# the-architect: blueprints with two blocking gates, four fields per build step, and a marketplace under a different name > A Claude Code plugin that interviews you across 14 project shapes and emits a self-contained blueprint rather than application code. The interview is the product, generation is refused until every underspecified decision is closed, and the second gate judges market viability alongside design. **Hainrixz/the-architect** — 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. - Repository: https://github.com/Hainrixz/the-architect - Website: https://tododeia.com - Stars: 520 · Forks: 100 - Language: Unknown - License: MIT - Published: 2026-09-15 · Updated: 2026-09-15 · Language: en - Canonical page: https://hysenlabs.com/projects/hainrixz-the-architect ## The install command names a different account than the repository The plugin install is two commands typed inside any Claude Code session: ```text /plugin marketplace add Hainrixz/the-architect /plugin install the-architect@soyenriquerocha ``` The two lines do not agree with each other. The marketplace is added from the repository owner, and the plugin is then installed from a marketplace whose identifier is a different name entirely. So the repository you are reading and the marketplace you are pulling from are not obviously the same publisher, and nothing on the page explains the relationship. For a tool whose entire output is a document another agent will execute unattended, that provenance question is not cosmetic. After installing, the command is available in any directory. That is a deliberate design choice worth naming: blueprints are written into a blueprints directory in whatever folder you are currently working in, and explicitly never inside the plugin. So the artefact lands next to the code it describes rather than inside the tool that produced it. The clone route exists as well, and the page says it still works exactly as in the first major version: ```bash git clone https://github.com/Hainrixz/the-architect.git cd the-architect claude ``` Prerequisites are Claude Code and a Claude subscription, with nothing else required. That is the shortest prerequisite list in this category, and it is also the reason the product cannot be evaluated without a subscription in the loop. ## Clone mode keeps the interview and loses the slash commands and subagents The two install paths are described as producing the same output, and on one dimension they genuinely do. Running Claude Code inside a clone reads the instruction file at the repository root and turns the session into the meta-agent. The page claims the same interview, the same gates, and the same output, with blueprints landing in a blueprints directory inside the clone. On the other dimension the page is explicit, and it is a real difference rather than a caveat. The slash commands and the subagents are plugin-only. Clone mode runs the same flow conversationally. That distinction matters more than it first appears, because the subagents are where named roles do work. There is a stack-researcher whose job is to verify every version against the live registries before anything is pinned, and there is a writer that composes and a validator that audits until it passes. In plugin mode those are separate agents with separate jobs. In clone mode they become turns in one conversation, and the same output is produced by a different mechanism. So a reader deciding between the two paths is choosing between a decomposed pipeline and a single conversation that produces a comparable artefact, and the page's framing of them as equivalent is generous rather than literal. The root instruction file is what makes clone mode work at all, which also means it is doing more work in that mode than the plugin manifest is. ## Gate A refuses to generate while a clarification marker is open Two gates run before anything is written, both in the architecture phase, and the page is firm that neither is optional. Gate A is a self-scan for markers. Before presenting anything, the tool reads its own draft and emits a marker for every decision that is still underspecified. The named examples are scope boundaries, delete semantics, who can see whose data, and who owns the API keys. Each marker has exactly three ways to close. You answer it. You confirm a default that the tool has stated out loud. Or it becomes an explicit Non-Goal. Entering generation with an open marker is forbidden. The failure this prevents is described in a sentence worth keeping: a blueprint that reads as complete because the gaps were quietly filled with plausible guesses, and a builder agent that implements the guess at two in the morning with nobody to ask. That is a specific and common failure mode. The mechanism is unusual in one respect: the third way to close a marker is to declare the question out of scope, which means a blueprint can satisfy Gate A by converting an unknown into a Non-Goal rather than resolving it. Whether that is correct depends on how often a Non-Goal is the honest answer, and the page treats all three closures as equivalent. The observable property is simple though. If generation starts, no marker was left open. ## Gate B includes market viability, so a sound plan can go back to redesign The second gate is an adversarial pre-mortem aimed at killing the plan before it is generated. Eight angles are named. Four of them are engineering concerns: false assumptions, execution risk, the blind spot nobody in the conversation is looking at, and a six-months-out obituary. Four are commercial: market, competition, viability, and unit economics. Findings that survive their own rebuttal, between three and seven of them, become Risk Register entries or Non-Goals. If one invalidates the architecture, the plan goes back to redesign rather than shipping with the problem recorded as a risk. That routing rule is where the two halves of the gate collide. A commercial finding can send a technically sound architecture back through design, and design does not usually answer a unit-economics objection. The page does not say what happens then, so the loop has no stated exit other than Non-Goal. The tooling is optional in a specific sense. It uses a devil's-advocate command when that is installed, and runs inline otherwise. The gate is mandatory; only the command is not. Given that the command name is Spanish and the page is in English with a Spanish edition alongside, that split is plausible but coincidental. Between the two gates, the flow is: interview, classify, verify versions live, present one dense architecture message, run both gates there, and only then generate. ## Every build step carries four fields, added because v1 steps had none The blueprint has twenty fixed sections, and section nine, the build order, is described as the reason the other nineteen exist. Each build step carries four fields. What to do, the condition that means done, a command that verifies it, and a checkpoint. The page is explicit that this is a repair rather than a feature. In the first major version steps carried no definition of done, so an autonomous builder had no stopping condition, over-built, and declared victory on work that never ran. That failure mode is worth taking seriously precisely because everything else in the design assumes an agent will work unattended. Gates that block generation are pointless if the generated document then gives the builder no way to know when to stop. The worked example is included on the page, taken from the blueprint template, and it is a Stripe checkout step: an SDK client reading a secret, a route that creates a checkout session for the signed-in user, a signature-verified webhook receiver that parses the raw body, and a single writer to the subscriptions table. Then the example stops partway through a list item, after a hyphen and three letters of a word. The example is also fenced with four backticks rather than three, so that it can contain nested fences. That is the correct choice for showing a document that itself contains code, and it is the kind of detail that suggests the template was written to be copyable rather than merely readable. ## Phase 4 runs 20 to 30 minutes silently, and stating the estimate is required The duration breakdown is given up front, with a heading that says the part nobody warns you about. Once the architecture is confirmed, generation runs roughly twenty to thirty minutes for a bundle and ten to fifteen for a single file, and produces no output until it finishes. The page explains that the time is real work: a live registry call for every version pin, a full composition pass, and at least one validator round trip. What it does not explain is why there is no progress output during any of that. A session that emits nothing for half an hour is indistinguishable from a hung one from the outside. The mitigation is a requirement rather than a feature. The tool is required to tell you the estimate before it starts, and the page says that if it fails to, that is a bug. So the design answer to a silent half hour is a promise made in advance, which is reasonable and is not the same as streaming progress. The four-phase shape also decides bundle versus single file from the step count and says which it chose, so the size of the wait is at least predictable from the output rather than discovered afterwards. The whole path has two documented waits. The interview is interactive and fast, and this phase is not interactive at all. Choosing quick mode mostly changes which of those two you get. ## Three releases in one morning, with notes written as test results The three most recent releases were published on the same day, within about three and a half hours of each other, and the last push to the default branch carries that same date. What makes them worth reading is how they are labelled. The newest notes are zero deviations, the promise holds. The one before is cycle five, fourteen out of fourteen under the strict protocol. The one before that is the literal-builder test. Those are verification outcomes, not feature descriptions. Each names an experiment rather than a change, and the newest one is a claim about a promise holding, which implies there was a promise to hold. The page gives the failures those releases address. Version one had build steps with no definition of done, so builders over-built and declared victory on work that never ran. Version two added the two blocking gates. The four fields per step are described as an anti-drift fix, which is the same failure named again. So the release history reads as a sequence of attempts to make an autonomous builder trustworthy, each validated by something the page counts. Fourteen out of fourteen is the kind of number that appears when a protocol is being tested against a fixed set rather than being used in anger. There is a separate versioning document at the repository root, which suggests the numbering scheme is worth reading before assuming what two point five means. ## Fourteen shapes come from a questions directory, and the blueprint has twenty sections The repository is markdown and configuration, with no detected primary language, and its top level explains the structure of the method rather than the code. There is a questions directory and a knowledge directory. Those two hold the interview material: the fourteen project shapes the discovery phase classifies into, and the question banks the deep-dive phase draws from once a shape is fixed. There is also a templates directory holding the blueprint template the worked example is taken from, a commands directory holding the entry points, and an agents directory holding the subagents. That layout means the fourteen shapes are data, not code. Adding a shape is a question set rather than a branch, which is the right shape for the problem and explains why the discovery phase can classify into one of fourteen without the page documenting what each one is. The blueprint side is fixed at twenty sections. Not configurable, and not generated to fit the project. Section nine is the build order and the other nineteen exist to support it. A fixed template is a deliberate constraint: a builder agent can rely on section nine being where the steps are, and the verify commands are structured by a template rather than invented per project. The cost is that a project needing twenty-one kinds of information has nowhere to put the twenty-first, and a project needing nineteen has a section that says little. Neither is a large problem, and the page does not present the count as anything other than the structure it is. ## Conclusion the-architect is for people who intend to hand work to an autonomous builder and then leave, and the design reflects that: generation is blocked until every underspecified decision has been answered, confirmed as a stated default, or written down as a non-goal. Two things to weigh first. The interview is the product, so the quick path gives you three questions and a document you will probably have to correct, while the full path costs an hour for one you will not. And the second gate fires on market viability and unit economics as well as on design, so a technically sound plan can be sent back for redesign on grounds you may not accept. ## FAQ ### What does the-architect actually produce? A self-contained markdown blueprint rather than application code. A different Claude Code instance with no prior context is meant to build from it without asking a question, and it carries EARS acceptance criteria plus a runnable verify command on every build step. ### How do I install the-architect? As a plugin, with two commands inside any Claude Code session: add the marketplace from the repository, then install the plugin from it. Cloning the repository and starting Claude Code there also works, but that mode runs the same flow conversationally and has no slash commands or subagents. ### What are the two gates in the-architect? Gate A scans its own draft for clarification markers and forbids generation while any is open, so each must be answered, confirmed as a stated default, or recorded as a Non-Goal. Gate B is an adversarial pre-mortem across eight angles whose surviving findings become risk register entries or Non-Goals. ### How long does the-architect take to run? The quick path asks three questions in one message and runs about ten minutes end to end. The full path asks 12 to 16 questions across 6 or 7 messages and runs about 40 to 60 minutes, of which generation alone is 20 to 30 minutes for a bundle or 10 to 15 for a single file, with no output in between. ### Where does the-architect write its blueprints? Into a blueprints directory in whatever folder you are working in, never inside the plugin itself. When run from a clone, they land inside that clone instead. The only stated prerequisites are Claude Code and a Claude subscription. ## Sources - [Hainrixz/the-architect on GitHub](https://github.com/Hainrixz/the-architect) - [License: MIT](https://github.com/Hainrixz/the-architect/blob/main/LICENSE) - [Project website](https://tododeia.com) - [README](https://github.com/Hainrixz/the-architect/blob/main/README.md) - [Releases](https://github.com/Hainrixz/the-architect/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hainrixz-the-architect