architect-quick
Fast-track blueprint — three questions, smart defaults for everything else, still validator-gated. For when you just want it built. / Blueprint express — tres preguntas, defaults inteligentes, con el mismo validador.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/Hainrixz/the-architect/HEAD/commands/architect-quick.md -o ~/.claude/commands/architect-quick.mdarchitect-quick.md
# `/architect-quick` — fast-track
You are being invoked as `/architect-quick`. Same machinery as `/architect`, compressed interview.
Read the skill first — it is still the source of truth:
- Plugin install: `${CLAUDE_PLUGIN_ROOT}/skills/architect/SKILL.md`
- Clone install: `./CLAUDE.md` at the repo root — the clone-mode mirror of the skill. Same rules,
same state machine, repo-relative paths, and the subagent work done inline.
## Mode
| Setting | Value |
|---|---|
| Entry | Greenfield |
| Depth | 3 questions, one message, then defaults |
| Output | **Recommend single file** — quick mode implies a small build — and confirm it, because `${CLAUDE_PLUGIN_ROOT}/questions/phase-4-generate.md` **Step 2 is authoritative on emission mode**. This row is input to your recommendation, not the decision. Fold the confirmation into the architecture card in Flow step 3 so it costs no extra round. Confirmed single file → `./blueprints/<project-slug>-blueprint.md` in the user's cwd; bundle → `./blueprints/<project-slug>/`. |
| Gate | `blueprint-validator` must return **PASS** — speed does not buy an exemption |
## The three questions — ask all three in ONE message
1. **What is it?** One or two sentences.
2. **Who uses it?** Public users, an internal team, other developers — and roughly how many.
3. **Any tech you must use or must avoid?** Existing stack, hosting constraint, language. "No
preference" is a valid answer and the fastest one.
If `$ARGUMENTS` already answers Q1, say so and ask only Q2 and Q3. Do not re-ask what you were told.
Then stop asking. Everything else is a default you choose and **state out loud**.
## Defaults — decide, announce, do not ask
| Decision | Default |
|---|---|
| Shape | Classify from the three answers using `${CLAUDE_PLUGIN_ROOT}/questions/phase-1-discovery.md`. Ambiguous → pick the closer one and say which and why. |
| Runtime track | The shape file's **Default runtime track**. Deviate only if Q3 forces it. |
| Capabilities | The shape file's **Core capabilities** table, nothing extra. |
| Pins | From the `stack-researcher` report produced in this session — it is authoritative. `${CLAUDE_PLUGIN_ROOT}/knowledge/runtime-tracks/<track>.md` is the fallback for any package the researcher did not resolve, and its unverified caveats carry through verbatim. Never write a pin from memory. |
| Stage | MVP. Testing is smoke-level, observability is logs plus error tracking. |
| Scope | The shape's build order, trimmed to what ships something usable. |
## Flow
1. Ask the three questions. Wait.
2. Classify the shape. Read `${CLAUDE_PLUGIN_ROOT}/knowledge/shapes/<shape>.md` and its default
runtime track. Check `${CLAUDE_PLUGIN_ROOT}/knowledge/stack-compatibility.md` for known-bad pairs.
3. Print a **6-line architecture card** — shape, track, data store, auth, hosting, scope — and one
line naming the recommended output mode (single file). Ask for a single yes. This is Phase 3
compressed, not skipped: the user still signs off before you write, and that same yes is the
Step 2 emission-mode confirmation `phase-4-generate.md` requires. If they ask for a bundle
instead, take it and move on.
4. Dispatch `stack-researcher` to verify pins.
5. Dispatch `blueprint-writer` to emit the blueprint from
`${CLAUDE_PLUGIN_ROOT}/templates/blueprint-template.md`,
`${CLAUDE_PLUGIN_ROOT}/templates/claude-md-template.md`,
`${CLAUDE_PLUGIN_ROOT}/templates/tasks-schema.md`, and
`${CLAUDE_PLUGIN_ROOT}/templates/epic-template.md`. Tell it the output mode explicitly — the one
the user confirmed in step 3, not the one you recommended. In single-file mode the workspace files (`CLAUDE.md`,
`AGENTS.md`, `.claude/`) are fenced code blocks inside Section 19, not real files, and there is no
`tasks.json` and no `epics/`. **`.claude/commands/` is never emitted in either mode.**
6. Dispatch `blueprint-validator`. FAIL → fix and re-run. Do not narrate the failure as a caveat and
hand it over anyway.
## Rules
1. **Never more than one round of questions.** If something is genuinely undecidable from three
answers, pick the reversible option and record it in §20.3 Decision log with its
`Would reverse if` trigger. The blueprint has no Open Questions section by design — an unresolved
marker left in the deliverable is a validator BLOCKER.
2. **Every build step still gets an observable "Done when"** and a verify command. This is the part
people try to cut for speed. It is the part that makes the build survive.
3. **State every default you applied** in the summary, so the user knows what they got by omission.
4. Detect and use the user's language.
## After completion
Print the output path and the applied-defaults list. Bundle → the task count and: run
`/architect-next` from the target project root to start. Single file → say resume is manual and hand
over the path. If any default is wrong, `/architect` does the full interview instead.Adversarially audits a finished blueprint bundle and returns PASS or FAIL with line-referenced findings. Use before handing any blueprint to the user or to a build agent, and again after fixes. Read-only, Grep-driven, no shell. Fails on verify commands that reference files no build step creates, unobservable or machine-undecidable acceptance criteria, a migration with no Section 9.1 parity and cutover plan, missing sections, an empty Non-Goals scope fence, steps with no checkpoint tag, oversized steps, undocumented env vars, verify commands missing from the settings.json allowlist, dangling references, bad skill references, surviving placeholders, invented filenames for tool-generated artifacts, workspace files that are malformed or unignorable under the blueprint's own linter config (formatter *execution* is handed to the main thread's smoke test, not guessed at here), pins that imply verification that never happened, pins that no step ever installs, a step that retroactively breaks an earlier step's verify gate, an emitted runner config that cannot resolve a package the blueprint mandates, a standalone tool reading env vars nothing loads, an asserted count that disagrees with the blueprint's own content, checkpoint tags with no repository initialisation, an ignore file excluding a file the blueprint calls committed, two emitted artifacts that state the same path, entry point, name or port differently, an entry point that is built but never invoked, an emitted config that does not exclude the bundle's own path, a guard that exits non-zero on the path it guards against, a step Verify that asserts repository state only that same step's Checkpoint could produce, a byte-exact golden file or expected-output example that contradicts the blueprint's own data model or quotes a message only the pinned runtime could have produced, a gate whose pass condition is any non-zero exit so a usage error satisfies it vacuously, an ignore file or governing config delivered after the command it governs, and a tasks.json that does not match its epics. Triages pattern hits before filing them — an approval gate or a notarization command whose criterion resolves on this machine is correct work, not a finding.
Composes the finished blueprint from the interview findings, the chosen shape, the runtime track, and the selected capabilities — and in bundle mode writes the whole bundle: blueprint.md, tasks.json, epics/, and workspace/ (CLAUDE.md, AGENTS.md, .claude/, and the §19.6 verify-critical config files the gates need to run). Use after the architecture has been confirmed with the user, so the long generation runs in isolated context instead of flooding the interview thread. Its prompt must state the output mode. Returns the written paths, section coverage, an assumptions log, and any gap it refused to invent an answer for.
Resolves package versions and package identifiers against authoritative sources — the published artifact first, then the registry — before either is written into a blueprint. Use PROACTIVELY whenever a version is about to be pinned, a runtime track is refreshed, an export or option name is in doubt, or the user asks "what version should we use". Its report is authoritative over any cached runtime-track file. Returns package → current stable version → source URL → date checked, and flags prereleases, versions the rest of the stack cannot accept yet, unmaintained packages, and anything it could not verify.
Run the blueprint-validator against an existing blueprint and report PASS/FAIL with specifics. Blueprints written before v2 will FAIL — they have no acceptance criteria. That is expected, not a bug. / Audita un blueprint existente con el validador; los blueprints v1 fallan porque no tienen criterios de aceptación.
Design a change against an existing codebase — maps the repo's stack, conventions, structure and tests, then emits a blueprint for a feature, refactor, or migration instead of a from-scratch build. / Diseña un cambio sobre un repo existente — mapea stack y convenciones y emite un blueprint de cambio, no de proyecto nuevo.
Resume a build — reads tasks.json from a bundle, finds the first pending task whose dependencies are all done, and prints it with its epic, acceptance criteria, and every verify command. This is what lets a long build survive across sessions. / Reanuda una construcción desde tasks.json y muestra la siguiente tarea desbloqueada.
Re-verify every pinned version in an existing blueprint against the live registries and report what moved, what breaks, and what to change — un-rots a months-old blueprint without a redesign. / Reverifica cada versión fijada en un blueprint contra los registros y reporta qué cambió y qué romper.
>-