AWS’s agentic development environment built around spec-driven development. A Kiro spec is a set of structured artifacts — requirements.md, design.md and tasks.md — generated through a requirements, design and tasks workflow before implementation, with project guidance held in .kiro/steering/. Available as IDE, CLI, web and mobile. A proprietary commercial AWS product with paid plans, not an open specification.
Kiro
Kiro is Amazon’s agentic development environment, built on the premise that an agent should produce requirements, a design and a sequenced task list before it produces code. It entered public preview in July 2025 and reached general availability in November 2025, and now ships as an IDE, a CLI, and web and mobile surfaces.
- Three artifacts per feature - A spec generates
requirements.mdcapturing user stories and acceptance criteria (orbugfix.mdfor a defect),design.mdfor the technical architecture, andtasks.mdas discrete trackable tasks whose status updates as work proceeds. - A three-phase workflow - Requirements or bug analysis, then design, then task generation — each reviewed before the next, so the plan is agreed before implementation starts.
- Steering files for standing context - Project-wide guidance lives in
.kiro/steering/in the repository root, with~/.kiro/steering/applying across every workspace. This is the part closest to a repository convention, and the part most like AGENTS.md. - Property-based testing for spec correctness - Added at general availability, alongside progress checkpointing and centrally managed team plans.
Kiro is catalogued here for the artifact shape it popularized, not because it is a standard — it plainly is not. It is a proprietary, commercially licensed AWS product with subscription pricing, no published specification, and no open governance. What makes it worth a record is that requirements.md / design.md / tasks.md has become something close to a de facto shape for spec-driven development: OpenSpec and Spec Kit both emit recognisably the same trio, and Kiro is where most developers met it.
That convergence is only skin deep. The three toolkits agree on roughly what documents a feature needs and agree on nothing else — no shared grammar for a requirement, no shared directory, no way to hand a Kiro spec to Spec Kit. A team adopting any of them is adopting a vendor’s conventions, and in Kiro’s case a vendor’s product, IDE and billing relationship along with them.
Practices this standard realizes
The ways of working this standard exists to serve. A standard rarely arrives on its own — it is usually the artifact some practice needed before it could be more than an argument.
Spec-Driven Development
AWS's agentic IDE, where the requirements/design/tasks trio that SDD converged on was popularized.