mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-03-30 13:43:26 +08:00
Add Kiro base structure, install script, and docs (#809)
Co-authored-by: Sungmin Hong <hsungmin@amazon.com>
This commit is contained in:
Himanshu Sharma
607
.kiro/README.md
Normal file
607
.kiro/README.md
Normal file
@@ -0,0 +1,607 @@
|
|||||||
|
# Everything Claude Code for Kiro
|
||||||
|
|
||||||
|
Bring [Everything Claude Code](https://github.com/anthropics/courses/tree/master/everything-claude-code) (ECC) workflows to [Kiro](https://kiro.dev). This repository provides custom agents, skills, hooks, steering files, and scripts that can be installed into any Kiro project with a single command.
|
||||||
|
|
||||||
|
## Quick Start
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Go to .kiro folder
|
||||||
|
cd .kiro
|
||||||
|
|
||||||
|
# Install to your project
|
||||||
|
./install.sh /path/to/your/project
|
||||||
|
|
||||||
|
# Or install to the current directory
|
||||||
|
./install.sh
|
||||||
|
|
||||||
|
# Or install globally (applies to all Kiro projects)
|
||||||
|
./install.sh ~
|
||||||
|
```
|
||||||
|
|
||||||
|
The installer uses non-destructive copy — it will not overwrite your existing files.
|
||||||
|
|
||||||
|
## Component Inventory
|
||||||
|
|
||||||
|
| Component | Count | Location |
|
||||||
|
|-----------|-------|----------|
|
||||||
|
| Agents (JSON) | 16 | `.kiro/agents/*.json` |
|
||||||
|
| Agents (MD) | 16 | `.kiro/agents/*.md` |
|
||||||
|
| Skills | 18 | `.kiro/skills/*/SKILL.md` |
|
||||||
|
| Steering Files | 16 | `.kiro/steering/*.md` |
|
||||||
|
| IDE Hooks | 10 | `.kiro/hooks/*.kiro.hook` |
|
||||||
|
| Scripts | 2 | `.kiro/scripts/*.sh` |
|
||||||
|
| MCP Examples | 1 | `.kiro/settings/mcp.json.example` |
|
||||||
|
| Documentation | 5 | `docs/*.md` |
|
||||||
|
|
||||||
|
## What's Included
|
||||||
|
|
||||||
|
### Agents
|
||||||
|
|
||||||
|
Agents are specialized AI assistants with specific tool configurations.
|
||||||
|
|
||||||
|
**Format:**
|
||||||
|
- **IDE**: Markdown files (`.md`) - Access via automatic selection or explicit invocation
|
||||||
|
- **CLI**: JSON files (`.json`) - Access via `/agent swap` command
|
||||||
|
|
||||||
|
Both formats are included for maximum compatibility.
|
||||||
|
|
||||||
|
> **Note:** Agent models are determined by your current model selection in Kiro, not by the agent configuration.
|
||||||
|
|
||||||
|
| Agent | Description |
|
||||||
|
|-------|-------------|
|
||||||
|
| `planner` | Expert planning specialist for complex features and refactoring. Read-only tools for safe analysis. |
|
||||||
|
| `code-reviewer` | Senior code reviewer ensuring quality and security. Reviews code for CRITICAL security issues, code quality, React/Next.js patterns, and performance. |
|
||||||
|
| `tdd-guide` | Test-Driven Development specialist enforcing write-tests-first methodology. Ensures 80%+ test coverage with comprehensive test suites. |
|
||||||
|
| `security-reviewer` | Security vulnerability detection and remediation specialist. Flags secrets, SSRF, injection, unsafe crypto, and OWASP Top 10 vulnerabilities. |
|
||||||
|
| `architect` | Software architecture specialist for system design, scalability, and technical decision-making. Read-only tools for safe analysis. |
|
||||||
|
| `build-error-resolver` | Build and TypeScript error resolution specialist. Fixes build/type errors with minimal diffs, no architectural changes. |
|
||||||
|
| `doc-updater` | Documentation and codemap specialist. Updates codemaps and documentation, generates docs/CODEMAPS/*, updates READMEs. |
|
||||||
|
| `refactor-cleaner` | Dead code cleanup and consolidation specialist. Removes unused code, duplicates, and refactors safely. |
|
||||||
|
| `go-reviewer` | Go code review specialist. Reviews Go code for idiomatic patterns, error handling, concurrency, and performance. |
|
||||||
|
| `python-reviewer` | Python code review specialist. Reviews Python code for PEP 8, type hints, error handling, and best practices. |
|
||||||
|
| `database-reviewer` | Database and SQL specialist. Reviews schema design, queries, migrations, and database security. |
|
||||||
|
| `e2e-runner` | End-to-end testing specialist. Creates and maintains E2E tests using Playwright or Cypress. |
|
||||||
|
| `harness-optimizer` | Test harness optimization specialist. Improves test performance, reliability, and maintainability. |
|
||||||
|
| `loop-operator` | Verification loop operator. Runs comprehensive checks and iterates until all pass. |
|
||||||
|
| `chief-of-staff` | Executive assistant for project management, coordination, and strategic planning. |
|
||||||
|
| `go-build-resolver` | Go build error resolution specialist. Fixes Go compilation errors, dependency issues, and build problems. |
|
||||||
|
|
||||||
|
**Usage in IDE:**
|
||||||
|
- You can run an agent in `/` in a Kiro session, e.g., `/code-reviewer`.
|
||||||
|
- Kiro's Spec session has native planner, designer, and architects that can be used instead of `planner` and `architect` agents.
|
||||||
|
|
||||||
|
**Usage in CLI:**
|
||||||
|
1. Start a chat session
|
||||||
|
2. Type `/agent swap` to see available agents
|
||||||
|
3. Select an agent to switch (e.g., `code-reviewer` after writing code)
|
||||||
|
4. Or start with a specific agent: `kiro-cli --agent planner`
|
||||||
|
|
||||||
|
|
||||||
|
### Skills
|
||||||
|
|
||||||
|
Skills are on-demand workflows invocable via the `/` menu in chat.
|
||||||
|
|
||||||
|
| Skill | Description |
|
||||||
|
|-------|-------------|
|
||||||
|
| `tdd-workflow` | Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests. Use when writing new features or fixing bugs. |
|
||||||
|
| `coding-standards` | Universal coding standards and best practices for TypeScript, JavaScript, React, and Node.js. Use when starting projects, reviewing code, or refactoring. |
|
||||||
|
| `security-review` | Comprehensive security checklist and patterns. Use when adding authentication, handling user input, creating API endpoints, or working with secrets. |
|
||||||
|
| `verification-loop` | Comprehensive verification system that runs build, type check, lint, tests, security scan, and diff review. Use after completing features or before creating PRs. |
|
||||||
|
| `api-design` | RESTful API design patterns and best practices. Use when designing new APIs or refactoring existing endpoints. |
|
||||||
|
| `frontend-patterns` | React, Next.js, and frontend architecture patterns. Use when building UI components or optimizing frontend performance. |
|
||||||
|
| `backend-patterns` | Node.js, Express, and backend architecture patterns. Use when building APIs, services, or backend infrastructure. |
|
||||||
|
| `e2e-testing` | End-to-end testing with Playwright or Cypress. Use when adding E2E tests or improving test coverage. |
|
||||||
|
| `golang-patterns` | Go idioms, concurrency patterns, and best practices. Use when writing Go code or reviewing Go projects. |
|
||||||
|
| `golang-testing` | Go testing patterns with table-driven tests and benchmarks. Use when writing Go tests or improving test coverage. |
|
||||||
|
| `python-patterns` | Python idioms, type hints, and best practices. Use when writing Python code or reviewing Python projects. |
|
||||||
|
| `python-testing` | Python testing with pytest and coverage. Use when writing Python tests or improving test coverage. |
|
||||||
|
| `database-migrations` | Database schema design and migration patterns. Use when creating migrations or refactoring database schemas. |
|
||||||
|
| `postgres-patterns` | PostgreSQL-specific patterns and optimizations. Use when working with PostgreSQL databases. |
|
||||||
|
| `docker-patterns` | Docker and containerization best practices. Use when creating Dockerfiles or optimizing container builds. |
|
||||||
|
| `deployment-patterns` | Deployment strategies and CI/CD patterns. Use when setting up deployments or improving CI/CD pipelines. |
|
||||||
|
| `search-first` | Search-first development methodology. Use when exploring unfamiliar codebases or debugging issues. |
|
||||||
|
| `agentic-engineering` | Agentic software engineering patterns and workflows. Use when working with AI agents or building agentic systems. |
|
||||||
|
|
||||||
|
**Usage:**
|
||||||
|
|
||||||
|
1. Type `/` in chat to open the skills menu
|
||||||
|
2. Select a skill (e.g., `tdd-workflow` when starting a new feature, `security-review` when adding auth)
|
||||||
|
3. The agent will guide you through the workflow with specific instructions and checklists
|
||||||
|
|
||||||
|
**Note:** For planning complex features, use the `planner` agent instead (see Agents section above).
|
||||||
|
|
||||||
|
### Steering Files
|
||||||
|
|
||||||
|
Steering files provide always-on rules and context that shape how the agent works with your code.
|
||||||
|
|
||||||
|
| File | Inclusion | Description |
|
||||||
|
|------|-----------|-------------|
|
||||||
|
| `coding-style.md` | auto | Core coding style rules: immutability, file organization, error handling, and code quality standards. Loaded in every conversation. |
|
||||||
|
| `security.md` | auto | Security best practices including mandatory checks, secret management, and security response protocol. Loaded in every conversation. |
|
||||||
|
| `testing.md` | auto | Testing requirements: 80% coverage minimum, TDD workflow, and test types (unit, integration, E2E). Loaded in every conversation. |
|
||||||
|
| `development-workflow.md` | auto | Development process, PR workflow, and collaboration patterns. Loaded in every conversation. |
|
||||||
|
| `git-workflow.md` | auto | Git commit conventions, branching strategies, and version control best practices. Loaded in every conversation. |
|
||||||
|
| `patterns.md` | auto | Common design patterns and architectural principles. Loaded in every conversation. |
|
||||||
|
| `performance.md` | auto | Performance optimization guidelines and profiling strategies. Loaded in every conversation. |
|
||||||
|
| `lessons-learned.md` | auto | Project-specific patterns and learnings. Edit this file to capture your team's conventions. Loaded in every conversation. |
|
||||||
|
| `typescript-patterns.md` | fileMatch: `*.ts,*.tsx` | TypeScript-specific patterns, type safety, and best practices. Loaded when editing TypeScript files. |
|
||||||
|
| `python-patterns.md` | fileMatch: `*.py` | Python-specific patterns, type hints, and best practices. Loaded when editing Python files. |
|
||||||
|
| `golang-patterns.md` | fileMatch: `*.go` | Go-specific patterns, concurrency, and best practices. Loaded when editing Go files. |
|
||||||
|
| `swift-patterns.md` | fileMatch: `*.swift` | Swift-specific patterns and best practices. Loaded when editing Swift files. |
|
||||||
|
| `dev-mode.md` | manual | Development context mode. Invoke with `#dev-mode` for focused development. |
|
||||||
|
| `review-mode.md` | manual | Code review context mode. Invoke with `#review-mode` for thorough reviews. |
|
||||||
|
| `research-mode.md` | manual | Research context mode. Invoke with `#research-mode` for exploration and learning. |
|
||||||
|
|
||||||
|
Steering files with `auto` inclusion are loaded automatically. No action needed — they apply as soon as you install them.
|
||||||
|
|
||||||
|
To create your own, add a markdown file to `.kiro/steering/` with YAML frontmatter:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
---
|
||||||
|
inclusion: auto # auto | fileMatch | manual
|
||||||
|
description: Brief explanation of what this steering file contains
|
||||||
|
fileMatchPattern: "*.ts" # required if inclusion is fileMatch
|
||||||
|
---
|
||||||
|
|
||||||
|
Your rules here...
|
||||||
|
```
|
||||||
|
|
||||||
|
### Hooks
|
||||||
|
|
||||||
|
Kiro supports two types of hooks:
|
||||||
|
|
||||||
|
1. **IDE Hooks** - Standalone JSON files in `.kiro/hooks/` (for Kiro IDE)
|
||||||
|
2. **CLI Hooks** - Embedded in agent configurations (for `kiro-cli`)
|
||||||
|
|
||||||
|
#### IDE Hooks (Standalone Files)
|
||||||
|
|
||||||
|
These hooks appear in the Agent Hooks panel in the Kiro IDE and can be toggled on/off. Hook files use the `.kiro.hook` extension.
|
||||||
|
|
||||||
|
| Hook | Trigger | Action | Description |
|
||||||
|
|------|---------|--------|-------------|
|
||||||
|
| `quality-gate` | Manual (`userTriggered`) | `runCommand` | Runs build, type check, lint, and tests via `quality-gate.sh`. Click to trigger comprehensive quality checks. |
|
||||||
|
| `typecheck-on-edit` | File edited (`*.ts`, `*.tsx`) | `askAgent` | Checks for type errors when TypeScript files are edited to catch issues early. |
|
||||||
|
| `console-log-check` | File edited (`*.js`, `*.ts`, `*.tsx`) | `askAgent` | Checks for console.log statements to prevent debug code from being committed. |
|
||||||
|
| `tdd-reminder` | File created (`*.ts`, `*.tsx`) | `askAgent` | Reminds you to write tests first when creating new TypeScript files. |
|
||||||
|
| `git-push-review` | Before shell command | `askAgent` | Reviews git push commands to ensure code quality before pushing. |
|
||||||
|
| `code-review-on-write` | After write operation | `askAgent` | Triggers code review after file modifications. |
|
||||||
|
| `auto-format` | File edited (`*.ts`, `*.tsx`, `*.js`) | `askAgent` | Checks for formatting issues and fixes them inline without spawning a terminal. |
|
||||||
|
| `extract-patterns` | Agent stops | `askAgent` | Suggests patterns to add to lessons-learned.md after completing work. |
|
||||||
|
| `session-summary` | Agent stops | `askAgent` | Provides a summary of work completed in the session. |
|
||||||
|
| `doc-file-warning` | Before write operation | `askAgent` | Warns before modifying documentation files to ensure intentional changes. |
|
||||||
|
|
||||||
|
**IDE Hook Format:**
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"version": "1.0.0",
|
||||||
|
"enabled": true,
|
||||||
|
"name": "hook-name",
|
||||||
|
"description": "What this hook does",
|
||||||
|
"when": {
|
||||||
|
"type": "fileEdited",
|
||||||
|
"patterns": ["*.ts"]
|
||||||
|
},
|
||||||
|
"then": {
|
||||||
|
"type": "runCommand",
|
||||||
|
"command": "npx tsc --noEmit"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Required fields:** `version`, `enabled`, `name`, `description`, `when`, `then`
|
||||||
|
|
||||||
|
**Available trigger types:** `fileEdited`, `fileCreated`, `fileDeleted`, `userTriggered`, `promptSubmit`, `agentStop`, `preToolUse`, `postToolUse`
|
||||||
|
|
||||||
|
#### CLI Hooks (Embedded in Agents)
|
||||||
|
|
||||||
|
CLI hooks are embedded within agent configuration files for use with `kiro-cli`.
|
||||||
|
|
||||||
|
**Example:** See `.kiro/agents/tdd-guide-with-hooks.json` for an agent with embedded hooks.
|
||||||
|
|
||||||
|
**CLI Hook Format:**
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"name": "my-agent",
|
||||||
|
"hooks": {
|
||||||
|
"postToolUse": [
|
||||||
|
{
|
||||||
|
"matcher": "fs_write",
|
||||||
|
"command": "npx tsc --noEmit"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Available triggers:** `agentSpawn`, `userPromptSubmit`, `preToolUse`, `postToolUse`, `stop`
|
||||||
|
|
||||||
|
See `.kiro/hooks/README.md` for complete documentation on both hook types.
|
||||||
|
|
||||||
|
### Scripts
|
||||||
|
|
||||||
|
Shell scripts used by hooks to perform quality checks and formatting.
|
||||||
|
|
||||||
|
| Script | Description |
|
||||||
|
|--------|-------------|
|
||||||
|
| `quality-gate.sh` | Detects your package manager (pnpm/yarn/bun/npm) and runs build, type check, lint, and test commands. Skips checks gracefully if tools are missing. |
|
||||||
|
| `format.sh` | Detects your formatter (biome or prettier) and auto-formats the specified file. Used by formatting hooks. |
|
||||||
|
|
||||||
|
## Project Structure
|
||||||
|
|
||||||
|
```
|
||||||
|
.kiro/
|
||||||
|
├── agents/ # 16 agents (JSON + MD formats)
|
||||||
|
│ ├── planner.json # Planning specialist (CLI)
|
||||||
|
│ ├── planner.md # Planning specialist (IDE)
|
||||||
|
│ ├── code-reviewer.json # Code review specialist (CLI)
|
||||||
|
│ ├── code-reviewer.md # Code review specialist (IDE)
|
||||||
|
│ ├── tdd-guide.json # TDD specialist (CLI)
|
||||||
|
│ ├── tdd-guide.md # TDD specialist (IDE)
|
||||||
|
│ ├── security-reviewer.json # Security specialist (CLI)
|
||||||
|
│ ├── security-reviewer.md # Security specialist (IDE)
|
||||||
|
│ ├── architect.json # Architecture specialist (CLI)
|
||||||
|
│ ├── architect.md # Architecture specialist (IDE)
|
||||||
|
│ ├── build-error-resolver.json # Build error specialist (CLI)
|
||||||
|
│ ├── build-error-resolver.md # Build error specialist (IDE)
|
||||||
|
│ ├── doc-updater.json # Documentation specialist (CLI)
|
||||||
|
│ ├── doc-updater.md # Documentation specialist (IDE)
|
||||||
|
│ ├── refactor-cleaner.json # Refactoring specialist (CLI)
|
||||||
|
│ ├── refactor-cleaner.md # Refactoring specialist (IDE)
|
||||||
|
│ ├── go-reviewer.json # Go review specialist (CLI)
|
||||||
|
│ ├── go-reviewer.md # Go review specialist (IDE)
|
||||||
|
│ ├── python-reviewer.json # Python review specialist (CLI)
|
||||||
|
│ ├── python-reviewer.md # Python review specialist (IDE)
|
||||||
|
│ ├── database-reviewer.json # Database specialist (CLI)
|
||||||
|
│ ├── database-reviewer.md # Database specialist (IDE)
|
||||||
|
│ ├── e2e-runner.json # E2E testing specialist (CLI)
|
||||||
|
│ ├── e2e-runner.md # E2E testing specialist (IDE)
|
||||||
|
│ ├── harness-optimizer.json # Test harness specialist (CLI)
|
||||||
|
│ ├── harness-optimizer.md # Test harness specialist (IDE)
|
||||||
|
│ ├── loop-operator.json # Verification loop specialist (CLI)
|
||||||
|
│ ├── loop-operator.md # Verification loop specialist (IDE)
|
||||||
|
│ ├── chief-of-staff.json # Project management specialist (CLI)
|
||||||
|
│ ├── chief-of-staff.md # Project management specialist (IDE)
|
||||||
|
│ ├── go-build-resolver.json # Go build specialist (CLI)
|
||||||
|
│ └── go-build-resolver.md # Go build specialist (IDE)
|
||||||
|
├── skills/ # 18 skills
|
||||||
|
│ ├── tdd-workflow/
|
||||||
|
│ │ └── SKILL.md # TDD workflow skill
|
||||||
|
│ ├── coding-standards/
|
||||||
|
│ │ └── SKILL.md # Coding standards skill
|
||||||
|
│ ├── security-review/
|
||||||
|
│ │ └── SKILL.md # Security review skill
|
||||||
|
│ ├── verification-loop/
|
||||||
|
│ │ └── SKILL.md # Verification loop skill
|
||||||
|
│ ├── api-design/
|
||||||
|
│ │ └── SKILL.md # API design skill
|
||||||
|
│ ├── frontend-patterns/
|
||||||
|
│ │ └── SKILL.md # Frontend patterns skill
|
||||||
|
│ ├── backend-patterns/
|
||||||
|
│ │ └── SKILL.md # Backend patterns skill
|
||||||
|
│ ├── e2e-testing/
|
||||||
|
│ │ └── SKILL.md # E2E testing skill
|
||||||
|
│ ├── golang-patterns/
|
||||||
|
│ │ └── SKILL.md # Go patterns skill
|
||||||
|
│ ├── golang-testing/
|
||||||
|
│ │ └── SKILL.md # Go testing skill
|
||||||
|
│ ├── python-patterns/
|
||||||
|
│ │ └── SKILL.md # Python patterns skill
|
||||||
|
│ ├── python-testing/
|
||||||
|
│ │ └── SKILL.md # Python testing skill
|
||||||
|
│ ├── database-migrations/
|
||||||
|
│ │ └── SKILL.md # Database migrations skill
|
||||||
|
│ ├── postgres-patterns/
|
||||||
|
│ │ └── SKILL.md # PostgreSQL patterns skill
|
||||||
|
│ ├── docker-patterns/
|
||||||
|
│ │ └── SKILL.md # Docker patterns skill
|
||||||
|
│ ├── deployment-patterns/
|
||||||
|
│ │ └── SKILL.md # Deployment patterns skill
|
||||||
|
│ ├── search-first/
|
||||||
|
│ │ └── SKILL.md # Search-first methodology skill
|
||||||
|
│ └── agentic-engineering/
|
||||||
|
│ └── SKILL.md # Agentic engineering skill
|
||||||
|
├── steering/ # 16 steering files
|
||||||
|
│ ├── coding-style.md # Auto-loaded coding style rules
|
||||||
|
│ ├── security.md # Auto-loaded security rules
|
||||||
|
│ ├── testing.md # Auto-loaded testing rules
|
||||||
|
│ ├── development-workflow.md # Auto-loaded dev workflow
|
||||||
|
│ ├── git-workflow.md # Auto-loaded git workflow
|
||||||
|
│ ├── patterns.md # Auto-loaded design patterns
|
||||||
|
│ ├── performance.md # Auto-loaded performance rules
|
||||||
|
│ ├── lessons-learned.md # Auto-loaded project patterns
|
||||||
|
│ ├── typescript-patterns.md # Loaded for .ts/.tsx files
|
||||||
|
│ ├── python-patterns.md # Loaded for .py files
|
||||||
|
│ ├── golang-patterns.md # Loaded for .go files
|
||||||
|
│ ├── swift-patterns.md # Loaded for .swift files
|
||||||
|
│ ├── dev-mode.md # Manual: #dev-mode
|
||||||
|
│ ├── review-mode.md # Manual: #review-mode
|
||||||
|
│ └── research-mode.md # Manual: #research-mode
|
||||||
|
├── hooks/ # 10 IDE hooks
|
||||||
|
│ ├── README.md # Documentation on IDE and CLI hooks
|
||||||
|
│ ├── quality-gate.kiro.hook # Manual quality gate hook
|
||||||
|
│ ├── typecheck-on-edit.kiro.hook # Auto typecheck on edit
|
||||||
|
│ ├── console-log-check.kiro.hook # Check for console.log
|
||||||
|
│ ├── tdd-reminder.kiro.hook # TDD reminder on file create
|
||||||
|
│ ├── git-push-review.kiro.hook # Review before git push
|
||||||
|
│ ├── code-review-on-write.kiro.hook # Review after write
|
||||||
|
│ ├── auto-format.kiro.hook # Auto-format on edit
|
||||||
|
│ ├── extract-patterns.kiro.hook # Extract patterns on stop
|
||||||
|
│ ├── session-summary.kiro.hook # Summary on stop
|
||||||
|
│ └── doc-file-warning.kiro.hook # Warn before doc changes
|
||||||
|
├── scripts/ # 2 shell scripts
|
||||||
|
│ ├── quality-gate.sh # Quality gate shell script
|
||||||
|
│ └── format.sh # Auto-format shell script
|
||||||
|
└── settings/ # MCP configuration
|
||||||
|
└── mcp.json.example # Example MCP server configs
|
||||||
|
|
||||||
|
docs/ # 5 documentation files
|
||||||
|
├── longform-guide.md # Deep dive on agentic workflows
|
||||||
|
├── shortform-guide.md # Quick reference guide
|
||||||
|
├── security-guide.md # Security best practices
|
||||||
|
├── migration-from-ecc.md # Migration guide from ECC
|
||||||
|
└── ECC-KIRO-INTEGRATION-PLAN.md # Integration plan and analysis
|
||||||
|
```
|
||||||
|
|
||||||
|
## Customization
|
||||||
|
|
||||||
|
All files are yours to modify after installation. The installer never overwrites existing files, so your customizations are safe across re-installs.
|
||||||
|
|
||||||
|
- **Edit agent prompts** in `.kiro/agents/*.json` to adjust behavior or add project-specific instructions
|
||||||
|
- **Modify skill workflows** in `.kiro/skills/*/SKILL.md` to match your team's processes
|
||||||
|
- **Adjust steering rules** in `.kiro/steering/*.md` to enforce your coding standards
|
||||||
|
- **Toggle or edit hooks** in `.kiro/hooks/*.json` to automate your workflow
|
||||||
|
- **Customize scripts** in `.kiro/scripts/*.sh` to match your tooling setup
|
||||||
|
|
||||||
|
## Recommended Workflow
|
||||||
|
|
||||||
|
1. **Start with planning**: Use the `planner` agent to break down complex features
|
||||||
|
2. **Write tests first**: Invoke the `tdd-workflow` skill before implementing
|
||||||
|
3. **Review your code**: Switch to `code-reviewer` agent after writing code
|
||||||
|
4. **Check security**: Use `security-reviewer` agent for auth, API endpoints, or sensitive data handling
|
||||||
|
5. **Run quality gate**: Trigger the `quality-gate` hook before committing
|
||||||
|
6. **Verify comprehensively**: Use the `verification-loop` skill before creating PRs
|
||||||
|
|
||||||
|
The auto-loaded steering files (coding-style, security, testing) ensure consistent standards throughout your session.
|
||||||
|
|
||||||
|
## Usage Examples
|
||||||
|
|
||||||
|
### Example 1: Building a New Feature with TDD
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Start with the planner agent to break down the feature
|
||||||
|
kiro-cli --agent planner
|
||||||
|
> "I need to add user authentication with JWT tokens"
|
||||||
|
|
||||||
|
# 2. Invoke the TDD workflow skill
|
||||||
|
> /tdd-workflow
|
||||||
|
|
||||||
|
# 3. Follow the TDD cycle: write tests first, then implementation
|
||||||
|
# The tdd-workflow skill will guide you through:
|
||||||
|
# - Writing unit tests for auth logic
|
||||||
|
# - Writing integration tests for API endpoints
|
||||||
|
# - Writing E2E tests for login flow
|
||||||
|
|
||||||
|
# 4. Switch to code-reviewer after implementation
|
||||||
|
> /agent swap code-reviewer
|
||||||
|
> "Review the authentication implementation"
|
||||||
|
|
||||||
|
# 5. Run security review for auth-related code
|
||||||
|
> /agent swap security-reviewer
|
||||||
|
> "Check for security vulnerabilities in the auth system"
|
||||||
|
|
||||||
|
# 6. Trigger quality gate before committing
|
||||||
|
# (In IDE: Click the quality-gate hook in Agent Hooks panel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 2: Code Review Workflow
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Switch to code-reviewer agent
|
||||||
|
kiro-cli --agent code-reviewer
|
||||||
|
|
||||||
|
# 2. Review specific files or directories
|
||||||
|
> "Review the changes in src/api/users.ts"
|
||||||
|
|
||||||
|
# 3. Use the verification-loop skill for comprehensive checks
|
||||||
|
> /verification-loop
|
||||||
|
|
||||||
|
# 4. The verification loop will:
|
||||||
|
# - Run build and type checks
|
||||||
|
# - Run linter
|
||||||
|
# - Run all tests
|
||||||
|
# - Perform security scan
|
||||||
|
# - Review git diff
|
||||||
|
# - Iterate until all checks pass
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 3: Security-First Development
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Invoke security-review skill when working on sensitive features
|
||||||
|
> /security-review
|
||||||
|
|
||||||
|
# 2. The skill provides a comprehensive checklist:
|
||||||
|
# - Input validation and sanitization
|
||||||
|
# - Authentication and authorization
|
||||||
|
# - Secret management
|
||||||
|
# - SQL injection prevention
|
||||||
|
# - XSS prevention
|
||||||
|
# - CSRF protection
|
||||||
|
|
||||||
|
# 3. Switch to security-reviewer agent for deep analysis
|
||||||
|
> /agent swap security-reviewer
|
||||||
|
> "Analyze the API endpoints for security vulnerabilities"
|
||||||
|
|
||||||
|
# 4. The security.md steering file is auto-loaded, ensuring:
|
||||||
|
# - No hardcoded secrets
|
||||||
|
# - Proper error handling
|
||||||
|
# - Secure crypto usage
|
||||||
|
# - OWASP Top 10 compliance
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 4: Language-Specific Development
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# For Go projects:
|
||||||
|
kiro-cli --agent go-reviewer
|
||||||
|
> "Review the concurrency patterns in this service"
|
||||||
|
> /golang-patterns # Invoke Go-specific patterns skill
|
||||||
|
|
||||||
|
# For Python projects:
|
||||||
|
kiro-cli --agent python-reviewer
|
||||||
|
> "Review the type hints and error handling"
|
||||||
|
> /python-patterns # Invoke Python-specific patterns skill
|
||||||
|
|
||||||
|
# Language-specific steering files are auto-loaded:
|
||||||
|
# - golang-patterns.md loads when editing .go files
|
||||||
|
# - python-patterns.md loads when editing .py files
|
||||||
|
# - typescript-patterns.md loads when editing .ts/.tsx files
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 5: Using Hooks for Automation
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Hooks run automatically based on triggers:
|
||||||
|
|
||||||
|
# 1. typecheck-on-edit hook
|
||||||
|
# - Triggers when you save .ts or .tsx files
|
||||||
|
# - Agent checks for type errors inline, no terminal spawned
|
||||||
|
|
||||||
|
# 2. console-log-check hook
|
||||||
|
# - Triggers when you save .js, .ts, or .tsx files
|
||||||
|
# - Agent flags console.log statements and offers to remove them
|
||||||
|
|
||||||
|
# 3. tdd-reminder hook
|
||||||
|
# - Triggers when you create a new .ts or .tsx file
|
||||||
|
# - Reminds you to write tests first
|
||||||
|
# - Reinforces TDD discipline
|
||||||
|
|
||||||
|
# 4. extract-patterns hook
|
||||||
|
# - Runs when agent stops working
|
||||||
|
# - Suggests patterns to add to lessons-learned.md
|
||||||
|
# - Builds your team's knowledge base over time
|
||||||
|
|
||||||
|
# Toggle hooks on/off in the Agent Hooks panel (IDE)
|
||||||
|
# or disable them in the hook JSON files
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 6: Manual Context Modes
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Use manual steering files for specific contexts:
|
||||||
|
|
||||||
|
# Development mode - focused on implementation
|
||||||
|
> #dev-mode
|
||||||
|
> "Implement the user registration endpoint"
|
||||||
|
|
||||||
|
# Review mode - thorough code review
|
||||||
|
> #review-mode
|
||||||
|
> "Review all changes in the current PR"
|
||||||
|
|
||||||
|
# Research mode - exploration and learning
|
||||||
|
> #research-mode
|
||||||
|
> "Explain how the authentication system works"
|
||||||
|
|
||||||
|
# Manual steering files provide context-specific instructions
|
||||||
|
# without cluttering every conversation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 7: Database Work
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Use database-reviewer agent for schema work
|
||||||
|
kiro-cli --agent database-reviewer
|
||||||
|
> "Review the database schema for the users table"
|
||||||
|
|
||||||
|
# 2. Invoke database-migrations skill
|
||||||
|
> /database-migrations
|
||||||
|
|
||||||
|
# 3. For PostgreSQL-specific work
|
||||||
|
> /postgres-patterns
|
||||||
|
> "Optimize this query for better performance"
|
||||||
|
|
||||||
|
# 4. The database-reviewer checks:
|
||||||
|
# - Schema design and normalization
|
||||||
|
# - Index usage and performance
|
||||||
|
# - Migration safety
|
||||||
|
# - SQL injection vulnerabilities
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 8: Building and Deploying
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Fix build errors with build-error-resolver
|
||||||
|
kiro-cli --agent build-error-resolver
|
||||||
|
> "Fix the TypeScript compilation errors"
|
||||||
|
|
||||||
|
# 2. Use docker-patterns skill for containerization
|
||||||
|
> /docker-patterns
|
||||||
|
> "Create a production-ready Dockerfile"
|
||||||
|
|
||||||
|
# 3. Use deployment-patterns skill for CI/CD
|
||||||
|
> /deployment-patterns
|
||||||
|
> "Set up a GitHub Actions workflow for deployment"
|
||||||
|
|
||||||
|
# 4. Run quality gate before deployment
|
||||||
|
# (Trigger quality-gate hook to run all checks)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 9: Refactoring and Cleanup
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Use refactor-cleaner agent for safe refactoring
|
||||||
|
kiro-cli --agent refactor-cleaner
|
||||||
|
> "Remove unused code and consolidate duplicate functions"
|
||||||
|
|
||||||
|
# 2. The agent will:
|
||||||
|
# - Identify dead code
|
||||||
|
# - Find duplicate implementations
|
||||||
|
# - Suggest consolidation opportunities
|
||||||
|
# - Refactor safely without breaking changes
|
||||||
|
|
||||||
|
# 3. Use verification-loop after refactoring
|
||||||
|
> /verification-loop
|
||||||
|
# Ensures all tests still pass after refactoring
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example 10: Documentation Updates
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Use doc-updater agent for documentation work
|
||||||
|
kiro-cli --agent doc-updater
|
||||||
|
> "Update the README with the new API endpoints"
|
||||||
|
|
||||||
|
# 2. The agent will:
|
||||||
|
# - Update codemaps in docs/CODEMAPS/
|
||||||
|
# - Update README files
|
||||||
|
# - Generate API documentation
|
||||||
|
# - Keep docs in sync with code
|
||||||
|
|
||||||
|
# 3. doc-file-warning hook prevents accidental doc changes
|
||||||
|
# - Triggers before writing to documentation files
|
||||||
|
# - Asks for confirmation
|
||||||
|
# - Prevents unintentional modifications
|
||||||
|
```
|
||||||
|
|
||||||
|
## Documentation
|
||||||
|
|
||||||
|
For more detailed information, see the `docs/` directory:
|
||||||
|
|
||||||
|
- **[Longform Guide](docs/longform-guide.md)** - Deep dive on agentic workflows and best practices
|
||||||
|
- **[Shortform Guide](docs/shortform-guide.md)** - Quick reference for common tasks
|
||||||
|
- **[Security Guide](docs/security-guide.md)** - Comprehensive security best practices
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Contributers
|
||||||
|
|
||||||
|
- Himanshu Sharma [@ihimanss](https://github.com/ihimanss)
|
||||||
|
- Sungmin Hong [@aws-hsungmin](https://github.com/aws-hsungmin)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## License
|
||||||
|
|
||||||
|
MIT — see [LICENSE](LICENSE) for details.
|
||||||
301
.kiro/docs/longform-guide.md
Normal file
301
.kiro/docs/longform-guide.md
Normal file
@@ -0,0 +1,301 @@
|
|||||||
|
# Agentic Workflows: A Deep Dive
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
This guide explores the philosophy and practice of agentic workflows—a development methodology where AI agents become active collaborators in the software development process. Rather than treating AI as a code completion tool, agentic workflows position AI as a thinking partner that can plan, execute, review, and iterate on complex tasks.
|
||||||
|
|
||||||
|
## What Are Agentic Workflows?
|
||||||
|
|
||||||
|
Agentic workflows represent a fundamental shift in how we approach software development with AI assistance. Instead of asking an AI to "write this function" or "fix this bug," agentic workflows involve:
|
||||||
|
|
||||||
|
1. **Delegation of Intent**: You describe what you want to achieve, not how to achieve it
|
||||||
|
2. **Autonomous Execution**: The agent plans and executes multi-step tasks independently
|
||||||
|
3. **Iterative Refinement**: The agent reviews its own work and improves it
|
||||||
|
4. **Context Awareness**: The agent maintains understanding across conversations and files
|
||||||
|
5. **Tool Usage**: The agent uses development tools (linters, tests, formatters) to validate its work
|
||||||
|
|
||||||
|
## Core Principles
|
||||||
|
|
||||||
|
### 1. Agents as Specialists
|
||||||
|
|
||||||
|
Rather than one general-purpose agent, agentic workflows use specialized agents for different tasks:
|
||||||
|
|
||||||
|
- **Planner**: Breaks down complex features into actionable tasks
|
||||||
|
- **Code Reviewer**: Analyzes code for quality, security, and best practices
|
||||||
|
- **TDD Guide**: Leads test-driven development workflows
|
||||||
|
- **Security Reviewer**: Focuses exclusively on security concerns
|
||||||
|
- **Architect**: Designs system architecture and component interactions
|
||||||
|
|
||||||
|
Each agent has a specific model, tool set, and prompt optimized for its role.
|
||||||
|
|
||||||
|
### 2. Skills as Reusable Workflows
|
||||||
|
|
||||||
|
Skills are on-demand workflows that agents can invoke for specific tasks:
|
||||||
|
|
||||||
|
- **TDD Workflow**: Red-green-refactor cycle with property-based testing
|
||||||
|
- **Security Review**: Comprehensive security audit checklist
|
||||||
|
- **Verification Loop**: Continuous validation and improvement cycle
|
||||||
|
- **API Design**: RESTful API design patterns and best practices
|
||||||
|
|
||||||
|
Skills provide structured guidance for complex, multi-step processes.
|
||||||
|
|
||||||
|
### 3. Steering Files as Persistent Context
|
||||||
|
|
||||||
|
Steering files inject rules and patterns into every conversation:
|
||||||
|
|
||||||
|
- **Auto-inclusion**: Always-on rules (coding style, security, testing)
|
||||||
|
- **File-match**: Conditional rules based on file type (TypeScript patterns for .ts files)
|
||||||
|
- **Manual**: Context modes you invoke explicitly (dev-mode, review-mode)
|
||||||
|
|
||||||
|
This ensures consistency without repeating instructions.
|
||||||
|
|
||||||
|
### 4. Hooks as Automation
|
||||||
|
|
||||||
|
Hooks trigger actions automatically based on events:
|
||||||
|
|
||||||
|
- **File Events**: Run type checks when you save TypeScript files
|
||||||
|
- **Tool Events**: Review code before git push, check for console.log statements
|
||||||
|
- **Agent Events**: Summarize sessions, extract patterns for future use
|
||||||
|
|
||||||
|
Hooks create a safety net and capture knowledge automatically.
|
||||||
|
|
||||||
|
## Workflow Patterns
|
||||||
|
|
||||||
|
### Pattern 1: Feature Development with TDD
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Invoke planner agent: "Plan a user authentication feature"
|
||||||
|
→ Agent creates task breakdown with acceptance criteria
|
||||||
|
|
||||||
|
2. Invoke tdd-guide agent with tdd-workflow skill
|
||||||
|
→ Agent writes failing tests first
|
||||||
|
→ Agent implements minimal code to pass tests
|
||||||
|
→ Agent refactors for quality
|
||||||
|
|
||||||
|
3. Hooks trigger automatically:
|
||||||
|
→ typecheck-on-edit runs after each file save
|
||||||
|
→ code-review-on-write provides feedback after implementation
|
||||||
|
→ quality-gate runs before commit
|
||||||
|
|
||||||
|
4. Invoke code-reviewer agent for final review
|
||||||
|
→ Agent checks for edge cases, error handling, documentation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Pattern 2: Security-First Development
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Enable security-review skill for the session
|
||||||
|
→ Security patterns loaded into context
|
||||||
|
|
||||||
|
2. Invoke security-reviewer agent: "Review authentication implementation"
|
||||||
|
→ Agent checks for common vulnerabilities
|
||||||
|
→ Agent validates input sanitization
|
||||||
|
→ Agent reviews cryptographic usage
|
||||||
|
|
||||||
|
3. git-push-review hook triggers before push
|
||||||
|
→ Agent performs final security check
|
||||||
|
→ Agent blocks push if critical issues found
|
||||||
|
|
||||||
|
4. Update lessons-learned.md with security patterns
|
||||||
|
→ extract-patterns hook suggests additions
|
||||||
|
```
|
||||||
|
|
||||||
|
### Pattern 3: Refactoring Legacy Code
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Invoke architect agent: "Analyze this module's architecture"
|
||||||
|
→ Agent identifies coupling, cohesion issues
|
||||||
|
→ Agent suggests refactoring strategy
|
||||||
|
|
||||||
|
2. Invoke refactor-cleaner agent with verification-loop skill
|
||||||
|
→ Agent refactors incrementally
|
||||||
|
→ Agent runs tests after each change
|
||||||
|
→ Agent validates behavior preservation
|
||||||
|
|
||||||
|
3. Invoke code-reviewer agent for quality check
|
||||||
|
→ Agent ensures code quality improved
|
||||||
|
→ Agent verifies documentation updated
|
||||||
|
```
|
||||||
|
|
||||||
|
### Pattern 4: Bug Investigation and Fix
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Invoke planner agent: "Investigate why login fails on mobile"
|
||||||
|
→ Agent creates investigation plan
|
||||||
|
→ Agent identifies files to examine
|
||||||
|
|
||||||
|
2. Invoke build-error-resolver agent
|
||||||
|
→ Agent reproduces the bug
|
||||||
|
→ Agent writes failing test
|
||||||
|
→ Agent implements fix
|
||||||
|
→ Agent validates fix with tests
|
||||||
|
|
||||||
|
3. Invoke security-reviewer agent
|
||||||
|
→ Agent ensures fix doesn't introduce vulnerabilities
|
||||||
|
|
||||||
|
4. doc-updater agent updates documentation
|
||||||
|
→ Agent adds troubleshooting notes
|
||||||
|
→ Agent updates changelog
|
||||||
|
```
|
||||||
|
|
||||||
|
## Advanced Techniques
|
||||||
|
|
||||||
|
### Technique 1: Continuous Learning with Lessons Learned
|
||||||
|
|
||||||
|
The `lessons-learned.md` steering file acts as your project's evolving knowledge base:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
inclusion: auto
|
||||||
|
description: Project-specific patterns and decisions
|
||||||
|
---
|
||||||
|
|
||||||
|
## Project-Specific Patterns
|
||||||
|
|
||||||
|
### Authentication Flow
|
||||||
|
- Always use JWT with 15-minute expiry
|
||||||
|
- Refresh tokens stored in httpOnly cookies
|
||||||
|
- Rate limit: 5 attempts per minute per IP
|
||||||
|
|
||||||
|
### Error Handling
|
||||||
|
- Use Result<T, E> pattern for expected errors
|
||||||
|
- Log errors with correlation IDs
|
||||||
|
- Never expose stack traces to clients
|
||||||
|
```
|
||||||
|
|
||||||
|
The `extract-patterns` hook automatically suggests additions after each session.
|
||||||
|
|
||||||
|
### Technique 2: Context Modes for Different Tasks
|
||||||
|
|
||||||
|
Use manual steering files to switch contexts:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Development mode: Focus on speed and iteration
|
||||||
|
#dev-mode
|
||||||
|
|
||||||
|
# Review mode: Focus on quality and security
|
||||||
|
#review-mode
|
||||||
|
|
||||||
|
# Research mode: Focus on exploration and learning
|
||||||
|
#research-mode
|
||||||
|
```
|
||||||
|
|
||||||
|
Each mode loads different rules and priorities.
|
||||||
|
|
||||||
|
### Technique 3: Agent Chaining
|
||||||
|
|
||||||
|
Chain specialized agents for complex workflows:
|
||||||
|
|
||||||
|
```
|
||||||
|
planner → architect → tdd-guide → security-reviewer → doc-updater
|
||||||
|
```
|
||||||
|
|
||||||
|
Each agent builds on the previous agent's work, creating a pipeline.
|
||||||
|
|
||||||
|
### Technique 4: Property-Based Testing Integration
|
||||||
|
|
||||||
|
Use the TDD workflow skill with property-based testing:
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Define correctness properties (not just examples)
|
||||||
|
2. Agent generates property tests with fast-check
|
||||||
|
3. Agent runs 100+ iterations to find edge cases
|
||||||
|
4. Agent fixes issues discovered by properties
|
||||||
|
5. Agent documents properties in code comments
|
||||||
|
```
|
||||||
|
|
||||||
|
This catches bugs that example-based tests miss.
|
||||||
|
|
||||||
|
## Best Practices
|
||||||
|
|
||||||
|
### 1. Start with Planning
|
||||||
|
|
||||||
|
Always begin complex features with the planner agent. A good plan saves hours of rework.
|
||||||
|
|
||||||
|
### 2. Use the Right Agent for the Job
|
||||||
|
|
||||||
|
Don't use a general agent when a specialist exists. The security-reviewer agent will catch vulnerabilities that a general agent might miss.
|
||||||
|
|
||||||
|
### 3. Enable Relevant Hooks
|
||||||
|
|
||||||
|
Hooks provide automatic quality checks. Enable them early to catch issues immediately.
|
||||||
|
|
||||||
|
### 4. Maintain Lessons Learned
|
||||||
|
|
||||||
|
Update `lessons-learned.md` regularly. It becomes more valuable over time as it captures your project's unique patterns.
|
||||||
|
|
||||||
|
### 5. Review Agent Output
|
||||||
|
|
||||||
|
Agents are powerful but not infallible. Always review generated code, especially for security-critical components.
|
||||||
|
|
||||||
|
### 6. Iterate with Feedback
|
||||||
|
|
||||||
|
If an agent's output isn't quite right, provide specific feedback and let it iterate. Agents improve with clear guidance.
|
||||||
|
|
||||||
|
### 7. Use Skills for Complex Workflows
|
||||||
|
|
||||||
|
Don't try to describe a complex workflow in a single prompt. Use skills that encode best practices.
|
||||||
|
|
||||||
|
### 8. Combine Auto and Manual Steering
|
||||||
|
|
||||||
|
Use auto-inclusion for universal rules, file-match for language-specific patterns, and manual for context switching.
|
||||||
|
|
||||||
|
## Common Pitfalls
|
||||||
|
|
||||||
|
### Pitfall 1: Over-Prompting
|
||||||
|
|
||||||
|
**Problem**: Providing too much detail in prompts, micromanaging the agent.
|
||||||
|
|
||||||
|
**Solution**: Trust the agent to figure out implementation details. Focus on intent and constraints.
|
||||||
|
|
||||||
|
### Pitfall 2: Ignoring Hooks
|
||||||
|
|
||||||
|
**Problem**: Disabling hooks because they "slow things down."
|
||||||
|
|
||||||
|
**Solution**: Hooks catch issues early when they're cheap to fix. The time saved far exceeds the overhead.
|
||||||
|
|
||||||
|
### Pitfall 3: Not Using Specialized Agents
|
||||||
|
|
||||||
|
**Problem**: Using the default agent for everything.
|
||||||
|
|
||||||
|
**Solution**: Swap to specialized agents for their domains. They have optimized prompts and tool sets.
|
||||||
|
|
||||||
|
### Pitfall 4: Forgetting to Update Lessons Learned
|
||||||
|
|
||||||
|
**Problem**: Repeating the same explanations to agents in every session.
|
||||||
|
|
||||||
|
**Solution**: Capture patterns in `lessons-learned.md` once, and agents will remember forever.
|
||||||
|
|
||||||
|
### Pitfall 5: Skipping Tests
|
||||||
|
|
||||||
|
**Problem**: Asking agents to "just write the code" without tests.
|
||||||
|
|
||||||
|
**Solution**: Use the TDD workflow. Tests document behavior and catch regressions.
|
||||||
|
|
||||||
|
## Measuring Success
|
||||||
|
|
||||||
|
### Metrics to Track
|
||||||
|
|
||||||
|
1. **Time to Feature**: How long from idea to production?
|
||||||
|
2. **Bug Density**: Bugs per 1000 lines of code
|
||||||
|
3. **Review Cycles**: How many iterations before merge?
|
||||||
|
4. **Test Coverage**: Percentage of code covered by tests
|
||||||
|
5. **Security Issues**: Vulnerabilities found in review vs. production
|
||||||
|
|
||||||
|
### Expected Improvements
|
||||||
|
|
||||||
|
With mature agentic workflows, teams typically see:
|
||||||
|
|
||||||
|
- 40-60% reduction in time to feature
|
||||||
|
- 50-70% reduction in bug density
|
||||||
|
- 30-50% reduction in review cycles
|
||||||
|
- 80%+ test coverage (up from 40-60%)
|
||||||
|
- 90%+ reduction in security issues reaching production
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
Agentic workflows represent a paradigm shift in software development. By treating AI as a collaborative partner with specialized roles, persistent context, and automated quality checks, we can build software faster and with higher quality than ever before.
|
||||||
|
|
||||||
|
The key is to embrace the methodology fully: use specialized agents, leverage skills for complex workflows, maintain steering files for consistency, and enable hooks for automation. Start small with one agent or skill, experience the benefits, and gradually expand your agentic workflow toolkit.
|
||||||
|
|
||||||
|
The future of software development is collaborative, and agentic workflows are leading the way.
|
||||||
496
.kiro/docs/security-guide.md
Normal file
496
.kiro/docs/security-guide.md
Normal file
@@ -0,0 +1,496 @@
|
|||||||
|
# Security Guide for Agentic Workflows
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
AI agents are powerful development tools, but they introduce unique security considerations. This guide covers security best practices for using agentic workflows safely and responsibly.
|
||||||
|
|
||||||
|
## Core Security Principles
|
||||||
|
|
||||||
|
### 1. Trust but Verify
|
||||||
|
|
||||||
|
**Principle**: Always review agent-generated code, especially for security-critical components.
|
||||||
|
|
||||||
|
**Why**: Agents can make mistakes, miss edge cases, or introduce vulnerabilities unintentionally.
|
||||||
|
|
||||||
|
**Practice**:
|
||||||
|
- Review all authentication and authorization code manually
|
||||||
|
- Verify cryptographic implementations against standards
|
||||||
|
- Check input validation and sanitization
|
||||||
|
- Test error handling for information leakage
|
||||||
|
|
||||||
|
### 2. Least Privilege
|
||||||
|
|
||||||
|
**Principle**: Grant agents only the tools and access they need for their specific role.
|
||||||
|
|
||||||
|
**Why**: Limiting agent capabilities reduces the blast radius of potential mistakes.
|
||||||
|
|
||||||
|
**Practice**:
|
||||||
|
- Use `allowedTools` to restrict agent capabilities
|
||||||
|
- Read-only agents (planner, architect) should not have write access
|
||||||
|
- Review agents should not have shell access
|
||||||
|
- Use `toolsSettings.allowedPaths` to restrict file access
|
||||||
|
|
||||||
|
### 3. Defense in Depth
|
||||||
|
|
||||||
|
**Principle**: Use multiple layers of security controls.
|
||||||
|
|
||||||
|
**Why**: No single control is perfect; layered defenses catch what others miss.
|
||||||
|
|
||||||
|
**Practice**:
|
||||||
|
- Enable security-focused hooks (git-push-review, doc-file-warning)
|
||||||
|
- Use the security-reviewer agent before merging
|
||||||
|
- Maintain security steering files for consistent rules
|
||||||
|
- Run automated security scans in CI/CD
|
||||||
|
|
||||||
|
### 4. Secure by Default
|
||||||
|
|
||||||
|
**Principle**: Security should be the default, not an afterthought.
|
||||||
|
|
||||||
|
**Why**: It's easier to maintain security from the start than to retrofit it later.
|
||||||
|
|
||||||
|
**Practice**:
|
||||||
|
- Enable auto-inclusion security steering files
|
||||||
|
- Use TDD workflow with security test cases
|
||||||
|
- Include security requirements in planning phase
|
||||||
|
- Document security decisions in lessons-learned
|
||||||
|
|
||||||
|
## Agent-Specific Security
|
||||||
|
|
||||||
|
### Planner Agent
|
||||||
|
|
||||||
|
**Risk**: May suggest insecure architectures or skip security requirements.
|
||||||
|
|
||||||
|
**Mitigation**:
|
||||||
|
- Always include security requirements in planning prompts
|
||||||
|
- Review plans with security-reviewer agent
|
||||||
|
- Use security-review skill during planning
|
||||||
|
- Document security constraints in requirements
|
||||||
|
|
||||||
|
**Example Secure Prompt**:
|
||||||
|
```
|
||||||
|
Plan a user authentication feature with these security requirements:
|
||||||
|
- Password hashing with bcrypt (cost factor 12)
|
||||||
|
- Rate limiting (5 attempts per minute)
|
||||||
|
- JWT tokens with 15-minute expiry
|
||||||
|
- Refresh tokens in httpOnly cookies
|
||||||
|
- CSRF protection for state-changing operations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Code-Writing Agents (TDD Guide, Build Error Resolver)
|
||||||
|
|
||||||
|
**Risk**: May introduce vulnerabilities like SQL injection, XSS, or insecure deserialization.
|
||||||
|
|
||||||
|
**Mitigation**:
|
||||||
|
- Enable security steering files (auto-loaded)
|
||||||
|
- Use git-push-review hook to catch issues before commit
|
||||||
|
- Run security-reviewer agent after implementation
|
||||||
|
- Include security test cases in TDD workflow
|
||||||
|
|
||||||
|
**Common Vulnerabilities to Watch**:
|
||||||
|
- SQL injection (use parameterized queries)
|
||||||
|
- XSS (sanitize user input, escape output)
|
||||||
|
- CSRF (use tokens for state-changing operations)
|
||||||
|
- Path traversal (validate and sanitize file paths)
|
||||||
|
- Command injection (avoid shell execution with user input)
|
||||||
|
- Insecure deserialization (validate before deserializing)
|
||||||
|
|
||||||
|
### Security Reviewer Agent
|
||||||
|
|
||||||
|
**Risk**: May miss subtle vulnerabilities or provide false confidence.
|
||||||
|
|
||||||
|
**Mitigation**:
|
||||||
|
- Use as one layer, not the only layer
|
||||||
|
- Combine with automated security scanners
|
||||||
|
- Review findings manually
|
||||||
|
- Update security steering files with new patterns
|
||||||
|
|
||||||
|
**Best Practice**:
|
||||||
|
```
|
||||||
|
1. Run security-reviewer agent
|
||||||
|
2. Run automated scanner (Snyk, SonarQube, etc.)
|
||||||
|
3. Manual review of critical components
|
||||||
|
4. Document findings in lessons-learned
|
||||||
|
```
|
||||||
|
|
||||||
|
### Refactor Cleaner Agent
|
||||||
|
|
||||||
|
**Risk**: May accidentally remove security checks during refactoring.
|
||||||
|
|
||||||
|
**Mitigation**:
|
||||||
|
- Use verification-loop skill to validate behavior preservation
|
||||||
|
- Include security tests in test suite
|
||||||
|
- Review diffs carefully for removed security code
|
||||||
|
- Run security-reviewer after refactoring
|
||||||
|
|
||||||
|
## Hook Security
|
||||||
|
|
||||||
|
### Git Push Review Hook
|
||||||
|
|
||||||
|
**Purpose**: Catch security issues before they reach the repository.
|
||||||
|
|
||||||
|
**Configuration**:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"name": "git-push-review",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"description": "Review code before git push",
|
||||||
|
"enabled": true,
|
||||||
|
"when": {
|
||||||
|
"type": "preToolUse",
|
||||||
|
"toolTypes": ["shell"]
|
||||||
|
},
|
||||||
|
"then": {
|
||||||
|
"type": "askAgent",
|
||||||
|
"prompt": "Review the code for security issues before pushing. Check for: SQL injection, XSS, CSRF, authentication bypasses, information leakage, and insecure cryptography. Block the push if critical issues are found."
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Best Practice**: Keep this hook enabled always, especially for production branches.
|
||||||
|
|
||||||
|
### Console Log Check Hook
|
||||||
|
|
||||||
|
**Purpose**: Prevent accidental logging of sensitive data.
|
||||||
|
|
||||||
|
**Configuration**:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"name": "console-log-check",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"description": "Check for console.log statements",
|
||||||
|
"enabled": true,
|
||||||
|
"when": {
|
||||||
|
"type": "fileEdited",
|
||||||
|
"patterns": ["*.js", "*.ts", "*.tsx"]
|
||||||
|
},
|
||||||
|
"then": {
|
||||||
|
"type": "runCommand",
|
||||||
|
"command": "grep -n 'console\\.log' \"$KIRO_FILE_PATH\" && echo 'Warning: console.log found' || true"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why**: Console logs can leak sensitive data (passwords, tokens, PII) in production.
|
||||||
|
|
||||||
|
### Doc File Warning Hook
|
||||||
|
|
||||||
|
**Purpose**: Prevent accidental modification of critical documentation.
|
||||||
|
|
||||||
|
**Configuration**:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"name": "doc-file-warning",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"description": "Warn before modifying documentation files",
|
||||||
|
"enabled": true,
|
||||||
|
"when": {
|
||||||
|
"type": "preToolUse",
|
||||||
|
"toolTypes": ["write"]
|
||||||
|
},
|
||||||
|
"then": {
|
||||||
|
"type": "askAgent",
|
||||||
|
"prompt": "If you're about to modify a README, SECURITY, or LICENSE file, confirm this is intentional and the changes are appropriate."
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Steering File Security
|
||||||
|
|
||||||
|
### Security Steering File
|
||||||
|
|
||||||
|
**Purpose**: Inject security rules into every conversation.
|
||||||
|
|
||||||
|
**Key Rules to Include**:
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
inclusion: auto
|
||||||
|
description: Security best practices and vulnerability prevention
|
||||||
|
---
|
||||||
|
|
||||||
|
# Security Rules
|
||||||
|
|
||||||
|
## Input Validation
|
||||||
|
- Validate all user input on the server side
|
||||||
|
- Use allowlists, not denylists
|
||||||
|
- Sanitize input before use
|
||||||
|
- Reject invalid input, don't try to fix it
|
||||||
|
|
||||||
|
## Authentication
|
||||||
|
- Use bcrypt/argon2 for password hashing (never MD5/SHA1)
|
||||||
|
- Implement rate limiting on authentication endpoints
|
||||||
|
- Use secure session management (httpOnly, secure, sameSite cookies)
|
||||||
|
- Implement account lockout after failed attempts
|
||||||
|
|
||||||
|
## Authorization
|
||||||
|
- Check authorization on every request
|
||||||
|
- Use principle of least privilege
|
||||||
|
- Implement role-based access control (RBAC)
|
||||||
|
- Never trust client-side authorization checks
|
||||||
|
|
||||||
|
## Cryptography
|
||||||
|
- Use TLS 1.3 for transport security
|
||||||
|
- Use established libraries (don't roll your own crypto)
|
||||||
|
- Use secure random number generators
|
||||||
|
- Rotate keys regularly
|
||||||
|
|
||||||
|
## Data Protection
|
||||||
|
- Encrypt sensitive data at rest
|
||||||
|
- Never log passwords, tokens, or PII
|
||||||
|
- Use parameterized queries (prevent SQL injection)
|
||||||
|
- Sanitize output (prevent XSS)
|
||||||
|
|
||||||
|
## Error Handling
|
||||||
|
- Never expose stack traces to users
|
||||||
|
- Log errors securely with correlation IDs
|
||||||
|
- Use generic error messages for users
|
||||||
|
- Implement proper exception handling
|
||||||
|
```
|
||||||
|
|
||||||
|
### Language-Specific Security
|
||||||
|
|
||||||
|
**TypeScript/JavaScript**:
|
||||||
|
```markdown
|
||||||
|
- Use Content Security Policy (CSP) headers
|
||||||
|
- Sanitize HTML with DOMPurify
|
||||||
|
- Use helmet.js for Express security headers
|
||||||
|
- Validate with Zod/Yup, not manual checks
|
||||||
|
- Use prepared statements for database queries
|
||||||
|
```
|
||||||
|
|
||||||
|
**Python**:
|
||||||
|
```markdown
|
||||||
|
- Use parameterized queries with SQLAlchemy
|
||||||
|
- Sanitize HTML with bleach
|
||||||
|
- Use secrets module for random tokens
|
||||||
|
- Validate with Pydantic
|
||||||
|
- Use Flask-Talisman for security headers
|
||||||
|
```
|
||||||
|
|
||||||
|
**Go**:
|
||||||
|
```markdown
|
||||||
|
- Use html/template for HTML escaping
|
||||||
|
- Use crypto/rand for random generation
|
||||||
|
- Use prepared statements with database/sql
|
||||||
|
- Validate with validator package
|
||||||
|
- Use secure middleware for HTTP headers
|
||||||
|
```
|
||||||
|
|
||||||
|
## MCP Server Security
|
||||||
|
|
||||||
|
### Risk Assessment
|
||||||
|
|
||||||
|
MCP servers extend agent capabilities but introduce security risks:
|
||||||
|
|
||||||
|
- **Network Access**: Servers can make external API calls
|
||||||
|
- **File System Access**: Some servers can read/write files
|
||||||
|
- **Credential Storage**: Servers may require API keys
|
||||||
|
- **Code Execution**: Some servers can execute arbitrary code
|
||||||
|
|
||||||
|
### Secure MCP Configuration
|
||||||
|
|
||||||
|
**1. Review Server Permissions**
|
||||||
|
|
||||||
|
Before installing an MCP server, review what it can do:
|
||||||
|
```bash
|
||||||
|
# Check server documentation
|
||||||
|
# Understand what APIs it calls
|
||||||
|
# Review what data it accesses
|
||||||
|
```
|
||||||
|
|
||||||
|
**2. Use Environment Variables for Secrets**
|
||||||
|
|
||||||
|
Never hardcode API keys in `mcp.json`:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"mcpServers": {
|
||||||
|
"github": {
|
||||||
|
"command": "npx",
|
||||||
|
"args": ["-y", "@modelcontextprotocol/server-github"],
|
||||||
|
"env": {
|
||||||
|
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**3. Limit Server Scope**
|
||||||
|
|
||||||
|
Use least privilege for API tokens:
|
||||||
|
- GitHub: Use fine-grained tokens with minimal scopes
|
||||||
|
- Cloud providers: Use service accounts with minimal permissions
|
||||||
|
- Databases: Use read-only credentials when possible
|
||||||
|
|
||||||
|
**4. Review Server Code**
|
||||||
|
|
||||||
|
For open-source MCP servers:
|
||||||
|
```bash
|
||||||
|
# Clone and review the source
|
||||||
|
git clone https://github.com/org/mcp-server
|
||||||
|
cd mcp-server
|
||||||
|
# Review for security issues
|
||||||
|
grep -r "eval\|exec\|shell" .
|
||||||
|
```
|
||||||
|
|
||||||
|
**5. Use Auto-Approve Carefully**
|
||||||
|
|
||||||
|
Only auto-approve tools you fully trust:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"mcpServers": {
|
||||||
|
"github": {
|
||||||
|
"autoApprove": ["search_repositories", "get_file_contents"]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Never auto-approve:
|
||||||
|
- File write operations
|
||||||
|
- Shell command execution
|
||||||
|
- Database modifications
|
||||||
|
- API calls that change state
|
||||||
|
|
||||||
|
## Secrets Management
|
||||||
|
|
||||||
|
### Never Commit Secrets
|
||||||
|
|
||||||
|
**Risk**: Secrets in version control can be extracted from history.
|
||||||
|
|
||||||
|
**Prevention**:
|
||||||
|
```bash
|
||||||
|
# Add to .gitignore
|
||||||
|
echo ".env" >> .gitignore
|
||||||
|
echo ".kiro/settings/mcp.json" >> .gitignore
|
||||||
|
echo "secrets/" >> .gitignore
|
||||||
|
|
||||||
|
# Use git-secrets or similar tools
|
||||||
|
git secrets --install
|
||||||
|
git secrets --register-aws
|
||||||
|
```
|
||||||
|
|
||||||
|
### Use Environment Variables
|
||||||
|
|
||||||
|
**Good**:
|
||||||
|
```bash
|
||||||
|
# .env file (not committed)
|
||||||
|
DATABASE_URL=postgresql://user:pass@localhost/db
|
||||||
|
API_KEY=sk-...
|
||||||
|
|
||||||
|
# Load in application
|
||||||
|
export $(cat .env | xargs)
|
||||||
|
```
|
||||||
|
|
||||||
|
**Bad**:
|
||||||
|
```javascript
|
||||||
|
// Hardcoded secret (never do this!)
|
||||||
|
const apiKey = "sk-1234567890abcdef";
|
||||||
|
```
|
||||||
|
|
||||||
|
### Rotate Secrets Regularly
|
||||||
|
|
||||||
|
- API keys: Every 90 days
|
||||||
|
- Database passwords: Every 90 days
|
||||||
|
- JWT signing keys: Every 30 days
|
||||||
|
- Refresh tokens: On suspicious activity
|
||||||
|
|
||||||
|
### Use Secret Management Services
|
||||||
|
|
||||||
|
For production:
|
||||||
|
- AWS Secrets Manager
|
||||||
|
- HashiCorp Vault
|
||||||
|
- Azure Key Vault
|
||||||
|
- Google Secret Manager
|
||||||
|
|
||||||
|
## Incident Response
|
||||||
|
|
||||||
|
### If an Agent Generates Vulnerable Code
|
||||||
|
|
||||||
|
1. **Stop**: Don't merge or deploy the code
|
||||||
|
2. **Analyze**: Understand the vulnerability
|
||||||
|
3. **Fix**: Correct the issue manually or with security-reviewer agent
|
||||||
|
4. **Test**: Verify the fix with security tests
|
||||||
|
5. **Document**: Add pattern to lessons-learned.md
|
||||||
|
6. **Update**: Improve security steering files to prevent recurrence
|
||||||
|
|
||||||
|
### If Secrets Are Exposed
|
||||||
|
|
||||||
|
1. **Revoke**: Immediately revoke exposed credentials
|
||||||
|
2. **Rotate**: Generate new credentials
|
||||||
|
3. **Audit**: Check for unauthorized access
|
||||||
|
4. **Clean**: Remove secrets from git history (git-filter-repo)
|
||||||
|
5. **Prevent**: Update .gitignore and pre-commit hooks
|
||||||
|
|
||||||
|
### If a Security Issue Reaches Production
|
||||||
|
|
||||||
|
1. **Assess**: Determine severity and impact
|
||||||
|
2. **Contain**: Deploy hotfix or take system offline
|
||||||
|
3. **Notify**: Inform affected users if required
|
||||||
|
4. **Investigate**: Determine root cause
|
||||||
|
5. **Remediate**: Fix the issue permanently
|
||||||
|
6. **Learn**: Update processes to prevent recurrence
|
||||||
|
|
||||||
|
## Security Checklist
|
||||||
|
|
||||||
|
### Before Starting Development
|
||||||
|
|
||||||
|
- [ ] Security steering files enabled (auto-inclusion)
|
||||||
|
- [ ] Security-focused hooks enabled (git-push-review, console-log-check)
|
||||||
|
- [ ] MCP servers reviewed and configured securely
|
||||||
|
- [ ] Secrets management strategy in place
|
||||||
|
- [ ] .gitignore includes sensitive files
|
||||||
|
|
||||||
|
### During Development
|
||||||
|
|
||||||
|
- [ ] Security requirements included in planning
|
||||||
|
- [ ] TDD workflow includes security test cases
|
||||||
|
- [ ] Input validation on all user input
|
||||||
|
- [ ] Output sanitization for all user-facing content
|
||||||
|
- [ ] Authentication and authorization implemented correctly
|
||||||
|
- [ ] Cryptography uses established libraries
|
||||||
|
- [ ] Error handling doesn't leak information
|
||||||
|
|
||||||
|
### Before Merging
|
||||||
|
|
||||||
|
- [ ] Code reviewed by security-reviewer agent
|
||||||
|
- [ ] Automated security scanner run (Snyk, SonarQube)
|
||||||
|
- [ ] Manual review of security-critical code
|
||||||
|
- [ ] No secrets in code or configuration
|
||||||
|
- [ ] No console.log statements with sensitive data
|
||||||
|
- [ ] Security tests passing
|
||||||
|
|
||||||
|
### Before Deploying
|
||||||
|
|
||||||
|
- [ ] Security headers configured (CSP, HSTS, etc.)
|
||||||
|
- [ ] TLS/HTTPS enabled
|
||||||
|
- [ ] Rate limiting configured
|
||||||
|
- [ ] Monitoring and alerting set up
|
||||||
|
- [ ] Incident response plan documented
|
||||||
|
- [ ] Secrets rotated if needed
|
||||||
|
|
||||||
|
## Resources
|
||||||
|
|
||||||
|
### Tools
|
||||||
|
|
||||||
|
- **Static Analysis**: SonarQube, Semgrep, CodeQL
|
||||||
|
- **Dependency Scanning**: Snyk, Dependabot, npm audit
|
||||||
|
- **Secret Scanning**: git-secrets, truffleHog, GitGuardian
|
||||||
|
- **Runtime Protection**: OWASP ZAP, Burp Suite
|
||||||
|
|
||||||
|
### Standards
|
||||||
|
|
||||||
|
- **OWASP Top 10**: https://owasp.org/www-project-top-ten/
|
||||||
|
- **CWE Top 25**: https://cwe.mitre.org/top25/
|
||||||
|
- **NIST Guidelines**: https://www.nist.gov/cybersecurity
|
||||||
|
|
||||||
|
### Learning
|
||||||
|
|
||||||
|
- **OWASP Cheat Sheets**: https://cheatsheetseries.owasp.org/
|
||||||
|
- **PortSwigger Web Security Academy**: https://portswigger.net/web-security
|
||||||
|
- **Secure Code Warrior**: https://www.securecodewarrior.com/
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
Security in agentic workflows requires vigilance and layered defenses. By following these best practices—reviewing agent output, using security-focused agents and hooks, maintaining security steering files, and securing MCP servers—you can leverage the power of AI agents while maintaining strong security posture.
|
||||||
|
|
||||||
|
Remember: agents are tools that amplify your capabilities, but security remains your responsibility. Trust but verify, use defense in depth, and always prioritize security in your development workflow.
|
||||||
360
.kiro/docs/shortform-guide.md
Normal file
360
.kiro/docs/shortform-guide.md
Normal file
@@ -0,0 +1,360 @@
|
|||||||
|
# Quick Reference Guide
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Clone the repository
|
||||||
|
git clone https://github.com/yourusername/ecc-kiro-public-repo.git
|
||||||
|
cd ecc-kiro-public-repo
|
||||||
|
|
||||||
|
# Install to current project
|
||||||
|
./install.sh
|
||||||
|
|
||||||
|
# Install globally to ~/.kiro/
|
||||||
|
./install.sh ~
|
||||||
|
```
|
||||||
|
|
||||||
|
## Agents
|
||||||
|
|
||||||
|
### Swap to an Agent
|
||||||
|
|
||||||
|
```
|
||||||
|
/agent swap <agent-name>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Available Agents
|
||||||
|
|
||||||
|
| Agent | Model | Use For |
|
||||||
|
|-------|-------|---------|
|
||||||
|
| `planner` | Opus | Breaking down complex features into tasks |
|
||||||
|
| `code-reviewer` | Sonnet | Code quality and best practices review |
|
||||||
|
| `tdd-guide` | Sonnet | Test-driven development workflows |
|
||||||
|
| `security-reviewer` | Sonnet | Security audits and vulnerability checks |
|
||||||
|
| `architect` | Opus | System design and architecture decisions |
|
||||||
|
| `build-error-resolver` | Sonnet | Fixing build and compilation errors |
|
||||||
|
| `doc-updater` | Haiku | Updating documentation and comments |
|
||||||
|
| `refactor-cleaner` | Sonnet | Code refactoring and cleanup |
|
||||||
|
| `go-reviewer` | Sonnet | Go-specific code review |
|
||||||
|
| `python-reviewer` | Sonnet | Python-specific code review |
|
||||||
|
| `database-reviewer` | Sonnet | Database schema and query review |
|
||||||
|
| `e2e-runner` | Sonnet | End-to-end test creation and execution |
|
||||||
|
| `harness-optimizer` | Opus | Test harness optimization |
|
||||||
|
| `loop-operator` | Sonnet | Verification loop execution |
|
||||||
|
| `chief-of-staff` | Opus | Project coordination and planning |
|
||||||
|
| `go-build-resolver` | Sonnet | Go build error resolution |
|
||||||
|
|
||||||
|
## Skills
|
||||||
|
|
||||||
|
### Invoke a Skill
|
||||||
|
|
||||||
|
Type `/` in chat and select from the menu, or use:
|
||||||
|
|
||||||
|
```
|
||||||
|
#skill-name
|
||||||
|
```
|
||||||
|
|
||||||
|
### Available Skills
|
||||||
|
|
||||||
|
| Skill | Use For |
|
||||||
|
|-------|---------|
|
||||||
|
| `tdd-workflow` | Red-green-refactor TDD cycle |
|
||||||
|
| `security-review` | Comprehensive security audit |
|
||||||
|
| `verification-loop` | Continuous validation and improvement |
|
||||||
|
| `coding-standards` | Code style and standards enforcement |
|
||||||
|
| `api-design` | RESTful API design patterns |
|
||||||
|
| `frontend-patterns` | React/Vue/Angular best practices |
|
||||||
|
| `backend-patterns` | Server-side architecture patterns |
|
||||||
|
| `e2e-testing` | End-to-end testing strategies |
|
||||||
|
| `golang-patterns` | Go idioms and patterns |
|
||||||
|
| `golang-testing` | Go testing best practices |
|
||||||
|
| `python-patterns` | Python idioms and patterns |
|
||||||
|
| `python-testing` | Python testing (pytest, unittest) |
|
||||||
|
| `database-migrations` | Database schema evolution |
|
||||||
|
| `postgres-patterns` | PostgreSQL optimization |
|
||||||
|
| `docker-patterns` | Container best practices |
|
||||||
|
| `deployment-patterns` | Deployment strategies |
|
||||||
|
| `search-first` | Search-driven development |
|
||||||
|
| `agentic-engineering` | Agentic workflow patterns |
|
||||||
|
|
||||||
|
## Steering Files
|
||||||
|
|
||||||
|
### Auto-Loaded (Always Active)
|
||||||
|
|
||||||
|
- `coding-style.md` - Code organization and naming
|
||||||
|
- `development-workflow.md` - Dev process and PR workflow
|
||||||
|
- `git-workflow.md` - Commit conventions and branching
|
||||||
|
- `security.md` - Security best practices
|
||||||
|
- `testing.md` - Testing standards
|
||||||
|
- `patterns.md` - Design patterns
|
||||||
|
- `performance.md` - Performance guidelines
|
||||||
|
- `lessons-learned.md` - Project-specific patterns
|
||||||
|
|
||||||
|
### File-Match (Loaded for Specific Files)
|
||||||
|
|
||||||
|
- `typescript-patterns.md` - For `*.ts`, `*.tsx` files
|
||||||
|
- `python-patterns.md` - For `*.py` files
|
||||||
|
- `golang-patterns.md` - For `*.go` files
|
||||||
|
- `swift-patterns.md` - For `*.swift` files
|
||||||
|
|
||||||
|
### Manual (Invoke with #)
|
||||||
|
|
||||||
|
```
|
||||||
|
#dev-mode # Development context
|
||||||
|
#review-mode # Code review context
|
||||||
|
#research-mode # Research and exploration context
|
||||||
|
```
|
||||||
|
|
||||||
|
## Hooks
|
||||||
|
|
||||||
|
### View Hooks
|
||||||
|
|
||||||
|
Open the Agent Hooks panel in Kiro's sidebar.
|
||||||
|
|
||||||
|
### Available Hooks
|
||||||
|
|
||||||
|
| Hook | Trigger | Action |
|
||||||
|
|------|---------|--------|
|
||||||
|
| `quality-gate` | Manual | Run full quality check (build, types, lint, tests) |
|
||||||
|
| `typecheck-on-edit` | Save `*.ts`, `*.tsx` | Run TypeScript type check |
|
||||||
|
| `console-log-check` | Save `*.js`, `*.ts`, `*.tsx` | Check for console.log statements |
|
||||||
|
| `tdd-reminder` | Create `*.ts`, `*.tsx` | Remind to write tests first |
|
||||||
|
| `git-push-review` | Before shell command | Review before git push |
|
||||||
|
| `code-review-on-write` | After file write | Review written code |
|
||||||
|
| `auto-format` | Save `*.ts`, `*.tsx`, `*.js` | Auto-format with biome/prettier |
|
||||||
|
| `extract-patterns` | Agent stops | Suggest patterns for lessons-learned |
|
||||||
|
| `session-summary` | Agent stops | Summarize session |
|
||||||
|
| `doc-file-warning` | Before file write | Warn about documentation files |
|
||||||
|
|
||||||
|
### Enable/Disable Hooks
|
||||||
|
|
||||||
|
Toggle hooks in the Agent Hooks panel or edit `.kiro/hooks/*.kiro.hook` files.
|
||||||
|
|
||||||
|
## Scripts
|
||||||
|
|
||||||
|
### Run Scripts Manually
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Full quality check
|
||||||
|
.kiro/scripts/quality-gate.sh
|
||||||
|
|
||||||
|
# Format a file
|
||||||
|
.kiro/scripts/format.sh path/to/file.ts
|
||||||
|
```
|
||||||
|
|
||||||
|
## MCP Servers
|
||||||
|
|
||||||
|
### Configure MCP Servers
|
||||||
|
|
||||||
|
1. Copy example: `cp .kiro/settings/mcp.json.example .kiro/settings/mcp.json`
|
||||||
|
2. Edit `.kiro/settings/mcp.json` with your API keys
|
||||||
|
3. Restart Kiro or reconnect servers from MCP Server view
|
||||||
|
|
||||||
|
### Available MCP Servers (Example)
|
||||||
|
|
||||||
|
- `github` - GitHub API integration
|
||||||
|
- `sequential-thinking` - Enhanced reasoning
|
||||||
|
- `memory` - Persistent memory across sessions
|
||||||
|
- `context7` - Extended context management
|
||||||
|
- `vercel` - Vercel deployment
|
||||||
|
- `railway` - Railway deployment
|
||||||
|
- `cloudflare-docs` - Cloudflare documentation
|
||||||
|
|
||||||
|
## Common Workflows
|
||||||
|
|
||||||
|
### Feature Development
|
||||||
|
|
||||||
|
```
|
||||||
|
1. /agent swap planner
|
||||||
|
"Plan a user authentication feature"
|
||||||
|
|
||||||
|
2. /agent swap tdd-guide
|
||||||
|
#tdd-workflow
|
||||||
|
"Implement the authentication feature"
|
||||||
|
|
||||||
|
3. /agent swap code-reviewer
|
||||||
|
"Review the authentication implementation"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Bug Fix
|
||||||
|
|
||||||
|
```
|
||||||
|
1. /agent swap planner
|
||||||
|
"Investigate why login fails on mobile"
|
||||||
|
|
||||||
|
2. /agent swap build-error-resolver
|
||||||
|
"Fix the login bug"
|
||||||
|
|
||||||
|
3. /agent swap security-reviewer
|
||||||
|
"Ensure the fix is secure"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Security Audit
|
||||||
|
|
||||||
|
```
|
||||||
|
1. /agent swap security-reviewer
|
||||||
|
#security-review
|
||||||
|
"Audit the authentication module"
|
||||||
|
|
||||||
|
2. Review findings and fix issues
|
||||||
|
|
||||||
|
3. Update lessons-learned.md with patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
### Refactoring
|
||||||
|
|
||||||
|
```
|
||||||
|
1. /agent swap architect
|
||||||
|
"Analyze the user module architecture"
|
||||||
|
|
||||||
|
2. /agent swap refactor-cleaner
|
||||||
|
#verification-loop
|
||||||
|
"Refactor based on the analysis"
|
||||||
|
|
||||||
|
3. /agent swap code-reviewer
|
||||||
|
"Review the refactored code"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Tips
|
||||||
|
|
||||||
|
### Get the Most from Agents
|
||||||
|
|
||||||
|
- **Be specific about intent**: "Add user authentication with JWT" not "write some auth code"
|
||||||
|
- **Let agents plan**: Don't micromanage implementation details
|
||||||
|
- **Provide context**: Reference files with `#file:path/to/file.ts`
|
||||||
|
- **Iterate with feedback**: "The error handling needs improvement" not "rewrite everything"
|
||||||
|
|
||||||
|
### Maintain Quality
|
||||||
|
|
||||||
|
- **Enable hooks early**: Catch issues immediately
|
||||||
|
- **Use TDD workflow**: Tests document behavior and catch regressions
|
||||||
|
- **Update lessons-learned**: Capture patterns once, use forever
|
||||||
|
- **Review agent output**: Agents are powerful but not infallible
|
||||||
|
|
||||||
|
### Speed Up Development
|
||||||
|
|
||||||
|
- **Use specialized agents**: They have optimized prompts and tools
|
||||||
|
- **Chain agents**: planner → tdd-guide → code-reviewer
|
||||||
|
- **Leverage skills**: Complex workflows encoded as reusable patterns
|
||||||
|
- **Use context modes**: #dev-mode for speed, #review-mode for quality
|
||||||
|
|
||||||
|
## Troubleshooting
|
||||||
|
|
||||||
|
### Agent Not Available
|
||||||
|
|
||||||
|
```
|
||||||
|
# List available agents
|
||||||
|
/agent list
|
||||||
|
|
||||||
|
# Verify installation
|
||||||
|
ls .kiro/agents/
|
||||||
|
```
|
||||||
|
|
||||||
|
### Skill Not Appearing
|
||||||
|
|
||||||
|
```
|
||||||
|
# Verify installation
|
||||||
|
ls .kiro/skills/
|
||||||
|
|
||||||
|
# Check SKILL.md format
|
||||||
|
cat .kiro/skills/skill-name/SKILL.md
|
||||||
|
```
|
||||||
|
|
||||||
|
### Hook Not Triggering
|
||||||
|
|
||||||
|
1. Check hook is enabled in Agent Hooks panel
|
||||||
|
2. Verify file patterns match: `"patterns": ["*.ts", "*.tsx"]`
|
||||||
|
3. Check hook JSON syntax: `cat .kiro/hooks/hook-name.kiro.hook`
|
||||||
|
|
||||||
|
### Steering File Not Loading
|
||||||
|
|
||||||
|
1. Check frontmatter: `inclusion: auto` or `fileMatch` or `manual`
|
||||||
|
2. For fileMatch, verify pattern: `fileMatchPattern: "*.ts,*.tsx"`
|
||||||
|
3. For manual, invoke with: `#filename`
|
||||||
|
|
||||||
|
### Script Not Executing
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Make executable
|
||||||
|
chmod +x .kiro/scripts/*.sh
|
||||||
|
|
||||||
|
# Test manually
|
||||||
|
.kiro/scripts/quality-gate.sh
|
||||||
|
```
|
||||||
|
|
||||||
|
## Getting Help
|
||||||
|
|
||||||
|
- **Longform Guide**: `docs/longform-guide.md` - Deep dive on agentic workflows
|
||||||
|
- **Security Guide**: `docs/security-guide.md` - Security best practices
|
||||||
|
- **Migration Guide**: `docs/migration-from-ecc.md` - For Claude Code users
|
||||||
|
- **GitHub Issues**: Report bugs and request features
|
||||||
|
- **Kiro Documentation**: https://kiro.dev/docs
|
||||||
|
|
||||||
|
## Customization
|
||||||
|
|
||||||
|
### Add Your Own Agent
|
||||||
|
|
||||||
|
1. Create `.kiro/agents/my-agent.json`:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"name": "my-agent",
|
||||||
|
"description": "My custom agent",
|
||||||
|
"prompt": "You are a specialized agent for...",
|
||||||
|
"model": "claude-sonnet-4-5"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Use with: `/agent swap my-agent`
|
||||||
|
|
||||||
|
### Add Your Own Skill
|
||||||
|
|
||||||
|
1. Create `.kiro/skills/my-skill/SKILL.md`:
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
name: my-skill
|
||||||
|
description: My custom skill
|
||||||
|
---
|
||||||
|
|
||||||
|
# My Skill
|
||||||
|
|
||||||
|
Instructions for the agent...
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Use with: `/` menu or `#my-skill`
|
||||||
|
|
||||||
|
### Add Your Own Steering File
|
||||||
|
|
||||||
|
1. Create `.kiro/steering/my-rules.md`:
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
inclusion: auto
|
||||||
|
description: My custom rules
|
||||||
|
---
|
||||||
|
|
||||||
|
# My Rules
|
||||||
|
|
||||||
|
Rules and patterns...
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Auto-loaded in every conversation
|
||||||
|
|
||||||
|
### Add Your Own Hook
|
||||||
|
|
||||||
|
1. Create `.kiro/hooks/my-hook.kiro.hook`:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"name": "my-hook",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"description": "My custom hook",
|
||||||
|
"enabled": true,
|
||||||
|
"when": {
|
||||||
|
"type": "fileEdited",
|
||||||
|
"patterns": ["*.ts"]
|
||||||
|
},
|
||||||
|
"then": {
|
||||||
|
"type": "runCommand",
|
||||||
|
"command": "echo 'File edited'"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Toggle in Agent Hooks panel
|
||||||
139
.kiro/install.sh
Executable file
139
.kiro/install.sh
Executable file
@@ -0,0 +1,139 @@
|
|||||||
|
#!/bin/bash
|
||||||
|
#
|
||||||
|
# ECC Kiro Installer
|
||||||
|
# Installs Everything Claude Code workflows into a Kiro project.
|
||||||
|
#
|
||||||
|
# Usage:
|
||||||
|
# ./install.sh # Install to current directory
|
||||||
|
# ./install.sh /path/to/dir # Install to specific directory
|
||||||
|
# ./install.sh ~ # Install globally to ~/.kiro/
|
||||||
|
#
|
||||||
|
|
||||||
|
set -euo pipefail
|
||||||
|
|
||||||
|
# When globs match nothing, expand to empty list instead of the literal pattern
|
||||||
|
shopt -s nullglob
|
||||||
|
|
||||||
|
# Resolve the directory where this script lives (the repo root)
|
||||||
|
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
|
||||||
|
SOURCE_KIRO="$SCRIPT_DIR/.kiro"
|
||||||
|
|
||||||
|
# Target directory: argument or current working directory
|
||||||
|
TARGET="${1:-.}"
|
||||||
|
|
||||||
|
# Expand ~ to $HOME
|
||||||
|
if [ "$TARGET" = "~" ] || [[ "$TARGET" == "~/"* ]]; then
|
||||||
|
TARGET="${TARGET/#\~/$HOME}"
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Resolve to absolute path
|
||||||
|
TARGET="$(cd "$TARGET" 2>/dev/null && pwd || echo "$TARGET")"
|
||||||
|
|
||||||
|
echo "ECC Kiro Installer"
|
||||||
|
echo "=================="
|
||||||
|
echo ""
|
||||||
|
echo "Source: $SOURCE_KIRO"
|
||||||
|
echo "Target: $TARGET/.kiro/"
|
||||||
|
echo ""
|
||||||
|
|
||||||
|
# Subdirectories to create and populate
|
||||||
|
SUBDIRS="agents skills steering hooks scripts settings"
|
||||||
|
|
||||||
|
# Create all required .kiro/ subdirectories
|
||||||
|
for dir in $SUBDIRS; do
|
||||||
|
mkdir -p "$TARGET/.kiro/$dir"
|
||||||
|
done
|
||||||
|
|
||||||
|
# Counters for summary
|
||||||
|
agents=0; skills=0; steering=0; hooks=0; scripts=0; settings=0
|
||||||
|
|
||||||
|
# Copy agents (JSON for CLI, Markdown for IDE)
|
||||||
|
if [ -d "$SOURCE_KIRO/agents" ]; then
|
||||||
|
for f in "$SOURCE_KIRO/agents"/*.json "$SOURCE_KIRO/agents"/*.md; do
|
||||||
|
[ -f "$f" ] || continue
|
||||||
|
local_name=$(basename "$f")
|
||||||
|
if [ ! -f "$TARGET/.kiro/agents/$local_name" ]; then
|
||||||
|
cp "$f" "$TARGET/.kiro/agents/" 2>/dev/null || true
|
||||||
|
agents=$((agents + 1))
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Copy skills (directories with SKILL.md)
|
||||||
|
if [ -d "$SOURCE_KIRO/skills" ]; then
|
||||||
|
for d in "$SOURCE_KIRO/skills"/*/; do
|
||||||
|
[ -d "$d" ] || continue
|
||||||
|
skill_name="$(basename "$d")"
|
||||||
|
if [ ! -d "$TARGET/.kiro/skills/$skill_name" ]; then
|
||||||
|
mkdir -p "$TARGET/.kiro/skills/$skill_name"
|
||||||
|
cp "$d"* "$TARGET/.kiro/skills/$skill_name/" 2>/dev/null || true
|
||||||
|
skills=$((skills + 1))
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Copy steering files (markdown)
|
||||||
|
if [ -d "$SOURCE_KIRO/steering" ]; then
|
||||||
|
for f in "$SOURCE_KIRO/steering"/*.md; do
|
||||||
|
local_name=$(basename "$f")
|
||||||
|
if [ ! -f "$TARGET/.kiro/steering/$local_name" ]; then
|
||||||
|
cp "$f" "$TARGET/.kiro/steering/" 2>/dev/null || true
|
||||||
|
steering=$((steering + 1))
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Copy hooks (.kiro.hook files and README)
|
||||||
|
if [ -d "$SOURCE_KIRO/hooks" ]; then
|
||||||
|
for f in "$SOURCE_KIRO/hooks"/*.kiro.hook "$SOURCE_KIRO/hooks"/*.md; do
|
||||||
|
[ -f "$f" ] || continue
|
||||||
|
local_name=$(basename "$f")
|
||||||
|
if [ ! -f "$TARGET/.kiro/hooks/$local_name" ]; then
|
||||||
|
cp "$f" "$TARGET/.kiro/hooks/" 2>/dev/null || true
|
||||||
|
hooks=$((hooks + 1))
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Copy scripts (shell scripts) and make executable
|
||||||
|
if [ -d "$SOURCE_KIRO/scripts" ]; then
|
||||||
|
for f in "$SOURCE_KIRO/scripts"/*.sh; do
|
||||||
|
local_name=$(basename "$f")
|
||||||
|
if [ ! -f "$TARGET/.kiro/scripts/$local_name" ]; then
|
||||||
|
cp "$f" "$TARGET/.kiro/scripts/" 2>/dev/null || true
|
||||||
|
chmod +x "$TARGET/.kiro/scripts/$local_name" 2>/dev/null || true
|
||||||
|
scripts=$((scripts + 1))
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Copy settings (example files)
|
||||||
|
if [ -d "$SOURCE_KIRO/settings" ]; then
|
||||||
|
for f in "$SOURCE_KIRO/settings"/*; do
|
||||||
|
[ -f "$f" ] || continue
|
||||||
|
local_name=$(basename "$f")
|
||||||
|
if [ ! -f "$TARGET/.kiro/settings/$local_name" ]; then
|
||||||
|
cp "$f" "$TARGET/.kiro/settings/" 2>/dev/null || true
|
||||||
|
settings=$((settings + 1))
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Installation summary
|
||||||
|
echo "Installation complete!"
|
||||||
|
echo ""
|
||||||
|
echo "Components installed:"
|
||||||
|
echo " Agents: $agents"
|
||||||
|
echo " Skills: $skills"
|
||||||
|
echo " Steering: $steering"
|
||||||
|
echo " Hooks: $hooks"
|
||||||
|
echo " Scripts: $scripts"
|
||||||
|
echo " Settings: $settings"
|
||||||
|
echo ""
|
||||||
|
echo "Next steps:"
|
||||||
|
echo " 1. Open your project in Kiro"
|
||||||
|
echo " 2. Agents: Automatic in IDE, /agent swap in CLI"
|
||||||
|
echo " 3. Skills: Available via / menu in chat"
|
||||||
|
echo " 4. Steering files with 'auto' inclusion load automatically"
|
||||||
|
echo " 5. Toggle hooks in the Agent Hooks panel"
|
||||||
|
echo " 6. Copy desired MCP servers from .kiro/settings/mcp.json.example to .kiro/settings/mcp.json"
|
||||||
50
.kiro/settings/mcp.json.example
Normal file
50
.kiro/settings/mcp.json.example
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
{
|
||||||
|
"mcpServers": {
|
||||||
|
"bedrock-agentcore-mcp-server": {
|
||||||
|
"command": "uvx",
|
||||||
|
"args": [
|
||||||
|
"awslabs.amazon-bedrock-agentcore-mcp-server@latest"
|
||||||
|
],
|
||||||
|
"env": {
|
||||||
|
"FASTMCP_LOG_LEVEL": "ERROR"
|
||||||
|
},
|
||||||
|
"disabled": false,
|
||||||
|
"autoApprove": [
|
||||||
|
"search_agentcore_docs",
|
||||||
|
"fetch_agentcore_doc",
|
||||||
|
"manage_agentcore_memory"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
"strands-agents": {
|
||||||
|
"command": "uvx",
|
||||||
|
"args": [
|
||||||
|
"strands-agents-mcp-server"
|
||||||
|
],
|
||||||
|
"env": {
|
||||||
|
"FASTMCP_LOG_LEVEL": "INFO"
|
||||||
|
},
|
||||||
|
"disabled": false,
|
||||||
|
"autoApprove": [
|
||||||
|
"search_docs",
|
||||||
|
"fetch_doc"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
"awslabs.cdk-mcp-server": {
|
||||||
|
"command": "uvx",
|
||||||
|
"args": [
|
||||||
|
"awslabs.cdk-mcp-server@latest"
|
||||||
|
],
|
||||||
|
"env": {
|
||||||
|
"FASTMCP_LOG_LEVEL": "ERROR"
|
||||||
|
},
|
||||||
|
"disabled": false
|
||||||
|
},
|
||||||
|
"react-docs": {
|
||||||
|
"command": "npx",
|
||||||
|
"args": [
|
||||||
|
"-y",
|
||||||
|
"react-docs-mcp"
|
||||||
|
]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
Reference in New Issue
Block a user