From finding to pull request.
10 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. prd-spec-generator runs a 10-step stateless reducer; automatised-pipeline supplies the codebase intelligence it grounds on. Ask it to keep going and the same runner implements, tests, reviews, and opens the pull request.
> /plugin install prd-spec-generator
Node.js 20.x or 22.x. Pairs with automatised-pipeline (Rust 1.94+, CMake) for codebase-grounded input analysis — optional, not required.
automatised-pipeline — the codebase intelligence layer
The 10-step reducer above needs the truth about your code before it writes a PRD. automatised-pipeline 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 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
- 24 MCP tools — across 10 numbered stage-slots
- 10 stage-slots (0–9) — automatised-pipeline implements 8 of them; stages 5 (PRD generation) and 7 (implementation) belong to prd-spec-generator and the coding agent
- 10 languages with full AST
- 434 tests passing, zero warnings
- 45,000+ lines of Rust
- Read-only — never writes code, opens PRs, or runs CI
- Feeds Cortex (workflow graph) and prd-spec-generator (call-graph context)
> /plugin marketplace add cdeust/automatised-pipeline
> /plugin install automatised-pipeline
The plugin compiles the LadybugDB C++ core + Rust binary on first install (~5 min). Cached after. Requires Rust 1.94+ and CMake.
What a /generate-prd run looks like
$ /generate-prd "add rate limiting to the export endpoint" [01/10] banner ........................ OK [02/10] context_detection .............. OK context: feature [03/10] input_analysis ................. OK graph-grounded via automatised-pipeline [04/10] feasibility_gate ............... OK single feature, pass-through [05/10] clarification .................. OK 1 round, proceed-signal set [06/10] budget ....................... OK [07/10] section_generation ............. OK per-section recall + validate + retry [08/10] jira_generation ................ OK [09/10] file_export .................... OK 9 files written [10/10] 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 prd-spec-generator a feature description. It runs a 10-step stateless reducer: detect the PRD context, ground the feature on your real code graph via automatised-pipeline, 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 10 named steps cover the PRD-generation phase; the post-PRD implementation loop is optional and separately gated.
Get Started in 2 Commands
Install, run. The reducer handles the rest.
Install the plugin
> /plugin marketplace add cdeust/prd-spec-generator
> /plugin install prd-spec-generator
Run the pipeline
> /generate-prd "describe the feature here"
The reducer detects context, grounds the feature on your code graph (if automatised-pipeline is installed), clarifies, generates, and exports a verified 9-file PRD.
10 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 and feature description, then advances to a preflight check that verifies Cortex and automatised-pipeline are reachable before the run starts depending on them. Formerly gated behind a license tier inherited from the Swift port — that gate was removed in April 2026; the step is now purely informational.
02 Step 2 — 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.
03 Step 3 — Input Analysis
Calls automatised-pipeline'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.
04 Step 4 — 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.
05 Step 5 — 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.
06 Step 6 — Budget
Validates the proceed-signal invariant set by clarification before transitioning to section generation. Token-budget accounting itself is exposed separately via the coordinate_context_budget MCP tool so the host can see the numbers before committing.
07 Step 7 — 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.
08 Step 8 — 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.
09 Step 9 — 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.
10 Step 10 — Self-Check
Two phases: a multi-judge verification batch over every generated section, with specialized panels per claim type (architecture, performance, security, data model, acceptance); 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 10 named 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 | prd-spec-generator |
|---|---|---|
| Structure | Single prompt → document | 10-step stateless reducer, one action per step |
| Grounding | Description only | Optional real code-graph grounding via automatised-pipeline |
| 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.
automatised-pipeline works with your stack
Full AST indexing across 10 languages — the grounding layer, not a code-generation restriction. prd-spec-generator itself is language-agnostic.
automatised-pipeline 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
automatised-pipeline and prd-spec-generator 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.