/architect
Interview, design, and emit a self-contained build bundle for a new project — 4 phases, acceptance criteria on every step, validator-gated. / Entrevista, diseña y genera un bundle autocontenido para un proyecto nuevo.
> /plugin marketplace add Hainrixz/the-architect > /plugin install the-architect@soyenriquerocha
How it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/architect
Context preview
What this command does when you run it.
Interview, design, and emit a self-contained build bundle for a new project — 4 phases, acceptance criteria on every step, validator-gated. / Entrevista, diseña y genera un bundle autocontenido para un proyecto nuevo.
Command definition
architect.mddescription: Interview, design, and emit a self-contained build bundle for a new project — 4 phases, acceptance criteria on every step, validator-gated. / Entrevista, diseña y genera un bundle autocontenido para un proyecto nuevo.
argument-hint: "[what you want to build]"
allowed-tools:
- Read
- Write
- Edit
- Glob
- Grep
- Bash
- WebFetch
- WebSearch
- Task
- Skill
- AskUserQuestion
`/architect` — design a new project end to end
You are being invoked as the `/architect` slash command. This file sets the **mode**. It does not contain the interview — the interview lives in `questions/` and is the single source of truth.
**Read these before saying anything to the user:**
- 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.
Read the skill end to end, then execute the four phases exactly as written there.
Mode
| Setting | Value | |---|---| | Entry | Greenfield — nothing exists yet | | Depth | Full 4-phase interview | | Question budget | Max 3 per message, conversational | | Output | Bundle or single file — **ask at phase-4 Step 2**, recommend bundle. Both land in the user's cwd under `./blueprints/`: `./blueprints/<project-slug>/` for a bundle, `./blueprints/<project-slug>-blueprint.md` for a single file. | | Gate | `blueprint-validator` must return **PASS** before you hand anything over |
`${CLAUDE_PLUGIN_ROOT}/questions/phase-4-generate.md` Step 3 is the authority on the emitted tree — do not reproduce it from memory here. One thing worth repeating: **`.claude/commands/` is never emitted into a generated project.** A slash command only fires when a human types it, and an autonomous builder types nothing; repeatable project workflows go in `.claude/skills/<name>/SKILL.md`.
Phase pointers — read, never paraphrase from memory
| Phase | Read | Produces | |---|---|---| | 1 · Discovery | `${CLAUDE_PLUGIN_ROOT}/questions/phase-1-discovery.md` | The shape → `${CLAUDE_PLUGIN_ROOT}/knowledge/shapes/<shape>.md` | | 2 · Deep dive | `${CLAUDE_PLUGIN_ROOT}/questions/phase-2-branches.md` | Runtime track + capability set | | 3 · Architecture | `${CLAUDE_PLUGIN_ROOT}/questions/phase-3-confirmation.md` | Confirmed stack, signed off by the user | | 4 · Generate | `${CLAUDE_PLUGIN_ROOT}/questions/phase-4-generate.md` | The bundle, then the validator |
Supporting files, loaded on demand and only when the phase calls for them: `knowledge/runtime-tracks/`, `knowledge/capabilities/`, `knowledge/stack-compatibility.md`, `knowledge/skills-registry.md`, `templates/blueprint-template.md`, `templates/claude-md-template.md`, `templates/tasks-schema.md`, `templates/epic-template.md` — all under `${CLAUDE_PLUGIN_ROOT}/`.
Arguments
`$ARGUMENTS` is an optional project description. It **seeds** Phase 1 Q1 — it does not replace it.
- Empty → open Phase 1 with Q1 as written.
- Non-empty → treat it as the answer to Q1. Play back the shape you read from it in one line, then
ask the next 2 unanswered Phase 1 questions.
A description in the argument never authorizes skipping Phases 2 and 3. If the user wants speed, that is `/architect-quick`.
Subagents
Dispatch these with the `Task` tool — do not do their work inline.
| Agent | When | File | |---|---|---| | `stack-researcher` | Phase 3, once the track is chosen — verify every pin against the live registry | `${CLAUDE_PLUGIN_ROOT}/agents/stack-researcher.md` | | `blueprint-writer` | Phase 4 — compose the bundle from the confirmed architecture | `${CLAUDE_PLUGIN_ROOT}/agents/blueprint-writer.md` | | `blueprint-validator` | Phase 4, after writing — the gate | `${CLAUDE_PLUGIN_ROOT}/agents/blueprint-validator.md` |
If the validator returns FAIL, fix the bundle and re-run it. Never hand the user a failing bundle with an apology attached.
The rules that matter here
1. **No blueprint before Phase 3 is confirmed.** The user says go, or you keep designing. 2. **Every build step carries an observable "Done when".** WHEN `<trigger>` THE SYSTEM SHALL `<observable response>`. "It works" is not a criterion. 3. **The bundle is self-contained.** A Claude Code instance with zero context builds from it without asking a single clarifying question. 4. **Write to the user's cwd, never inside the plugin.** The plugin cache is not a workspace. 5. **Detect the user's language from their first message** and stay in it — interview and bundle. 6. **Never hard-depend on a skill.** Not installed → fall back to the knowledge base and `WebFetch`/`WebSearch`, say so in one line, keep going.
After completion
Print the bundle path, the task count, the first task id, and one line: run `/architect-next` from the **target project root** to start building. Single-file mode has no `tasks.json`, so say that resume is manual and hand over the path alone.
Read more
description: Interview, design, and emit a self-contained build bundle for a new project — 4 phases, acceptance criteria on every step, validator-gated. / Entrevista, diseña y genera un bundle autocontenido para un proyecto nuevo. argument-hint: "[what you want to build]" allowed-tools: - Read - Write - Edit - Glob - Grep - Bash - WebFetch - WebSearch - Task - Skill - AskUserQuestion
`/architect` — design a new project end to end
You are being invoked as the `/architect` slash command. This file sets the **mode**. It does not contain the interview — the interview lives in `questions/` and is the single source of truth.
**Read these before saying anything to the user:**
- 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.
Read the skill end to end, then execute the four phases exactly as written there.
Mode
| Setting | Value | |---|---| | Entry | Greenfield — nothing exists yet | | Depth | Full 4-phase interview | | Question budget | Max 3 per message, conversational | | Output | Bundle or single file — **ask at phase-4 Step 2**, recommend bundle. Both land in the user's cwd under `./blueprints/`: `./blueprints/<project-slug>/` for a bundle, `./blueprints/<project-slug>-blueprint.md` for a single file. | | Gate | `blueprint-validator` must return **PASS** before you hand anything over |
`${CLAUDE_PLUGIN_ROOT}/questions/phase-4-generate.md` Step 3 is the authority on the emitted tree — do not reproduce it from memory here. One thing worth repeating: **`.claude/commands/` is never emitted into a generated project.** A slash command only fires when a human types it, and an autonomous builder types nothing; repeatable project workflows go in `.claude/skills/<name>/SKILL.md`.
Phase pointers — read, never paraphrase from memory
| Phase | Read | Produces | |---|---|---| | 1 · Discovery | `${CLAUDE_PLUGIN_ROOT}/questions/phase-1-discovery.md` | The shape → `${CLAUDE_PLUGIN_ROOT}/knowledge/shapes/<shape>.md` | | 2 · Deep dive | `${CLAUDE_PLUGIN_ROOT}/questions/phase-2-branches.md` | Runtime track + capability set | | 3 · Architecture | `${CLAUDE_PLUGIN_ROOT}/questions/phase-3-confirmation.md` | Confirmed stack, signed off by the user | | 4 · Generate | `${CLAUDE_PLUGIN_ROOT}/questions/phase-4-generate.md` | The bundle, then the validator |
Supporting files, loaded on demand and only when the phase calls for them: `knowledge/runtime-tracks/`, `knowledge/capabilities/`, `knowledge/stack-compatibility.md`, `knowledge/skills-registry.md`, `templates/blueprint-template.md`, `templates/claude-md-template.md`, `templates/tasks-schema.md`, `templates/epic-template.md` — all under `${CLAUDE_PLUGIN_ROOT}/`.
Arguments
`$ARGUMENTS` is an optional project description. It **seeds** Phase 1 Q1 — it does not replace it.
- Empty → open Phase 1 with Q1 as written.
- Non-empty → treat it as the answer to Q1. Play back the shape you read from it in one line, then
ask the next 2 unanswered Phase 1 questions.
A description in the argument never authorizes skipping Phases 2 and 3. If the user wants speed, that is `/architect-quick`.
Subagents
Dispatch these with the `Task` tool — do not do their work inline.
| Agent | When | File | |---|---|---| | `stack-researcher` | Phase 3, once the track is chosen — verify every pin against the live registry | `${CLAUDE_PLUGIN_ROOT}/agents/stack-researcher.md` | | `blueprint-writer` | Phase 4 — compose the bundle from the confirmed architecture | `${CLAUDE_PLUGIN_ROOT}/agents/blueprint-writer.md` | | `blueprint-validator` | Phase 4, after writing — the gate | `${CLAUDE_PLUGIN_ROOT}/agents/blueprint-validator.md` |
If the validator returns FAIL, fix the bundle and re-run it. Never hand the user a failing bundle with an apology attached.
The rules that matter here
1. **No blueprint before Phase 3 is confirmed.** The user says go, or you keep designing. 2. **Every build step carries an observable "Done when".** WHEN `<trigger>` THE SYSTEM SHALL `<observable response>`. "It works" is not a criterion. 3. **The bundle is self-contained.** A Claude Code instance with zero context builds from it without asking a single clarifying question. 4. **Write to the user's cwd, never inside the plugin.** The plugin cache is not a workspace. 5. **Detect the user's language from their first message** and stay in it — interview and bundle. 6. **Never hard-depend on a skill.** Not installed → fall back to the knowledge base and `WebFetch`/`WebSearch`, say so in one line, keep going.
After completion
Print the bundle path, the task count, the first task id, and one line: run `/architect-next` from the **target project root** to start building. Single-file mode has no `tasks.json`, so say that resume is manual and hand over the path alone.
A Claude Code plugin that interviews you, designs the whole architecture, and writes a self-contained blueprint another Claude Code instance builds from with zero context — EARS acceptance criteria and a runnable verify command on every build step. 14 project shapes, greenfield and brownfield. EN/ES.
Repo: Hainrixz/the-architect
Other commands on the-architect.
- /architect-audit
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
Open command - /architect-brownfield
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
Open command - /architect-next
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
Open command - /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.
Open command - /architect-refresh
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é
Open command

