From feature to verified PRD.
11 steps. One reducer.
A feature description goes in. A verified, 9-file PRD comes out — grounded on your actual code graph, not a hallucinated one. ai-architect-mcp-spec runs an 11-step stateless PRD reducer; ai-architect-mcp-codebase supplies the codebase intelligence it grounds on. Ask it to keep going and 9 opt-in steps implement, test, review and open the pull request, behind a human gate.
> /plugin install ai-architect-mcp-spec@ai-architect-mcp-spec-marketplace
Node.js 20.x or 22.x. Pairs with ai-architect-mcp-codebase (Rust 1.95.0, CMake) for codebase-grounded input analysis — optional, not required.
ai-architect-mcp-codebase — the codebase intelligence layer
The 11-step reducer above needs the truth about your code before it writes a PRD. ai-architect-mcp-codebase is the Rust MCP server that supplies it — the read-only half between “here is a feature description” and “here is what is actually true about the code.”
What it does
- Indexes Rust / Python / TypeScript / Java / Kotlin / Swift / Objective-C / C / C++ / Go codebases, plus Ruby on a shallow path, into a property graph (LadybugDB)
- Resolves call chains and imports across files; never hallucinates symbols
- Detects functional communities (Leiden-class)
- Traces processes from entry points
- Hybrid BM25 + sparse TF-IDF + RRF search
- Validates PRDs against the actual graph (no fictional symbols)
- Security gates: auth touch, unsafe code, public API change, coverage gap
- Semantic diff: before/after graph, regression score, new cycles
By the numbers
- 26 MCP tools — one pipeline stage per tool, 10 stages
- v0.11.1 — released 14 August 2026
- 11 languages (10 with full AST, Ruby on a shallow path)
- 1,200+ tests, zero warnings
- 83,724 lines of Rust (measured at v0.11.1)
- Read-only — never writes code, opens PRs, or runs CI
- Pairs with Cortex and ai-architect-mcp-spec (call-graph context)
> /plugin marketplace add cdeust/ai-architect-mcp-codebase
> /plugin install ai-architect-mcp-codebase@ai-architect-mcp-codebase-marketplace
The plugin compiles the LadybugDB C++ core + Rust binary on first install (~5 min). Cached after. Requires Rust 1.95.0 (pinned by rust-toolchain.toml) and CMake.
What a /generate-prd run looks like
$ /generate-prd "add rate limiting to the export endpoint" [01/11] banner ........................ OK [02/11] preflight ...................... OK Cortex + ai-architect-mcp-codebase reachable [03/11] context_detection .............. OK context: feature [04/11] input_analysis ................. OK graph-grounded via ai-architect-mcp-codebase [05/11] feasibility_gate ............... OK single feature, pass-through [06/11] clarification .................. OK 1 round, proceed-signal set [07/11] budget ....................... OK [08/11] section_generation ............. OK per-section recall + validate + retry [09/11] jira_generation ................ OK [10/11] file_export .................... OK 9 files written [11/11] self_check ..................... OK multi-judge + deterministic verdicts PRD complete. 9 files written under .prd-gen/. Ask to continue: implementation -> testing -> review -> pr_gate -> pull request.
What this pipeline does
It takes a feature description and produces a verified PRD — and, if you ask it to keep going, a pull request.
Give ai-architect-mcp-spec a feature description. It runs an 11-step stateless PRD reducer: check that Cortex and ai-architect-mcp-codebase are reachable, detect the PRD context, ground the feature on your real code graph via ai-architect-mcp-codebase, gate on scope, clarify with the user, budget the tokens, generate every PRD section against per-section Cortex recall, generate JIRA tickets, export 9 deliverable files, and self-check with a two-phase multi-judge verification pass.
self_check is not the end of the road. When you ask it to continue, the same state machine advances through an implementation loop — an engineer subagent implements on a feature branch, a test-engineer subagent runs the suite, a code-reviewer subagent verifies the diff (retrying implementation on a FAIL, bounded by a retry cap), and a mandatory human gate (pr_gate) asks before pushing. “No” is a valid terminal outcome, not a failure.
It works with any language your project uses — the pipeline reads your build system and test framework, not the other way around. The 11 named steps cover the PRD-generation phase; the 9 post-PRD implementation steps are optional and separately gated.
Get Started in 2 Commands
Install, run. The reducer handles the rest.
Install the plugin
> /plugin marketplace add cdeust/ai-architect-mcp-spec
> /plugin install ai-architect-mcp-spec@ai-architect-mcp-spec-marketplace
Run the pipeline
> /generate-prd "describe the feature here"
The reducer detects context, grounds the feature on your code graph (if ai-architect-mcp-codebase is installed), clarifies, generates, and exports a verified 9-file PRD.
11 steps, each with a defined state transition
A stateless reducer: every step reads the current state, emits one action, and advances. When a generated section fails validation, it retries with the violations injected — then advances regardless, so one bad section never blocks the PRD.
01 Step 1 — Banner
Emits a welcome banner with the run ID, the feature description and a capability summary.
02 Step 2 — Preflight
Probes the required ecosystem MCP servers (Cortex, ai-architect-mcp-codebase) before the pipeline depends on them; skippable via skip_preflight.
03 Step 3 — Context Detection
Classifies the feature description into one of eight PRD contexts — feature, bug, incident, proposal, PoC, MVP, release, or CI/CD — by trigger-word matching. The detected context selects which sections get generated and which validation rules apply.
04 Step 4 — Input Analysis
Calls ai-architect-mcp-codebase's analyze_codebase (index + resolve + cluster in one call), then prepare_prd_input to ground the feature on the real code graph — matched symbols, impacted communities, impacted processes. Without a codebase path, this step degrades gracefully and the PRD is generated from the description alone.
05 Step 5 — Feasibility Gate
Detects epic-scope signals in the feature description — multiple distinct features joined by “and,” “+,” or comma-separated nouns — and asks the user to pick one to focus on. Otherwise passes through.
06 Step 6 — Clarification
A two-phase loop: an engineer subagent composes a targeted question with options and rationale, the user answers, and the loop repeats until a clean proceed-signal is set. Bounded rounds — it does not ask forever.
07 Step 7 — Budget
Allocates the per-section retrieval and generation token budget (a 60/30/10 split from the Cortex context-assembly paper). The host can inspect the numbers through the coordinate_context_budget MCP tool.
08 Step 8 — Section Generation
The core authoring loop, per section: recall Cortex context for that section, spawn an engineer subagent to draft it, validate deterministically, retry with the violations injected as context on failure, and advance to the next section on pass — or after retries are exhausted, so one bad section never blocks the PRD.
09 Step 9 — JIRA Generation
Spawns an engineer subagent to turn the acceptance criteria, user stories, and requirements sections into JIRA tickets, stored as a synthetic section so file export can pick it up.
10 Step 10 — File Export
Writes the PRD deliverable: 6 core files plus up to 3 companion files, and a run-notes file if any section was skipped. No placeholder files — a companion file whose source section produced no content is never written.
11 Step 11 — Self-Check
Two phases: a multi-judge verification batch over every generated section, with a panel chosen per claim type (architecture: Liskov, Alexander, Dijkstra; performance: Fermi, Carnot, Curie, Erlang; security: Wu, Ibn al-Haytham; data model: Mendeleev, DBA, Lavoisier; acceptance criteria: Toulmin, Popper); then combining deterministic validation violations with the multi-judge report into the final verification summary. Not the end — from here the same runner can advance into an optional implementation → testing → review → pull-request loop, gated by a mandatory human decision at pr_gate.
Why this architecture matters
Steps, retries, and verification that isn't one model grading another.
Reducer, not monolith
Most AI PRD tools run a single prompt-to-document pass. This pipeline is a stateless reducer with 11 named PRD steps, each reading current state and emitting one action. Every step's output is inspectable on its own — you get an artifact at every transition, not just at the end.
Retry the section, not the run
When a generated section fails deterministic validation, the pipeline retries that section with the violations injected as context — not the whole PRD. When the retry budget runs out, it advances anyway rather than blocking the entire document on one section.
Verification isn't one model grading itself
Self-check runs specialized judge panels per claim type — architecture claims to Liskov/Alexander/Dijkstra-style reasoning, performance claims to Fermi/Carnot/Curie/Erlang-style reasoning, security claims to Wu/Ibn al-Haytham-style reasoning — plus deterministic Hard Output Rules validators that run zero LLM calls. A distribution_suspicious flag catches confirmatory bias when every judge agrees suspiciously often.
| Property | Typical AI PRD tool | ai-architect-mcp-spec |
|---|---|---|
| Structure | Single prompt → document | 11-step stateless reducer, one action per step |
| Grounding | Description only | Optional real code-graph grounding via ai-architect-mcp-codebase |
| Verification | None, or one LLM re-reading its own output | Specialized multi-judge panels per claim type + deterministic validators |
| Failure handling | Regenerate the whole document | Retry the failing section only, bounded, then advance |
| Output | One document | 9 files: 6 core + up to 3 companion |
| Beyond the PRD | Manual handoff to a coding agent | Optional implementation → testing → review → PR loop, same runner |
This is not CI/CD
CI/CD runs after code is written. This pipeline can write the code.
CI/CD triggers when a developer pushes code: build, test, deploy. It assumes a human wrote the code. This pipeline operates upstream — it takes a feature description and produces the PRD, and on request the code, tests, and pull request that your CI/CD system then validates. It does not replace your build system. It feeds it.
| Aspect | Traditional CI/CD | This pipeline |
|---|---|---|
| Trigger | Code push by developer | Feature description |
| Input | Source code | Unstructured requirements |
| Output | Build artifact, deploy | Verified PRD (9 files); optionally a pull request with code, tests, and docs |
| Code authorship | Human developer | Autonomous engineer subagent, human-gated at pr_gate |
| Verification | Test suite only | Test suite + multi-judge PRD verification + deterministic Hard Output Rules |
| Retry strategy | Re-run same build | Retry the failing section or the failing implementation with the failure context injected |
| Scope | Build → Deploy | Feature description → PRD → (optional) Pull Request |
It can generate the commits. Your CI/CD still validates and deploys them.
ai-architect-mcp-codebase works with your stack
Full AST indexing across 10 languages — the grounding layer, not a code-generation restriction. ai-architect-mcp-spec itself is language-agnostic.
ai-architect-mcp-codebase reads your project's real structure — imports, call chains, communities, execution processes — across these 10 languages with full AST. Every other file type (docs, config, binaries) is still indexed as a File node. The PRD reducer itself has no language restriction: it reads your build system, test framework, and directory structure, and runs your test suite natively during the optional implementation loop.
Where this pipeline fits in an engagement
ai-architect-mcp-codebase and ai-architect-mcp-spec do the grounding and verification work inside the paid pilot — working automations built against your own code and a measured before/after, not a one-time demo.