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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
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