The spec-driven development landscape

A portable workflow for taking a feature through Specify → Plan → Tasks → Implement. Its constitution and agent commands impose process discipline while generated Markdown files stay in the repository.

artifact

A constitution plus per-feature specification, implementation plan, task list, research, and supporting contracts.

distinctive

The broadest agent integration surface in this field and an active extension ecosystem. It is a strong default when a team wants one recognizable spec-to-code ceremony across different coding agents.

boundary

The core validates workflow and artifact presence more than system-wide semantics. It is a process harness, not a typed model of component ownership or cross-feature relationships.

A change-management format built around a useful split: specs describe current truth, while change folders carry proposals, designs, tasks, and delta specs. Archiving a completed change merges its deltas into the canonical specs.

artifact

Repository files under specs/ and changes/, with ADDED, MODIFIED, and REMOVED requirement deltas and scenario-based acceptance detail.

distinctive

Structural validation, machine-readable CLI output, high agent portability, and a beta store model for requirements shared across repositories. Version 1.7 adds a machine-wide default store and operation-specific agent instructions, strengthening its case as the closest general-purpose file-based alternative to durable spec memory.

boundary

Its center of gravity is requirements and change lifecycle, not a typed system graph. Rich component topology, revision APIs, and minimal projections are not its default abstraction.

An integrated IDE, CLI, and web environment whose specs move from requirements to design to implementation tasks. Requirements can use EARS notation, and steering files supply durable project conventions.

artifact

Per-feature requirements.md, design.md, and tasks.md files, supplemented by repository steering and automation hooks.

distinctive

It connects specification to implementation correctness more tightly than most competitors. Optional property-based testing derives executable properties from requirements, hooks can make checks blocking, and web spec sessions can coordinate implementation across multiple repositories.

boundary

The workflow is optimized for Kiro surfaces, so the full experience is less portable than a format-first tool. Durable system modeling and independent hosted revision history are not the primary proposition.

A source-adjacent DSL that places .sdd contracts beside code. Specs declare purpose, ownership, allowed reads and writes, dependencies, interfaces, prohibitions, scenarios, tasks, and completion conditions.

artifact

Hierarchical .sdd files: vertical rules inherit through the filesystem and explicit references establish horizontal relationships.

distinctive

Its editor integrations provide strict diagnostics and workspace validation, making behavioral and authority boundaries visible where developers work. The format is unusually good at saying what an agent may not modify.

boundary

It treats Git and the source tree as the persistence layer. It does not provide a hosted revision store, system-level projections, or a separate collaboration plane.

A per-feature intent format that starts with product evidence instead of an implementation plan. It records objective, evidence with anchors, outcomes, constraints, scope, edge cases, health metrics, and verification instructions.

artifact

A portable intent.md file using YAML frontmatter and Markdown, backed by JSON Schema and a GitHub Action.

distinctive

It makes the provenance of product decisions first-class. That is valuable when the important question is not only what to build, but which observed user or business signal justifies it.

boundary

The unit is a feature intent document rather than a whole-system graph. Architecture ownership, dependency integrity, and coordinated implementation are intentionally outside its core.

A large AI-assisted software-development method spanning analysis, product planning, architecture, epics, stories, implementation, and review. Specialist agent roles guide each phase and produce the next phase's context.

artifact

PRDs, architecture documents, epics, stories, project context, and a compact bmad-spec kernel covering why, capabilities, constraints, non-goals, and success signals.

distinctive

It offers the most comprehensive end-to-end ceremony in this set. Teams wanting repeatable roles and checkpoints across a full delivery lifecycle get much more than a spec template.

boundary

The breadth produces many artifacts and agent-mediated reviews rather than one canonical typed model. It is a delivery operating system, not primarily long-lived queryable system memory.

A Kiro-inspired implementation workflow packaged as portable Agent Skills. It covers discovery, requirements, design, task decomposition, long-running implementation, review, and debugging.

artifact

Repository-based requirements, design, and task files, with boundary annotations, dependency markers, file-structure plans, and cross-spec review.

distinctive

Boundary-first design and separate implementer, reviewer, and debugger roles make it suitable for autonomous work that must survive multiple sessions. Its TDD loop supplies stronger implementation feedback than document-only approaches.

boundary

The codebase remains the eventual source of truth and most quality judgment is agent-driven. It does not try to preserve a product-wide, independently queryable intent graph.

A desktop workspace for coordinating multiple coding agents around a Git branch and worktree. Each workspace combines a living spec, tasks, notes, context, diffs, browser state, and activity.

artifact

A workspace-level spec and task model attached to an isolated Git worktree, with coordinator, implementor, and verifier agents.

distinctive

It makes parallel-agent execution observable to a human and includes browser-based end-to-end verification. Bring-your-own-agent support includes Codex, Claude Code, and OpenCode.

boundary

The durable unit is the Intent application workspace rather than a portable formal specification. It optimizes orchestration and supervision more than semantic validation.

A product-oriented method for describing software as domains, narratives, scenes, and moments. The hierarchy expresses user goals, outcomes, business rules, examples, and should-statements before producing build instructions.

artifact

A narrative model that reads more like structured product behavior than a conventional technical requirements document.

distinctive

The vocabulary is accessible to business stakeholders and well suited to line-of-business applications. It keeps product behavior central instead of letting architecture or task decomposition dominate the conversation.

boundary

The public method is portable, but the complete workflow is a hosted product. Public documentation does not establish the same deterministic validation or open exit surface as format-first tools.

A collaborative project-memory and proposal workspace for teams and agents. Proposals move through Draft → Design → Review → Ready with problem, scope, approach, and Given/When/Then acceptance criteria.

artifact

Shared project memory, structured proposals, tasks, acceptance criteria, comments, and a Kanban workflow with real-time collaboration.

distinctive

Its MCP surface lets agents read and write the same specifications and tasks humans review in the UI. Self-hosting and an AGPL codebase offer an uncommon open path for collaborative spec software.

boundary

It is early and collaboration-centric. Its public model does not yet show the graph integrity, immutable revisions, or implementation evidence gates of more specialized systems.

A hosted execution system that turns a structured specification into epics and an atomic ticket dependency graph. Critical paths and execution waves make sequencing explicit for coding agents.

artifact

Structured specification fields followed by epics and ticket DAGs, with planning and implementation quality gates.

distinctive

Quality gates check acceptance criteria, expected files, Git state, and test evidence before work advances. Its MCP tools expose planning and execution state directly to agents.

boundary

The product focuses on the downstream execution graph rather than durable system intent. It is proprietary, and public documentation does not yet establish a lossless data export path, so long-term data portability remains unclear.

A code-intelligence system that derives a verifiable intermediate representation of intent, dependencies, and business logic from existing repositories, then exposes that graph to agents through MCP.

artifact

An incrementally maintained, code-derived graph spanning repositories, with dependency navigation and blast-radius analysis.

distinctive

It addresses the brownfield reality that useful intent often exists only in code. It re-derives a candidate spec for changed files, compares that reading with the accepted contract, and traces cross-repository blast radius without requiring a team to author a specification first.

boundary

Its direction of travel is code → inferred intent, the inverse of an authored specification. It can explain what appears to exist, but it cannot by itself preserve product intent that the code never implemented.