P12: Kiro Powers Creator (Bundled Capabilities)
type: project id: P12 title: Kiro Powers Creator track: Kiro CLI Mastery difficulty: Advanced time_estimate: 2 weeks prerequisites: [P01-P11] knowledge_areas: [Powers, Plugin Systems, MCP, Steering, Distribution] tools: [Kiro CLI, GitHub] main_book: “Designing Distributed Systems by Brendan Burns” —
Learning Objectives
By completing this project, you will:
- Understand Kiro Powers as the unit of distribution for AI expertise and capabilities
- Master the power structure including MCP servers, steering files, and hooks bundled together
- Learn keyword-triggered activation for dynamic capability loading
- Build and publish your own Power to GitHub for sharing
- Develop practices for versioning and updating distributed AI capabilities
Deep Theoretical Foundation
The Problem: Sharing AI Expertise
Individual Kiro configurations are powerful, but they’re trapped on one machine:
- Your custom MCP servers don’t travel with you
- Your steering files (coding conventions) stay local
- Your hooks (pre/post actions) aren’t shared with your team
- Every new machine means reconfiguration
What is a Kiro Power?
A Power is a portable bundle of AI capabilities:
┌─────────────────────────────────────────────────────────────────┐
│ KIRO POWER │
│ (e.g., "nextjs-power") │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ MCP SERVERS │ │ STEERING FILES │ │ HOOKS │ │
│ │ │ │ │ │ │ │
│ │ • nextjs-docs │ │ • conventions │ │ • app-router- │ │
│ │ • vercel-api │ │ • best-practs │ │ validator │ │
│ │ • prisma-db │ │ • file-struct │ │ • build-check │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
│ │
│ TRIGGERS: ["next", "nextjs", "vercel", "app router"] │
│ │
└─────────────────────────────────────────────────────────────────┘
Powers are to Kiro what plugins are to VS Code - but for AI capabilities, not editor features.
The Architecture of Distribution
┌─────────────────────────────────────────────────────────────────┐
│ POWER DISTRIBUTION FLOW │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Creator GitHub Users │
│ │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ Build │ push │ Repo │ /powers │ Install│ │
│ │ Power │ ──────────► │ │ ◄─────────── │ │ │
│ └──────────┘ └──────────┘ └────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ Test │ │ Releases │ │ Use │ │
│ │ Locally │ │ Versions │ │ Power │ │
│ └──────────┘ └──────────┘ └────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Power Components Explained
1. MCP Servers (Tools)
MCP servers give Kiro new abilities:
MCP Server: nextjs-docs
├── Purpose: Search Next.js documentation
├── Tools:
│ ├── search_docs(query) → relevant doc sections
│ ├── get_api_reference(function) → API details
│ └── get_example(topic) → code examples
└── Transport: stdio (bundled binary)
2. Steering Files (Behavior)
Steering files shape how Kiro writes code:
# nextjs-conventions.md
## File Structure
- Use App Router directory structure
- Colocate components with pages
- Keep server components as default
## Coding Style
- Prefer server components over client
- Use 'use client' directive explicitly
- Implement loading.tsx for suspense
3. Hooks (Automation)
Hooks run before/after Kiro actions:
// hooks/app-router-validator.ts
export const afterFileWrite = async (filePath: string) => {
if (filePath.includes('/app/') && filePath.endsWith('.tsx')) {
// Validate App Router conventions
await validateAppRouterFile(filePath);
}
};
Keyword-Triggered Activation
Powers don’t load by default - they activate when you mention trigger keywords:
User: "How do I create a Next.js API route?"
│
▼
┌─────────────────────┐
│ Keyword Detection │
│ Found: "Next.js" │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Match Triggers │
│ nextjs-power: │
│ ["next", "nextjs"] │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Activate Power │
│ • Load MCP servers │
│ • Apply steering │
│ • Enable hooks │
└─────────────────────┘
Real-World Analogy: The Specialized Toolkit
Think of a Power like a specialized toolkit:
- Plumber’s Kit: Pipe wrenches, plungers, Teflon tape (tools), plumbing code book (steering), “check for leaks after” checklist (hooks)
- Electrician’s Kit: Multimeter, wire strippers, voltage tester (tools), NEC codebook (steering), “verify power off first” protocol (hooks)
You don’t carry every toolkit everywhere - you bring the one you need. Powers work the same way.
Historical Context: Plugin Evolution
1990s: IDE Plugins (Eclipse, Visual Studio)
└── Extended editor functionality
2010s: Package Managers (npm, pip, gem)
└── Distributed code libraries
2020s: AI Extensions (GPT plugins, Claude tools)
└── Extended AI capabilities
2025: AI Powers (Kiro Powers, Claude Skills)
└── Bundled AI expertise + tools + behavior
Powers represent the next evolution: not just tools, but complete expertise packages.
Book Reference
“Designing Distributed Systems” by Brendan Burns discusses patterns for packaging and distributing system capabilities. Powers apply these patterns to AI expertise - encapsulating knowledge, tools, and behavior into distributable units.
Complete Project Specification
What You’re Building
A complete, publishable Kiro Power for a framework or domain of your choice:
- Framework Power (recommended for learning):
- Next.js Power
- Django Power
- FastAPI Power
- React Native Power
- Domain Power (for specialized knowledge):
- AWS Infrastructure Power
- GraphQL Power
- Testing Power (Jest/Vitest)
Power Structure
your-power/
├── power.json # Power manifest
├── README.md # Documentation
├── mcp/
│ ├── mcp.json # MCP server configuration
│ └── servers/
│ ├── docs-server/ # Documentation MCP
│ └── api-server/ # API integration MCP
├── steering/
│ ├── conventions.md # Coding conventions
│ ├── patterns.md # Design patterns
│ └── examples.md # Code examples
├── hooks/
│ ├── hooks.json # Hook configuration
│ ├── validators/ # Validation hooks
│ └── generators/ # Generation hooks
└── tests/
└── power.test.ts # Power tests
Expected Behavior
# Installation
$ kiro-cli
> /powers add https://github.com/yourname/nextjs-power
Installing power: nextjs-power v1.0.0
├── MCP Servers: 2 loaded
│ ├── nextjs-docs (documentation search)
│ └── vercel-api (deployment integration)
├── Steering: 3 files applied
│ ├── conventions.md
│ ├── patterns.md
│ └── examples.md
├── Hooks: 1 enabled
│ └── app-router-validator
Power installed successfully!
Triggers: "next", "nextjs", "vercel", "app router", "server components"
# Usage (keyword triggers activation)
> "How do I implement a server component in Next.js?"
[Power: nextjs-power activated]
[nextjs-docs] Searching documentation...
Based on Next.js 14 App Router patterns:
Server Components are the default in the App Router...
[Provides expert-level, docs-backed response]
Solution Architecture
Component Diagram
┌─────────────────────────────────────────────────────────────────┐
│ POWER ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ power.json (Manifest) │
│ ┌─────────────────────────────────────────────────────────────┐│
│ │ { ││
│ │ "name": "nextjs-power", ││
│ │ "version": "1.0.0", ││
│ │ "triggers": ["next", "nextjs", "vercel"], ││
│ │ "mcp": "./mcp/mcp.json", ││
│ │ "steering": ["./steering/*.md"], ││
│ │ "hooks": "./hooks/hooks.json" ││
│ │ } ││
│ └─────────────────────────────────────────────────────────────┘│
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ MCP Config │ │ Steering │ │ Hooks │ │
│ │ │ │ │ │ │ │
│ │ mcp.json: │ │ conventions: │ │ hooks.json: │ │
│ │ { │ │ # File names │ │ { │ │
│ │ "servers":[ │ │ - Use kebab │ │ "afterFile │ │
│ │ {...} │ │ - page.tsx │ │ Write": [ │ │
│ │ ] │ │ │ │ "validate"│ │
│ │ } │ │ patterns: │ │ ] │ │
│ │ │ │ # Use server │ │ } │ │
│ │ │ │ components │ │ │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
│ │ │ │ │
│ └───────────────┼───────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐│
│ │ KIRO RUNTIME ││
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ││
│ │ │ MCP Loader │ │ Steering │ │ Hook │ ││
│ │ │ │ │ Injector │ │ Executor │ ││
│ │ └─────────────┘ └─────────────┘ └─────────────┘ ││
│ └─────────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────────┘
Data Flow: Power Installation
/powers add <url>
│
▼
┌─────────────────┐
│ Fetch Repo │ ──► Clone or download from GitHub
└────────┬────────┘
│
▼
┌─────────────────┐
│ Parse Manifest │ ──► Read power.json
└────────┬────────┘
│
▼
┌─────────────────┐
│ Validate │ ──► Check structure, versions
└────────┬────────┘
│
▼
┌─────────────────┐
│ Install MCP │ ──► Register MCP servers
└────────┬────────┘
│
▼
┌─────────────────┐
│ Load Steering │ ──► Add to steering context
└────────┬────────┘
│
▼
┌─────────────────┐
│ Register Hooks │ ──► Enable hook callbacks
└────────┬────────┘
│
▼
┌─────────────────┐
│ Index Triggers │ ──► Map keywords to power
└─────────────────┘
Data Flow: Power Activation
User Message: "Create a Next.js API route"
│
▼
┌─────────────────────┐
│ Tokenize Message │
│ ["create", "next", │
│ "api", "route"] │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Match Triggers │
│ "next" → nextjs- │
│ power │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Load Power Context │
│ • Start MCP servers│
│ • Inject steering │
│ • Arm hooks │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Process Request │
│ with Power active │
└─────────────────────┘
Key Interfaces
| Interface | Purpose | Location |
|---|---|---|
power.json |
Manifest describing the power | Root |
mcp.json |
MCP server configuration | mcp/ |
*.md steering |
Behavioral instructions | steering/ |
hooks.json |
Hook definitions | hooks/ |
/powers add |
Install a power | Kiro CLI |
/powers list |
List installed powers | Kiro CLI |
/powers remove |
Uninstall a power | Kiro CLI |
Technology Choices
| Component | Choice | Reason |
|---|---|---|
| Distribution | GitHub | Universal, versioned, familiar |
| Manifest | JSON | Structured, parseable |
| Steering | Markdown | Human-readable, AI-friendly |
| MCP Servers | TypeScript/Node | Rich ecosystem |
| Hooks | TypeScript | Type-safe, testable |
Phased Implementation Guide
Phase 1: Foundation - Understanding Power Structure
Goal: Create the basic power structure locally.
Step 1.1: Create Power Directory
mkdir nextjs-power
cd nextjs-power
# Create structure
mkdir -p mcp/servers/docs-server
mkdir -p steering
mkdir -p hooks
mkdir -p tests
Step 1.2: Create Power Manifest
// power.json
{
"name": "nextjs-power",
"version": "1.0.0",
"description": "Expert Next.js 14 App Router assistance",
"author": "Your Name",
"repository": "https://github.com/yourname/nextjs-power",
"triggers": [
"next",
"nextjs",
"next.js",
"vercel",
"app router",
"server components",
"client components"
],
"mcp": "./mcp/mcp.json",
"steering": [
"./steering/conventions.md",
"./steering/patterns.md",
"./steering/examples.md"
],
"hooks": "./hooks/hooks.json",
"kiroVersion": ">=1.0.0"
}
Hint: triggers are lowercase keywords. Include common variations and abbreviations.
Step 1.3: Create Basic Steering
// steering/conventions.md
# Next.js Coding Conventions
## File Naming
- Use kebab-case for directories: `user-profile/`
- Special files: `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`
- Colocate components: `user-profile/user-avatar.tsx`
## Component Defaults
- Prefer Server Components (no directive needed)
- Add `'use client'` only when necessary
- Keep data fetching in server components
## Data Fetching
- Use `fetch` with built-in caching
- Prefer `generateStaticParams` for static pages
- Use `revalidate` for ISR patterns
Hint: Steering files are included in Kiro’s context. Be concise but specific.
Phase 2: Core Functionality - Building MCP and Hooks
Goal: Add functional MCP servers and hooks to your power.
Step 2.1: Create MCP Configuration
// mcp/mcp.json
{
"servers": [
{
"name": "nextjs-docs",
"description": "Search Next.js documentation",
"command": "node",
"args": ["./mcp/servers/docs-server/index.js"],
"transport": "stdio"
}
]
}
Step 2.2: Implement a Simple MCP Server
// mcp/servers/docs-server/index.ts
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
const server = new Server({
name: 'nextjs-docs',
version: '1.0.0',
}, {
capabilities: {
tools: {}
}
});
// Register tools
server.setRequestHandler('tools/list', async () => ({
tools: [
{
name: 'search_docs',
description: 'Search Next.js documentation',
inputSchema: {
type: 'object',
properties: {
query: { type: 'string', description: 'Search query' }
},
required: ['query']
}
}
]
}));
server.setRequestHandler('tools/call', async (request) => {
if (request.params.name === 'search_docs') {
const query = request.params.arguments.query;
// Implement actual search logic
return {
content: [
{ type: 'text', text: `Results for: ${query}\n...` }
]
};
}
throw new Error(`Unknown tool: ${request.params.name}`);
});
// Start server
const transport = new StdioServerTransport();
server.connect(transport);
Hint: Start with a simple implementation. You can enhance the MCP server later.
Step 2.3: Create Hooks Configuration
// hooks/hooks.json
{
"afterFileWrite": [
{
"name": "validate-app-router",
"match": "**/app/**/*.tsx",
"handler": "./hooks/validators/app-router.js"
}
]
}
// hooks/validators/app-router.ts
import * as fs from 'fs';
export default async function validate(filePath: string): Promise<void> {
const content = fs.readFileSync(filePath, 'utf-8');
// Check for common issues
const issues: string[] = [];
// Issue 1: Using useState without 'use client'
if (content.includes('useState') && !content.includes("'use client'")) {
issues.push("File uses useState but missing 'use client' directive");
}
// Issue 2: Importing from 'next/router' instead of 'next/navigation'
if (content.includes("from 'next/router'")) {
issues.push("Use 'next/navigation' instead of 'next/router' in App Router");
}
if (issues.length > 0) {
console.warn(`[nextjs-power] Validation issues in ${filePath}:`);
issues.forEach(issue => console.warn(` - ${issue}`));
}
}
Hint: Hooks run automatically. Keep them fast and non-blocking.
Phase 3: Polish and Distribution
Goal: Test locally, document, and publish to GitHub.
Step 3.1: Test Locally
# Install your power locally for testing
$ kiro-cli
> /powers add ./nextjs-power
# Verify installation
> /powers list
Installed Powers:
nextjs-power v1.0.0 (local)
Triggers: next, nextjs, vercel...
# Test activation
> "How do I create a dynamic route in Next.js?"
[Power: nextjs-power activated]
...
Hint: Test with various trigger phrases to ensure activation works.
Step 3.2: Create Documentation
// README.md
# Next.js Power for Kiro CLI
Expert Next.js 14 App Router assistance for Kiro.
## Installation
\```bash
kiro-cli
> /powers add https://github.com/yourname/nextjs-power
\```
## Features
### MCP Servers
- **nextjs-docs**: Search official Next.js documentation
### Steering
- App Router conventions
- Server/Client component patterns
- Data fetching best practices
### Hooks
- **app-router-validator**: Validates App Router patterns
## Triggers
This power activates when you mention:
- next, nextjs, next.js
- vercel
- app router
- server components, client components
## Examples
\```
> "Create a dynamic blog post page with Next.js"
[Power: nextjs-power activated]
...
\```
## License
MIT
Step 3.3: Publish to GitHub
# Initialize git repo
git init
git add .
git commit -m "Initial release of nextjs-power v1.0.0"
# Create GitHub repo and push
gh repo create nextjs-power --public
git push -u origin master
# Create a release
gh release create v1.0.0 --title "v1.0.0" --notes "Initial release"
Hint: Use GitHub releases for versioning. Users can install specific versions.
Step 3.4: Announce and Share
# Others can now install your power
$ kiro-cli
> /powers add https://github.com/yourname/nextjs-power
# Or a specific version
> /powers add https://github.com/yourname/nextjs-power@v1.0.0
Testing Strategy
Unit Testing
// tests/power.test.ts
import { validatePowerManifest } from '@kiro/power-tools';
import manifest from '../power.json';
describe('Power Manifest', () => {
test('has required fields', () => {
expect(manifest.name).toBeDefined();
expect(manifest.version).toMatch(/^\d+\.\d+\.\d+$/);
expect(manifest.triggers).toBeInstanceOf(Array);
expect(manifest.triggers.length).toBeGreaterThan(0);
});
test('triggers are lowercase', () => {
manifest.triggers.forEach(trigger => {
expect(trigger).toBe(trigger.toLowerCase());
});
});
});
Integration Testing
# Test power installation
$ kiro-cli --test
> /powers add ./nextjs-power
# Expect: Success message with components listed
# Test activation
> "Help with Next.js routing"
# Expect: Power activation message
# Test MCP tool
> [Manually invoke MCP tool]
# Expect: Tool returns results
Validation Checklist
[ ] power.json is valid JSON
[ ] All referenced files exist
[ ] MCP servers start successfully
[ ] Steering files are valid Markdown
[ ] Hooks execute without errors
[ ] Triggers activate the power
[ ] Power installs from GitHub URL
[ ] Power uninstalls cleanly
Common Pitfalls & Debugging
Pitfall 1: Triggers Too Specific
Problem: Power doesn’t activate because triggers are too narrow.
// Bad: Only exact matches
"triggers": ["next.js 14 app router"]
// Good: Multiple variations
"triggers": ["next", "nextjs", "next.js", "app router"]
Solution: Include common variations, abbreviations, and related terms.
Pitfall 2: MCP Server Won’t Start
Problem: MCP server fails silently or crashes.
Debug Steps:
# Test server manually
cd mcp/servers/docs-server
node index.js
# Check for missing dependencies
npm ls
# Enable verbose logging
DEBUG=* node index.js
Pitfall 3: Hooks Block Execution
Problem: Slow hooks make Kiro feel laggy.
Solution: Keep hooks fast (<100ms). Use async operations for slow tasks.
// Bad: Blocking
const result = execSync('npm run lint');
// Good: Non-blocking
exec('npm run lint', (error, stdout) => {
if (error) console.warn('Lint issues found');
});
Pitfall 4: Steering Too Long
Problem: Steering files consume too much context.
Solution: Be concise. Use bullet points. Prioritize critical conventions.
// Bad: Verbose explanations
The App Router in Next.js 14 represents a paradigm shift in how we
think about routing in React applications. Unlike the Pages Router
which used a file-system based routing approach...
// Good: Concise rules
## App Router Rules
- Default to Server Components
- Add 'use client' only for interactivity
- Use loading.tsx for suspense boundaries
Extensions & Challenges
Extension 1: Multi-Framework Power
Create a power that supports multiple related frameworks:
{
"name": "react-ecosystem-power",
"triggers": ["react", "next", "remix", "gatsby"],
"mcp": {
"servers": [
{ "name": "react-docs", "activate": ["react"] },
{ "name": "nextjs-docs", "activate": ["next"] },
{ "name": "remix-docs", "activate": ["remix"] }
]
}
}
Extension 2: Team Power with Private Features
Create a power with enterprise features:
{
"name": "company-standards-power",
"private": true,
"authentication": "github-org",
"steering": [
"./steering/public-conventions.md",
"./steering/internal-patterns.md"
]
}
Extension 3: Power Composition
Create powers that extend other powers:
{
"name": "fullstack-power",
"extends": [
"https://github.com/kiro/nextjs-power",
"https://github.com/kiro/prisma-power"
],
"steering": ["./steering/fullstack-patterns.md"]
}
Challenge: Production-Grade Power
Build a power that:
- Has 100% test coverage
- Includes comprehensive documentation
- Supports multiple versions of the framework
- Has a changelog and semantic versioning
- Gets installed by >10 other developers
Real-World Connections
How Professionals Use This
At Vercel: Internal Kiro Powers bundle Next.js expertise, Vercel-specific deployment patterns, and integration with their toolchain.
At Consulting Firms: Powers encode client coding standards, ensuring all developers (human and AI) follow the same conventions.
In Open Source: Framework maintainers publish official Powers alongside their frameworks.
Industry Examples
- Kiro Powers Registry: Official powers from AWS and partners (Datadog, Figma, Stripe)
- Community Powers: Open-source powers for frameworks, libraries, and domains
- Enterprise Powers: Private powers encoding organizational standards
The Power Ecosystem
┌─────────────────────────────────────────────────────────────────┐
│ POWER ECOSYSTEM │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Official Community Enterprise │
│ Powers Powers Powers │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ AWS │ │ nextjs- │ │ acme-corp│ │
│ │ Bedrock │ │ power │ │ standards│ │
│ ├──────────┤ ├──────────┤ ├──────────┤ │
│ │ Datadog │ │ prisma- │ │ internal │ │
│ │ │ │ power │ │ patterns │ │
│ ├──────────┤ ├──────────┤ ├──────────┤ │
│ │ Stripe │ │ graphql- │ │ security │ │
│ │ │ │ power │ │ hooks │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ /powers add /powers add private registry │
│ aws/bedrock user/nextjs company.kiro.dev │
│ │
└─────────────────────────────────────────────────────────────────┘
Self-Assessment Checklist
Conceptual Understanding
- Can you explain what a Kiro Power is and its three components (MCP, steering, hooks)?
- Why do Powers use keyword-triggered activation instead of always loading?
- What’s the difference between steering files and MCP servers?
- How does the Power distribution model differ from traditional plugins?
Practical Skills
- Can you create a valid
power.jsonmanifest? - Can you implement a basic MCP server for a Power?
- Can you write effective steering files that fit in context?
- Can you create and test hooks for validation or generation?
Advanced Competency
- Can you design trigger keywords for maximum activation coverage?
- Can you test a Power locally before publishing?
- Can you version and release a Power on GitHub?
- Can you troubleshoot Power installation failures?
Mastery Indicators
- You’ve published a Power used by others
- You maintain multiple versions with changelogs
- Your Power has comprehensive tests
- You receive and incorporate community feedback
- Other developers extend or compose with your Power
Summary
Kiro Powers are the distribution mechanism for AI expertise. By bundling MCP servers, steering files, and hooks into portable packages, you can:
- Share your AI configurations across machines
- Distribute best practices to your team
- Contribute expertise to the community
- Build on the work of others
Master Powers, and you become a contributor to the AI development ecosystem.
Next Project: P13: Tangent Mode Explorer - Master context isolation for side conversations