FAQ
The honest objections.
Every question below was actually raised — by stakeholders, eng leads, and the project's own validation log. Each answer names the doc or command where you can check it.
“Isn’t this just overhead?”
Only at the depth you configure. Effort is a per-stage dial in
blueprint.yml —
low through
max — so a demo runs lean and a launch runs thorough
(ADR-0003).
The only hard stop is dropping a stage below its default effort with no written justification.
What that buys: a confident, unverified claim can’t ride into the deliverable — fact-check blocks before deploy.
“Is anyone actually using this?”
Less than the polish implies. One external team engagement is in flight — a partner solutions architect running a
real client build on it — and the registry
(consumers.yml)
holds one independent external adopter; the rest is the author’s own projects.
blueprint fleet prints the live
count, so no number here can rot. Every methodology change is public in
WAVE-LOG.md,
and the demand assumptions — including the disconfirmed ones — are written down in
validation-script.md.
“Does this only work with Claude Code?”
No — most of the gates are plain Node scripts. 15 of the 18 reviewer gates ship as executable
.mjs and run from any terminal or CI;
3 judgment-heavy reviews and the stage skills need Claude Code.
blueprint review --list prints the executable set;
the .md-only specs sit beside them in
the reviewer directory.
| Capability | Where it runs |
|---|---|
15 of 18 reviewer gates (executable .mjs) | Any terminal or CI — blueprint review <name> |
3 judgment-heavy reviewer specs (.md only) | Claude Code, as agents |
The CLI — init · review · cost · fleet · upgrade · doctor · hive | Any terminal, Node 18+ |
Stage skills (/blueprint-research → /blueprint-deploy) | Claude Code |
“I already have my own spec loop. Why switch?”
Honestly: solo, don’t. A working personal loop beats a new one, and the field data says practitioners keep theirs
(validation-script.md, assumption A6).
Blueprint earns its keep at the team seam: a shared definition of done, one pinned methodology version,
and blueprint fleet flagging projects that drift.
If the build still feels fast and handoffs aren’t breaking, keep your kitchen — the adoption signal is the entropy wall in
variant-selection.md.
“A solo run isn’t production-grade.”
Agreed — a stakeholder said exactly this, and it’s on the record (validation-script.md, assumption A7). The reviewer fleet is agent gates: it checks the work product, not authority. Role sign-offs — PM vets requirements, engineering vets spec and code — sit on top as your team’s process; team-roles-and-conventions.md is the operating model for that. Blueprint doesn’t replace approval; it makes what’s being approved verifiable first.
“What if the agent skips a gate?”
Gates aren’t honor-system; they’re processes with exit codes.
blueprint review <name> --target=<dir> fails CI like any other check,
and blueprint doctor exits non-zero when its checks fail.
Running a stage below its default effort requires a written justification
(skip_justification in
blueprint.yml), and the cost-gate reviewer raises a blocking finding when it’s missing
(ADR-0003).
“How is this different from Spec Kit, BMAD, or GSD?”
The pipeline shape isn’t — staged spec-driven development is a crowded, named category, and Blueprint’s stages converge on the same pattern everyone else’s do. The difference is where enforcement lives: the field’s gates are mostly human approve prompts or checklists the LLM grades itself against, with the executable exceptions checking file existence or spec schema; Blueprint’s are Node scripts with exit codes that check artifact content and evidence, plus a document-level fact-check stage and self-application receipts (this site is the pipeline’s own output). The source-level read of the field — what each tool’s gates actually do, generously — is at /compare.
“What does it cost to try?”
One command, nothing persistent. npx runs the CLI
without installing it; there’s no server, no account, nothing to sign up for.
The scaffold it writes is MIT-licensed and lives in your repo — deleting the directory is the whole uninstall.
--name is the only required flag; every default the stamp
applies is echoed back, and any flag overrides it. The command runs as printed.
$ npx @nino-chavez-labs/blueprint-cli init --name=my-initiative“Why not just better prompts?”
Prompts don’t leave receipts. A good prompt produces a good artifact once; nothing records why, and the next session re-derives it or quietly contradicts it. Blueprint’s stages emit artifacts that cite each other — research feeds decisions, decisions are recorded where the prototype can cite them, and fact-check verifies claims against source before anything ships (METHODOLOGY.md). Six months later, “why is it built this way” has a paper trail.
“What happens when the methodology updates?”
It asks before it touches anything. blueprint upgrade is
dry-run by default — it reads the methodology version your project pins, shows what changed, and writes only when
you confirm. blueprint fleet reports which projects have
fallen behind, so drift is visible instead of silent.
The channel runs both ways: initiatives promote their workarounds upstream — most recently a consumer initiative
built and battle-tested the verification-ladder mechanics the spec had deferred, then promoted them into the
template (wave 62, 2026-06-11; the
wave log
records every promotion).
Objections handled? Watch it run on the live demo, or start at Learn and run it yourself.