Lesson 16
Capstone - Designing a Team Kiro Setup
The Scenario
You're setting up Kiro for an Angular 18 project. The team has 5 developers, uses Jira for tickets, GitHub for PRs, and deploys to AWS. You want to design the full .kiro/ configuration that ships with the repo - so any team member who clones the project gets a properly configured Kiro experience out of the box.
Note: This example uses Angular, but the patterns apply to any framework. Replace Angular-specific conventions (standalone components, signals, ng lint) with your stack's equivalents - the structure and decision-making are universal.
This is the design exercise. Everything you've learned comes together here.
The Complete .kiro/ Directory
.kiro/
├── steering/
│ ├── conventions.md # Always-on: team-wide code standards
│ ├── architecture.md # Always-on: project structure, key decisions
│ ├── component-patterns.md # fileMatch: "src/app/**/*.component.ts"
│ ├── service-patterns.md # fileMatch: "src/app/**/*.service.ts"
│ ├── testing-standards.md # fileMatch: "**/*.spec.ts"
│ ├── api-layer.md # fileMatch: "src/app/services/api/**"
│ └── deployment-guide.md # Manual: only when deploying
│
├── hooks/
│ ├── lint-on-save.json # PostFileSave: run ng lint on .ts/.html
│ ├── test-after-task.json # PostTaskExec: run affected tests
│ └── protect-prod-config.json # PreToolUse: gate writes to environment.prod.ts
│
├── skills/
│ ├── commit-message.md # Generate commit messages from diff
│ ├── pr-review.md # Review PR against team standards
│ └── new-feature.md # Scaffold a new feature module
│
├── agents/
│ └── researcher.md # Read-only exploration agent
│
├── settings/
│ └── mcp.json # MCP servers (project-specific only)
│
└── specs/
├── auth--user-login/
├── commerce--order-management/
└── ...Layer by Layer: Design Decisions
Steering: What Kiro Always Knows
conventions.md (always-on) - kept short, cross-cutting:
---
inclusion: auto
---
# Team Conventions
- Angular 18 with standalone components
- State management: Angular signals (not NgRx for new code)
- HTTP: HttpClient with typed responses, catchError in services
- Styling: SCSS with design tokens from @company/tokens
- Testing: Jest with Testing Library, property-based tests for business logic
- Package manager: pnpm
- Commit format: [branch-name] Short title\n\n- Detailscomponent-patterns.md (fileMatch) - only loads when working on components:
---
inclusion: fileMatch
fileMatchPattern: "src/app/**/*.component.ts"
---
# Component Patterns
- Always standalone (no NgModules)
- Use inject() not constructor injection
- Use signals for local state
- OnPush change detection for all components
- Template: inline for <20 lines, separate file otherwise
- Prefer computed() over manual derivationdeployment-guide.md (manual) - large, only needed occasionally:
---
inclusion: manual
---
# Deployment Guide
Refer to deployment procedures in #[[file:docs/deployment/runbook.md]]
...Hooks: What Happens Automatically
lint-on-save.json - catch issues immediately:
{
"version": "v1",
"hooks": [{
"name": "Lint on Save",
"trigger": "PostFileSave",
"matcher": "\\.(ts|html)$",
"action": { "type": "command", "command": "bash -c 'FILE=$(cat | jq -r .filePath); npx ng lint --files \"$FILE\"'" }
}]
}test-after-task.json - verify spec tasks:
{
"version": "v1",
"hooks": [{
"name": "Run Tests After Task",
"trigger": "PostTaskExec",
"action": { "type": "command", "command": "npx jest --passWithNoTests" }
}]
}protect-prod-config.json - safety gate:
{
"version": "v1",
"hooks": [{
"name": "Protect Production Config",
"trigger": "PreToolUse",
"matcher": "fs_write|str_replace",
"action": {
"type": "command",
"command": "bash -c 'INPUT=$(cat); if echo \"$INPUT\" | grep -q \"environment.prod\"; then echo \"Modifying production config requires confirmation\" >&2; exit 2; fi; exit 0'"
}
}]
}Skills: Reusable Team Workflows
commit-message.md:
---
name: commit-message
description: Generate a commit message from the current changes
argument-hint: "Any extra context about this change?"
---
## Generate Commit Message
1. Get the current branch: `git rev-parse --abbrev-ref HEAD`
2. Get the diff: `git diff --cached` (or `git diff` if nothing staged)
3. Format as:
```
[branch-name] Short imperative title (max 72 chars)
- What changed (files/areas)
- Why it changed (intent)
- Any trade-offs or decisions made
```new-feature.md:
---
name: new-feature
description: Scaffold a new feature module with component, service, routes, and tests
argument-hint: "Feature name, e.g. 'user-settings'"
---
## Scaffold New Feature
When asked to create a new feature:
1. Create directory: src/app/features/{name}/
2. Generate:
- {name}.component.ts (standalone, OnPush)
- {name}.service.ts (inject HttpClient)
- {name}.routes.ts (lazy-loaded route)
- {name}.component.spec.ts (Testing Library)
3. Register the route in app.routes.ts
4. Run lint and testsMCP: External Tool Access
.kiro/settings/mcp.json - project-specific servers only (shared ones live in ~/.kiro/settings/mcp.json):
{
"mcpServers": {
"project-docs": {
"command": "node",
"args": ["./tools/docs-mcp-server/dist/index.js"],
"disabled": false
}
}
}Shared servers (GitHub, Jira) go in each developer's global config - not committed to git (contains tokens).
Custom Agents: Specialised Delegation
researcher.md - read-only exploration:
---
description: Explore and analyse code without making changes
tools:
- read_file
- grep_search
- file_search
- list_directory
---
You are a read-only research agent for this Angular project.
Explore the codebase and provide analysis. You cannot modify files or run commands.
When investigating, always check: component hierarchy, service dependencies, route structure.What Goes in Git vs What Doesn't
| Committed to git (team-shared) | NOT committed (.gitignore) |
|---|---|
.kiro/steering/ | ~/.kiro/settings/mcp.json (has tokens) |
.kiro/hooks/ | Any file with API keys or secrets |
.kiro/skills/ | |
.kiro/agents/ | |
.kiro/specs/ | |
.kiro/settings/mcp.json (if no secrets) |
Onboarding a New Team Member
With this setup, a new developer's experience is:
- Clone the repo - all steering, hooks, skills, agents, and specs come along
- Set up personal MCP - add GitHub/Jira tokens to
~/.kiro/settings/mcp.json(one-time) - Start coding - Kiro already knows the conventions, runs lint on save, uses the right patterns
No "read the wiki." No "ask Dave how we do X." The configuration IS the onboarding.
Evolution Over Time
This isn't a one-time setup. The .kiro/ directory evolves with the project:
- New pattern emerges? - Add a steering file
- Team keeps making the same mistake? - Add a hook or agent-type PreToolUse prompt
- Repeating a workflow manually? - Create a skill
- New external tool needed? - Add MCP server (or power if occasional use)
- Standards change? - Update steering, Kiro adapts immediately
Treat .kiro/ like any other code - review changes in PRs, discuss in standups, iterate.
The Decision Framework
When you encounter a need, this is how to choose the right mechanism:
| Need | Mechanism | Why |
|---|---|---|
| "Kiro should always know X" | Steering (auto) | Persistent background knowledge |
| "Kiro should know X when working on Y files" | Steering (fileMatch) | Conditional, saves tokens |
| "Kiro should do X automatically when Y happens" | Hook | Event-driven automation |
| "Kiro should follow this procedure when I ask" | Skill | On-demand workflow instructions |
| "Kiro needs access to external service Z" | MCP server | Extends capabilities |
| "Kiro needs Z only sometimes (context-heavy)" | Power | On-demand MCP + steering bundle |
| "Kiro should delegate X with restricted tools" | Custom agent | Isolated, constrained execution |
| "This feature needs structured planning + verification" | Spec | Requirements → design → PBT verification |
Your Tangible Win
You've now seen every Kiro concept applied together in a realistic configuration. You have a complete reference design you can adapt for your own Angular project, a decision framework for choosing mechanisms, and an understanding of how the pieces connect.
You started this course knowing how to use Kiro for code generation. You now know how to shape Kiro - its knowledge, its automation, its tools, its constraints, and its verification - for yourself and your team.
What To Do Next
- Audit your current project's
.kiro/- what's there? What's missing? - Start with steering - add one always-on file with your core conventions
- Add one hook - lint-on-save is the lowest-risk, highest-value starting point
- Create one skill - the commit-message skill is immediately useful
- Try a bugfix spec - next bug, use the bugfix spec workflow and observe the PBT verification
- Set up Jira MCP - connect Kiro to your ticket system (see MCP Setup Guides)
Course Complete
16 lessons covering: steering, context management, hooks, skills, MCP (using + building), powers, sub-agents, custom agents, ACP, property-based testing, specs as living artifacts, model selection, multi-root workspaces, Kiro CLI, and this capstone.
If you want to go deeper on any topic (especially PBT or spec strategy), come back to this workspace and ask. The learning records track where you are, and new lessons can be added.