Named in this year's SDD roundups
Levelop, Augment Code, and thebcms cover Spec Kit, OpenSpec, Kiro, and BMAD. We just aren't in the article.
n-dx vs Spec Kitfor the codebase you already have
Those tools start with a spec you write. n-dx starts with the repo you already have. Scan the tree, keep a PRD that can be rebuilt from the code, then run the next task.
Searched Spec Kit vs OpenSpec? You probably never saw n-dx.
This year's roundups list Spec Kit, OpenSpec, Kiro, and BMAD. n-dx isn't on them. We're smaller: 16 GitHub stars as of 21 Aug 2026. That's why this page exists.
n-dx.dev already compares coding agents
Claude Code, Aider, OpenHands, Goose, MetaGPT, 8090, and Devin are agents. Spec Kit, OpenSpec, and Kiro are the spec layer people now evaluate first.
The job is the existing repo
If the last six months were vibe-coded, the plan has drifted, or a prototype became production, start from the tree, not a blank spec.
Spec-first is the right loop when you already know what to build.
n-dx is the other start: what's already here, and what to fix or finish. You can still add work in plain language with ndx add "Add SSO support" .
- 1-1
Analyze the tree
sourcevision writes AI-readable context: files, imports, architectural zones, React catalog.
ndx analyze . - 1-2
Propose a living PRD
Findings become epics and tasks. You accept or reject them. The spec is derived from the code.
ndx recommend . - 1-3
Execute the next task
hench picks the next task, briefs it with codebase context, and runs a tool-use loop.
ndx work . - 1-4
Stay current
Self-heal re-analyzes, recommends, executes, and acknowledges completed findings so they don't regenerate.
ndx self-heal .
The spec can be rebuilt from the tree. That's the point. If the last six months were vibe-coded, use the vibe-cleanup guide.
What each one actually does.
We didn't invent numbers for the other tools. Licenses and shapes below are from public docs as of 21 Aug 2026. If we haven't checked a file, we say so.
n-dx
CLI-first toolkit from En Dash. Install @n-dx/core, then analyze, recommend, work, and start. Built for Claude Code and Codex. PRD in .rex/prd_tree/. Rex and sourcevision expose MCP.
- Starts from an existing codebase scan
- Living PRD, re-derived when the tree changes
- Hench executes the next accepted task
- Elastic 2.0 (source-available, not OSI)
ndx analyze . && ndx recommend . && ndx work .github.com/en-dash-consulting/n-dx →
GitHub Spec Kit
Portable MIT toolkit. Install specify-cli, write a constitution, then specify, plan, task, and implement through the agent you already use. Specs are markdown in the repo. GitHub documents existing-project adoption; 2026 writeups still treat it as structured and often greenfield-leaning.
- Constitution, then specify / plan / task / implement
- Works with Copilot, Claude Code, Gemini, Cursor, and others
- Markdown artifacts in the repo
- MIT license
specify-cli · /speckit.implementgithub.com/github/spec-kit →
OpenSpec
Lightweight CLI from Fission-AI, built brownfield-first. Changes are deltas (ADDED, MODIFIED, REMOVED) against a source-of-truth spec. The loop is propose, apply, archive. You spec the slice you are changing. It does not scan a repo into a PRD.
- Change deltas, not a full-tree analyzer
- Propose, apply, archive
- Agent-agnostic apply step
- MIT commonly cited; confirm the LICENSE file
propose · apply · archiveopenspec.dev →
AWS Kiro
An agentic IDE, not a CLI you add to an existing editor. A prompt becomes requirements, design, and tasks, then its agents implement. Commercial AWS product. Formal requirement checks and Agent Hooks are on the public pitch. The workflow lives in Kiro.
- Prompt to a spec set, then implement
- Built-in agents; editor and spec are one product
- requirements.md / design.md / tasks.md
- AWS commercial license
kiro.dev · built-in agentskiro.dev →
Side by side.
Rows stay as words. We didn't invent competitor stars, downloads, or win rates. "Unknown" means we haven't verified it from public docs.
| Dimension | n-dx | Spec Kit | OpenSpec | Kiro |
|---|---|---|---|---|
| Form | CLI plus optional dashboard | CLI plus agent slash commands | CLI | Agentic IDE |
| License | Elastic 2.0 | MIT | MIT (commonly cited) | AWS commercial |
| Starts from | Existing codebase scan | Spec and constitution | Change delta | Prompt to spec set |
| Living spec | Rex PRD, re-analyzed each cycle | Markdown artifacts. Code auto-sync: unknown | Archive merges deltas into the source-of-truth spec | Spec then implement. Code auto-sync: unknown |
| Static analysis | sourcevision: files, imports, zones, React catalog | Not the product | Not the product | Not the product pitch |
| Execution | Hench tool-use loop | /speckit.implement via your agent | Apply via your agent | Built-in agents |
| Agents | Claude Code and Codex | Many (Copilot, Claude, Gemini, Cursor, others) | Agent-agnostic | Built-in |
| 2026 SDD roundups | Not named | Named | Named | Named |
Public documentation as of 21 Aug 2026. Levelop, Augment Code, and thebcms are the 2026 SDD roundups cited. We do not cite competitor star or download counts.
Which one fits what you're doing.
Having people on the repo with you is consulting, not a CLI flag. The picks below are about the product, not the services bench.
You will write the spec before the code.
You want the portable SDD workflow most teams already recognize, you switch agents, and MIT is what most open-source buyers expect.
- Agent-portable: Copilot, Claude, Gemini, Cursor, and others
- Constitution plus specify / plan / task / implement
- OSI-friendly MIT license
You are changing one slice at a time.
You want a thin delta layer on an existing system, not a codebase analyzer or a full PRD tree.
- ADDED / MODIFIED / REMOVED against a source-of-truth spec
- Propose, apply, archive. Agent-agnostic apply.
- Not a cleanup analyzer and not a living PRD
You want SDD inside an IDE.
You are fine on AWS, and you want agent, editor, and spec as one product.
- Prompt becomes requirements, design, and tasks
- Built-in agents. The workflow lives in Kiro.
- Commercial AWS product, not a CLI you drop into Cursor
The repo already exists.
The plan has drifted from the code, or a prototype became production without a spec. Analyze the tree, keep a PRD that can be re-derived, then execute.
- Existing-codebase scan, not a blank constitution
- Living PRD in .rex/, re-analyzed each cycle
- Hench executes. Built for Claude Code and Codex.
When n-dx is the wrong pick.
Skip n-dx if you need a large community, an OSI-approved license, or an agent-agnostic install. Those are real gaps.
You need an OSI-approved license
The code is public. The license is Elastic 2.0, not MIT. ELv2 allows internal use, modification, and distribution, with a hosted-service restriction. Spec Kit is MIT. The precise term for n-dx is source-available.
You need a large community
n-dx listed 16 GitHub stars on 21 Aug 2026. Spec Kit, OpenSpec, and Kiro are the names in the 2026 lists. If ecosystem size is the buying criterion, pick one of those.
You need an agent-agnostic install
n-dx is built for Claude Code and Codex. Spec Kit and OpenSpec are written to ride whatever agent you already use. If you switch models every week, start there.
Point it at a directory. Run the loop.
The package is @n-dx/core. Requires Node.js 22+. Works with Claude Code and Codex; configure your LLM vendor on first run.
$ npm i -g @n-dx/core
- 1
ndx init .set up all three tools - 2
ndx analyze .map the codebase - 3
ndx recommend .propose the PRD - 4
ndx work .run the next task - 5
ndx start .open the dashboard
Also: vibe-coded cleanup · toolkit listing · n-dx.dev
A few questions.
Is n-dx a Spec Kit alternative?
Kind of. Spec Kit starts from a spec you write and works with a lot of agents. n-dx starts from the repo and is built for Claude Code and Codex. Use the jobs above.
Why is n-dx missing from Spec Kit vs OpenSpec vs Kiro lists?
The 2026 roundups at Levelop, Augment Code, and thebcms name Spec Kit, OpenSpec, Kiro, and BMAD. n-dx is smaller and newer (16 GitHub stars on 21 Aug 2026).
Can I use n-dx on a greenfield repo?
Yes. Quickstart works on an empty folder. The tool is built for repos that already have code. If you're starting from a blank spec, Spec Kit or Kiro will feel more natural.
Is n-dx open source the way Spec Kit is?
The code is public. The license is Elastic 2.0, not MIT. ELv2 allows internal use, modification, and distribution, with a hosted-service restriction. Spec Kit is MIT. OpenSpec is commonly cited as MIT; confirm the LICENSE file. The precise term for n-dx is source-available, and that's the term this site uses.
Built by En Dash Consulting
Questions?
Let's talk.
Evaluating this for a team, or stuck on a specific repo? Write us. Putting people on the codebase with you is consulting, not a CLI flag.
Get in touch →