How LiteSpec Compares

The Short Answer#

Spec-driven development means writing down what to build before an AI coding agent builds it. Most approaches structure one feature or change at a time. They guide an agent through requirements, design, and tasks for a single piece of work, then archive the result. LiteSpec instead specifies one whole bounded-context application with versioned, citable rules, a tool-checked subset of them, and a written agent protocol.

Its rules carry stable provision IDs for exact citation, and its checks run in the editor, the build, and CI. The other approaches stay neutral about stack and architecture, which keeps them light but leaves structural decisions to each team. LiteSpec fixes the application shape and its stacks, which lets it state concrete rules an agent follows the same way twice.

The two sides combine: a team can run a per-feature workflow or behavior examples inside a LiteSpec product, with instruction files as the agent entry point.

The Approaches#

LiteSpec#

LiteSpec (Why LiteSpec Exists) is a standard for building one bounded-context business application. It has three parts: versioned rules, project records written top down through Intent, Behavior, Implementation, and Proof, and a model builder that follows the marks by which code and tests point up to records and renders the book product people read.

A project selects one size, one shape, and its stacks from .NET, React, Svelte, Blazor, and Android, and the standard states concrete rules for that selection. Every rule carries a stable provision ID. A project also declares the conformance level it claims in .litespec/project.json: records, traced or full, and the tools report only the part that level claims. The litespec CLI, Roslyn analyzers, and model findings check the claimed part. A project pins one release, as How the Tools Fit Together describes.

The levels nest: traced claims everything records claims, and full claims everything traced claims. The supported scope page states the declaration, and the project file reference lists the field.

GitHub Spec Kit#

GitHub Spec Kit (github/spec-kit) is an MIT-licensed, language-neutral open source toolkit in the github organization. It gives AI coding agents structured processes, reusable templates, and documented outcomes.

A project creates a constitution once, then repeats per-feature steps in the agent's chat: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, and /speckit-converge. Bug fixing and assessment ship as bundled extensions. Each step ends in a human review gate, with convergence repeated until the report reads Converged. It works with a supported agent on Linux, macOS, or Windows.

Kiro#

Kiro (kiro.dev) describes itself as an agentic AI with an IDE, CLI, web interface, mobile app, and Kiro Crew, built and operated by AWS. It works with Anthropic Claude, OpenAI GPT, and open-weight models, supports AGENTS.md and MCP, and prices paid use by credit while Kiro Crew stays free and open source.

Each spec covers one feature or bug fix and generates requirements.md (or bugfix.md), design.md, and tasks.md. Requirements analysis checks a spec for contradictions and gaps, and the IDE runs property-based and correctness testing.

Tessl#

Tessl (tessl.io) is an open platform for managing agentic development across an organization through a registry of installable tiles. Its spec-driven development tile by tessl-labs (the registry page), MIT licensed, teaches AI coding agents to gather requirements, write specifications, and get approval before writing code.

Specs are .spec.md files with YAML frontmatter and inline references to the tests that verify each requirement. Each change moves through a gather, approve, implement, and review loop. Tile checks cover spec shape, link integrity, and review outcomes. The tile is open source, and the commercial platform's skills work across MCP-compatible agents.

BMAD Method#

The BMAD Method (BMAD-METHOD), short for Breakthrough Method for Agile Ai Driven Development, turns an idea or change request into working software through named skills added to AI coding tools.

Thinking skills cover exploring, researching, arguing, and recording, bmad-build writes and reviews code, and briefs, specifications, and architecture documents carry durable context forward. Work scales from a small fix to whole-product planning, with teams following their own rules and the human in control. It is MIT licensed, free and open source with no paywalled workflows. BMad and BMAD-METHOD are trademarks of BMad Code, LLC. The core method names no stack beyond a game module for Unity, Unreal, Godot, and Phaser.

OpenSpec#

OpenSpec (OpenSpec) is spec-driven development (SDD) for AI coding assistants, maintained by Fission AI and built brownfield-first around a fluid and iterative approach.

Each change gets a folder with a proposal, specs, design, and tasks, and shipped changes archive when done. Durable specs with beta Stores share the shape. It covers one change at a time: you bring your preferred AI and OpenSpec brings the structure. Plans pass human review before code, with an expanded /opsx:verify workflow. It is MIT licensed, neutral, and working with 30 or more assistants through slash commands.

Agent OS#

Agent OS (Agent OS) by Brian Casel at Builder Methods is a system for injecting your codebase standards and writing better specs for spec-driven development. It discovers, deploys, and indexes a team's standards, pairing standing codebase standards with per-spec shaping for better plans and better builds.

Standards live as plain Markdown files any tool can read, complementing assistants such as Claude Code, Cursor, Windsurf, and Codex. It is MIT licensed, free and open source, in any language and any framework.

Agent Instruction Files#

Agent instruction files (AGENTS.md, CLAUDE.md memory, Copilot instructions) are plain Markdown files in the repository that carry whole-repository conventions: build commands, layout, standards, and workflows.

AGENTS.md is a simple, open format for guiding coding agents, stewarded by the Agentic AI Foundation under the Linux Foundation, and GitHub treats AGENTS.md, CLAUDE.md, and GEMINI.md as agent instructions. Teams write whatever they need as free text in nested AGENTS.md files, CLAUDE.md with .claude/rules/, and .github/copilot-instructions.md with .github/instructions/.

Nothing enforces the format: Claude treats these files as context, not configuration, so an agent follows them on a best-effort basis. Cursor publishes its own rules page (Cursor rules).

Behavior-Driven Development with Gherkin#

Behavior-driven development with Gherkin (Cucumber, Reqnroll) writes behavior as executable examples. Cucumber is a tool that supports Behaviour-Driven Development, and Gherkin is its grammar.

Teams write .feature files of Given-When-Then scenarios, versioned with the software and wired to code through step definitions. Reqnroll is an open-source Cucumber-style framework that automates them for .NET as a SpecFlow reboot.

BDD is about discovery, collaboration, and examples rather than testing alone. Cucumber reads executable specifications in plain text and validates the software against them, reporting pass or fail per scenario through step definitions that hard-wire each specification to its implementation.

ADRs, arc42, and C4#

Architecture records and diagrams (ADRs, arc42, the C4 model) document whole-system architecture and its significant decisions.

An ADR captures a single architectural decision and its rationale, and the collection forms the project's decision log. arc42 gives a 12-section template for architecture documentation and communication, and the C4 model is an easy to learn, developer friendly approach to software architecture diagramming. arc42 suits large and small teams, C4 zooms from system context down to code, and arc42 stays process-agnostic in support of arbitrary technologies.

Architecture Tests#

Architecture tests (ArchUnit, ArchUnitNET) check whole-codebase structure, from package and layer dependencies to cycles, naming, and sealing, with rules written as test code.

ArchUnit is a free, simple, and extensible library for checking Java architecture with any plain Java unit test framework. ArchUnitNET is a C# library that states architecture rules and asserts them in automated tests. Both enforce application-specific conventions beyond generic static analysis, and their rules execute as unit tests in the build pipeline. ArchUnitNET is Apache 2.0 licensed and NuGet distributed, and ArchUnit covers Java bytecode.

OpenFastTrace#

OpenFastTrace (openfasttrace.itsallcode.org) is a requirement tracing suite that traces each tagged specification item from requirements through design and implementation to tests and reports coverage, uncovered items, and broken or outdated links.

Like LiteSpec, it follows explicit IDs from a specification to the code and tests that cover it and computes coverage from those links. It does not ship an application rulebook, stack rules, an application code layout, or analyzers; the project defines the items it traces.

StrictDoc#

StrictDoc (strictdoc.readthedocs.io) is open-source software for technical documentation and requirements management that holds requirements as structured text with unique IDs, links them to parent requirements, and generates traceability views from the source files.

Like LiteSpec, it keeps each requirement citable by ID and derives traceability from the written source instead of a separate database. It does not state stack-specific engineering provisions, a bounded-context record model, code marks checked by analyzers, or a fixed application shape; its documents state the requirements a project writes.

Sphinx-Needs#

Sphinx-Needs (sphinx-needs.readthedocs.io) is a Sphinx extension that adds needs and requirements to Sphinx documentation, with an ID and links for each need, and renders lists, tables, and traceability views at documentation build time.

Like LiteSpec, it gives each stated need a stable ID, links it to other needs, and computes its views from the source on every build. It does not provide a record model for a whole application, CLI model checks, stack provisions, or analyzers; it works inside a Sphinx documentation project.

Doorstop#

Doorstop (doorstop.readthedocs.io) is a requirements management tool that facilitates the storage of textual requirements alongside source code in version control, with one file per item, links between items, and publication to text or HTML.

Like LiteSpec, it stores each requirement as version-controlled text beside the code and follows links between items. It does not check code marks with analyzers, compute completion of an application model, or state stack and layout provisions; it manages requirement documents and their links.

Side-by-Side Comparison#

The table summarizes each approach on the same dimensions, as described on the official pages linked in each section. Cells that read None described mean the pages read describe no such item.

The diagram places each approach by scope against verification.

Reasons for LiteSpec#

Each property below names the page that states it.

• A standing product standard. LiteSpec ships the whole rulebook for one bounded-context application, while per-feature approaches ship a workflow the team fills in. The supported scope page states the boundary.
• Citable rules. Every rule has a provision ID of page plus heading slug, so a review comment, an agent report, or an exception cites exactly one rule, such as litespec/backend/dotnet/domain#model-every-closed-set-of-domain-values-without-enums. The authoring page defines the grammar.
• Automated verification for a checked subset. The CLI checks records and the model, Roslyn analyzer rules flag breaches in the editor and build with links to their provisions, and model findings report unimplemented use cases, unraised refusals, undeclared edges, unresolved references, and expired exceptions, each with a check level: record checks always block, code checks block where the stack reader is qualified, and advisory checks never block. Most provisions carry a Reviewed for question a person judges; a checked subset carries a Checked by line a tool runs. The provision index lists each provision with its mark and states the checked share for each page. Code and tests point up to records through their marks, and the builder computes completion from those marks on every run, so it cannot go stale. The analyzer reference documents every rule, and the model page lists every finding code.
• Three conformance levels. A project claims records, traced or full in .litespec/project.json, and the tools report only the claimed part: records at records, marks and proof in the project's own layout at traced, and the stacks, LiteSpec's code layout, the analyzers and the operations provisions at full. The supported scope page states the levels.
• A versioned contract. Each release states every active provision, a project pins one release, and adoption is recorded in reviewedLiteSpecVersion. The authoring page states the release model, and How LiteSpec Works shows the pin.
• Stack depth where it applies. The fixed application shape allows concrete rules such as the modules project ordered by module, aggregate, and use case, one way to model a lifecycle, and one way to report a refused command. The supported scope page states the selection, and the .NET, React, Svelte, Blazor, and Android stack pages carry the per-stack rules.
• A written agent protocol. Agents ask litespec rules which provisions apply to the files they will edit, query one record with litespec model query, and finish with check-backed reports, stopping on conflicts with both rule IDs quoted. The protocol is written instructions: no tool checks that an agent ran litespec rules, read the records, or answered the review questions, and the agent page carries no Checked by line. The tools check the records and code the agent leaves behind. Work with Agents describes how an agent finds the rules, and the agent page states the task order.

Reasons for Another Approach#

LiteSpec is not the right answer everywhere. The points below favor another approach, stated in the makers' own terms.

• A team that wants a light per-feature flow can use OpenSpec, Spec Kit, or Kiro. OpenSpec is brownfield-first across 30 or more tools, Spec Kit pairs a constitution with per-feature commands and convergence gates, and Kiro turns requirements into design and tasks.
• A team on another stack can use a neutral approach. LiteSpec supports .NET with React, Svelte, Blazor, or Android, while BMAD names Unity, Unreal, Godot, and Phaser, ArchUnit covers Java bytecode, and Cucumber spans many programming languages.
• A team with strong conventions to keep can use Agent OS or plain instruction files. Agent OS discovers, deploys, and indexes the team's standards, and instruction files carry whatever the team writes.
• A team whose agents misuse library APIs can use Tessl tiles. The registry holds library-usage tiles per ecosystem alongside the methodology tile, while LiteSpec pins package versions without teaching API surfaces.
• A team that wants architecture documentation for readers rather than checks for machines can use ADRs, arc42, and C4. ADRs keep the decision log, arc42 gives the 12-section template, and C4 diagrams the system from context to code.
• A team with an existing suite that wants behavior or structural checks can add Cucumber, Reqnroll, ArchUnitNET, or ArchUnit. Cucumber validates plain-text specifications per scenario, Reqnroll automates Given-When-Then scenarios for .NET, and architecture tests enforce structural rules as unit tests.

Combined Use#

LiteSpec acts as the product standard, and the others work inside it.

• With AGENTS.md. A short AGENTS.md block points agents at the selection index and raw pages: instruction files carry the pointer, and LiteSpec carries the rules. Work with Agents shows the block.
• With BDD. The manifest pins Reqnroll and LightBDD, and the bdd extension states how executable acceptance tests prove LiteSpec scenarios. The BDD extension states the provisions, including litespec/backend/dotnet/ext/bdd#prove-a-scenario-from-every-bdd-scenario.
• With ADRs, arc42, and C4. A team can keep ADRs as its decision log and cite them from LiteSpec decision records, and draw arc42 or C4 views to present the architecture LiteSpec states. One side records for humans, and the other checks for machines.
• With a per-feature workflow. A team can shape a change with Spec Kit, OpenSpec, Kiro, BMAD, or the Tessl tile, then carry the result into LiteSpec use-case and result records. The workflow handles one change, and LiteSpec holds the product around it.

Sources#

Every address below shows the date it was read beside it.

• https://github.com/github/spec-kit (2026-10-21).
• https://kiro.dev/docs/specs/ (2026-10-21).
• https://kiro.dev/ (2026-10-21).
• https://tessl.io (2026-10-21).
• https://docs.tessl.io/ (2026-10-21).
• https://tessl.io/registry/tessl-labs/spec-driven-development (2026-10-21).
• https://github.com/bmad-code-org/BMAD-METHOD (2026-10-21).
• https://docs.bmad-method.org/ (2026-10-21).
• https://github.com/Fission-AI/OpenSpec (2026-10-21).
• https://openspec.dev/docs (2026-10-21).
• https://buildermethods.com/agent-os (2026-10-21).
• https://github.com/buildermethods/agent-os (2026-10-21).
• https://agents.md/ (2026-10-21).
• https://code.claude.com/docs/en/memory (2026-10-21).
• https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot (2026-10-21).
• https://cursor.com/docs (2026-10-21).
• https://cucumber.io/docs/ (2026-10-21).
• https://reqnroll.net/ (2026-10-21).
• https://adr.github.io/ (2026-10-21).
• https://arc42.org/ (2026-10-21).
• https://c4model.com/ (2026-10-21).
• https://www.archunit.org/ (2026-10-21).
• https://github.com/TNG/ArchUnitNET (2026-10-31).
• https://openfasttrace.itsallcode.org/ (2026-11-08).
• https://strictdoc.readthedocs.io/en/stable/ (2026-11-08).
• https://sphinx-needs.readthedocs.io/en/latest/ (2026-11-08).
• https://doorstop.readthedocs.io/en/stable/ (2026-11-08).

Next#

Lineage names the practices LiteSpec borrows from, and what it takes from each.