> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Coding Planning Frameworks

> Choose among source-backed AI coding and planning frameworks, including Amazon Working Backwards, by artifact model, workflow, task grain, review points, and tool coupling.

Choose a framework by the artifact and workflow you need, not by a universal score. Some methods organize one implementation plan. Others maintain project state, feature specifications, issue graphs, or a full product-delivery sequence.

The public [comparison repository](https://github.com/plannotator/spec-planning-frameworks#readme) applies each framework to the same reliable-webhook-delivery brief. It preserves generated files, tool versions, interrupted runs, and known limits for five runnable frameworks. Kiro uses a manual, source-faithful example because its authenticated workflow was unavailable.

| Framework | Primary unit | Main artifacts | Useful when |
| - | - | - | - |
| [Superpowers](/frameworks/superpowers) | Design and implementation plan | Repository specs and code-level plans | You want a defined path from design review to detailed execution |
| [GSD Core](/frameworks/gsd) | Project, milestone, phase, and plan | A durable `.planning/` tree | Work spans sessions and needs explicit state, phases, and verification |
| [GitHub Spec Kit](/frameworks/github-spec-kit) | Feature | Constitution, spec, plan, tasks, supporting artifacts | You want an open feature directory with structured requirements and tasks |
| [Kiro Specs](/frameworks/kiro-specs) | Feature or bug | Requirements or bug analysis, design, tasks | You want an IDE-integrated three-file specification workflow |
| [Matt Pocock's skills](/frameworks/matt-pocock-skills) | Issue, question, spec, or ticket | Issue-tracker artifacts and focused skills | You want composable planning skills inside an existing engineering process |
| [BMad Method](/frameworks/bmad-method) | Product initiative through story | Brief, PRD, architecture, epics, stories | You need a broader role-oriented product and delivery method |
| [Amazon Working Backwards PRFAQ](/frameworks/amazon-working-backwards-prfaq) | Proposed product or feature | Future press release, customer FAQ, internal FAQ | You want to test customer value before writing detailed requirements |
| [ADR formats](/frameworks/adr-formats) | Architectural decision | One Markdown decision record | You need to preserve a significant choice and its consequences |

## How to choose

Ask five questions:

1. Is the main object a feature, project phase, issue graph, delivery program, or decision?
2. Should artifacts live in the repository, an issue tracker, or an IDE-managed directory?
3. Does the team want a prescribed sequence or composable procedures?
4. Should tasks name exact code edits or remain outcome-focused?
5. What review and verification record must survive into the next session?

The profiles describe observed source behavior at a pinned commit or capture date. They do not claim that one framework produces better code. For direct decisions, see [Superpowers vs GSD](/compare/superpowers-vs-gsd) and [GitHub Spec Kit vs Kiro Specs](/compare/github-spec-kit-vs-kiro-specs).

*Reviewed July 19, 2026. Researched and maintained by the Plannotator documentation team.*


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.