Menu
Propose a new feature or change. Creates a structured spec folder with proposal, requirements, design, and tasks before any code is written. Use when starting new work.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Index of the kiro-rails engineering toolbox in this repo: every review command, spec workflow, subagent, and steering rule, with when to use each. Load this to decide which review or workflow to run, or to discover what kiro-rails offers. Routing only - each entry points at its own command, skill, or agent.
Security incident response, breach containment, evidence preservation, and recovery verification. Use when a breach, compromise, or security incident is detected or suspected.
Interactive guide to kiro-rails review prompts, agents, and tools. Explains which review to run, when, and why. Invoke with /review-guide or ask "what reviews should I run?", "which prompt?", or "how do I audit?".
Authentication, SSO, OAuth, OIDC, login, redirect, token implementation patterns. Use when implementing auth flows, login pages, token refresh, SSO integration, or redirect handling.
Archive a completed and verified spec. Moves it from active specs to the docs archive, updates the spec registry. Use after spec-verify passes.
Implement a proposed spec. Reads the spec folder, follows the task checklist, writes code using TDD. Use after spec-propose is complete and approved.
| name | spec-propose |
| description | Propose a new feature or change. Creates a structured spec folder with proposal, requirements, design, and tasks before any code is written. Use when starting new work. |
When the user wants to propose a new feature or change, create a structured spec folder BEFORE writing any code.
.kiro/specs/<feature-name>/.kiro/specs/<feature-name>/
├── proposal.md # Why this change exists
├── requirements.md # What the system should do
├── design.md # How to implement it
└── tasks.md # Checkbox-tracked implementation steps
# Proposal: <Feature Name>
## Problem Statement
What problem does this solve? Who is affected?
## Proposed Solution
High-level description of the approach.
## Scope
- **In scope:** what this change includes
- **Out of scope:** what this change explicitly excludes
## Success Criteria
How do we know this is done and working?
## Risks & Open Questions
- Risk 1: ...
- Question 1: ...
# Requirements: <Feature Name>
## Functional Requirements
### REQ-1: <Requirement Name>
**Description:** What the system must do.
**Acceptance Criteria:**
- [ ] Criterion 1
- [ ] Criterion 2
### REQ-2: <Requirement Name>
...
## Non-Functional Requirements
- Performance: ...
- Security: ...
- Accessibility: ...
# Design: <Feature Name>
## Architecture
How this fits into the existing system.
## Key Decisions
| Decision | Rationale | Alternatives Considered |
|----------|-----------|------------------------|
| ... | ... | ... |
## Data Model Changes
Describe any schema/model changes.
## API Changes
Describe any endpoint additions/modifications.
## Dependencies
What this depends on, what depends on this.
Use the TDD template from .kiro/templates/tasks-template-tdd.md if available. Otherwise:
# Tasks: <Feature Name>
## Implementation Checklist
- [ ] Task 1: ...
- [ ] Task 2: ...
- [ ] Task 3: ...
## Testing
- [ ] Unit tests for ...
- [ ] Integration tests for ...
## Documentation
- [ ] Update relevant docs
- [ ] Add ADR if architectural decision was made