Manages AWS Kiro spec files including requirements.md (EARS), design.md, tasks.md, and steering context.md for IDE sync and AI agent workflows.
npx claudepluginhub melodic-software/claude-code-plugins --plugin spec-driven-developmentThis skill is limited to using the following tools:
AWS Kiro specification patterns, file structure, and synchronization with canonical model.
Synchronizes canonical specs with AWS Kiro format (.kiro/requirements.md, design.md, tasks.md). Supports import, export, bidirectional sync with conflict detection and dry-run.
Guides feature development from idea to implementation: creates EARS requirements, design documents, and task lists in .kiro/specs/.
Transforms ideas into structured specifications (requirements, design, tasks) before implementation. Use when building features, fixing bugs, refactoring, or designing systems.
Share bugs, ideas, or general feedback.
AWS Kiro specification patterns, file structure, and synchronization with canonical model.
Keywords: Kiro, AWS Kiro, requirements.md, design.md, tasks.md, steering files, Kiro IDE, Kiro agent, Kiro sync, spec generation, agentic development, Kiro hooks
Use this skill when:
Kiro is an agentic IDE developed by AWS that uses specification-driven development. It generates three interconnected files:
.kiro/
├── specs/
│ ├── requirements.md # EARS-formatted requirements
│ ├── design.md # Technical implementation design
│ └── tasks.md # Executable task breakdown
└── steering/
└── context.md # Agent steering context
| File | Purpose | Format |
|---|---|---|
requirements.md | Requirements using EARS patterns | EARS syntax in markdown |
design.md | Technical design and architecture | Markdown with diagrams |
tasks.md | Executable task checklist | Markdown checkboxes |
Kiro uses EARS (Easy Approach to Requirements Syntax) for requirements. All six patterns are supported:
The system SHALL...WHILE <condition>, the system SHALL...WHEN <trigger>, the system SHALL...IF <condition>, THEN the system SHALL...WHERE <feature>, the system SHALL...Steering files provide context to the Kiro agent:
# Requirements: <Feature Name>
## Context
<Problem statement and background>
## Functional Requirements
### FR-1: <Requirement Title>
**Pattern:** Event-Driven
**Priority:** Must
WHEN the user submits a form, the system SHALL validate all required fields.
#### Acceptance Criteria
- [ ] AC-1.1: Given valid input, when submitted, then success message shown
- [ ] AC-1.2: Given invalid input, when submitted, then errors highlighted
### FR-2: ...
## Non-Functional Requirements
### NFR-1: Performance
The system SHALL respond within 200ms for all API requests.
# Design: <Feature Name>
## Overview
<High-level design approach>
## Architecture
### Component Diagram
<Mermaid or text diagram>
### Components
| Component | Responsibility |
| --- | --- |
| FormValidator | Input validation logic |
| FormHandler | Form submission handling |
## Data Model
### Entities
- **FormSubmission**: Captures form data
- id: UUID
- data: JSON
- status: enum
## API Design
### Endpoints
| Method | Path | Description |
| --- | --- | --- |
| POST | /api/forms | Submit form |
## Technical Decisions
### Approach Selected
<Chosen approach with rationale>
### Alternatives Considered
| Alternative | Pros | Cons | Why Not |
| --- | --- | --- | --- |
| ... | ... | ... | ... |
# Tasks: <Feature Name>
## Task List
### Phase 1: Setup
- [ ] **TSK-001**: Create FormValidator component
- Requirement: FR-1
- Deliverables: `src/validators/FormValidator.ts`
- Acceptance: Unit tests pass
- [ ] **TSK-002**: Create FormHandler service
- Requirement: FR-1, FR-2
- Deliverables: `src/services/FormHandler.ts`
- Acceptance: Integration tests pass
### Phase 2: Integration
- [ ] **TSK-003**: Wire up API endpoint
- Requirement: FR-1
- Deliverables: `src/routes/forms.ts`
- Acceptance: E2E tests pass
## Dependency Graph
```text
TSK-001 ─┬─> TSK-003
TSK-002 ─┘
```
## Progress
| Status | Count |
| --- | --- |
| Pending | 3 |
| In Progress | 0 |
| Complete | 0 |
| Kiro Field | Canonical Field |
|---|---|
| requirements.md FR-x | requirements[].id |
| EARS text | requirements[].text |
| Priority | requirements[].priority |
| AC-x.y | requirements[].acceptance_criteria[] |
| design.md | implementation_notes |
| tasks.md TSK-x | maps to task schema |
When converting from canonical format to Kiro:
# Project Context
## Overview
<Project description and purpose>
## Technology Stack
- Language: TypeScript
- Framework: Next.js
- Database: PostgreSQL
## Conventions
### Naming
- Use camelCase for variables
- Use PascalCase for components
- Use kebab-case for files
### Architecture
- Follow vertical slice architecture
- Use feature-based folder structure
- Apply CQRS for complex operations
## Domain Glossary
| Term | Definition |
| --- | --- |
| Form | User input collection |
| Submission | Completed form data |
## Constraints
- All APIs must be RESTful
- Response time < 200ms
- Test coverage > 80%
requirements.md with EARS patternsdesign.md with architecturetasks.md with breakdown| Action | Command |
|---|---|
| Generate from feature | /spec:kiro:sync --from feature |
| Sync to canonical | /spec:kiro:sync --to canonical |
| Update from canonical | /spec:kiro:sync --from canonical |
| Validate Kiro files | /spec:validate .kiro/specs/ |
Kiro files map to Spec Kit phases:
| Kiro File | Spec Kit Phase |
|---|---|
| requirements.md | Phase 1: Specify |
| design.md | Phase 2: Plan |
| tasks.md | Phase 3: Tasks |
Detailed Documentation:
Related Skills:
ears-authoring - EARS requirement patternsspeckit-workflow - GitHub Spec Kit 5-phase workflowcanonical-spec-format - Canonical specification structureLast Updated: 2025-12-24