← Back to Index

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- Details

component-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 derivation

deployment-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'"
    }
  }]
}
Ad

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 tests

MCP: 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)
The rule: If it contains team knowledge (conventions, workflows, hooks) - commit it. If it contains personal secrets (API tokens) - global config or .gitignore.

Onboarding a New Team Member

With this setup, a new developer's experience is:

  1. Clone the repo - all steering, hooks, skills, agents, and specs come along
  2. Set up personal MCP - add GitHub/Jira tokens to ~/.kiro/settings/mcp.json (one-time)
  3. 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:

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:

NeedMechanismWhy
"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"HookEvent-driven automation
"Kiro should follow this procedure when I ask"SkillOn-demand workflow instructions
"Kiro needs access to external service Z"MCP serverExtends capabilities
"Kiro needs Z only sometimes (context-heavy)"PowerOn-demand MCP + steering bundle
"Kiro should delegate X with restricted tools"Custom agentIsolated, constrained execution
"This feature needs structured planning + verification"SpecRequirements → 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

  1. Audit your current project's .kiro/ - what's there? What's missing?
  2. Start with steering - add one always-on file with your core conventions
  3. Add one hook - lint-on-save is the lowest-risk, highest-value starting point
  4. Create one skill - the commit-message skill is immediately useful
  5. Try a bugfix spec - next bug, use the bugfix spec workflow and observe the PBT verification
  6. 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.