using-maxgfrlisted

# using-maxgfr Three skills, one loop: a plan is written and approved, the plan is built, the build is proven. Each hands off to the next by a file on disk, so none of them needs the conversation that produced the previous one. | When | Skill | What it leaves behind | |---|---|---| | The user wants a change planned, designed, scoped, or their idea stress-tested — "plan this", "planifie", "grill me" | `blueprint` | `docs/plans/<date>-<slug>.md`, `status: approved` once they say yes | | An approved plan exists and the user says implement it — "build it", "go", "do it", "vas-y", "implémente", "let Codex write it" | `build` | the code, in a worktree, with a step table of exit codes | | You are about to say done, fixed, passing, or working — or the user says "verify", "vérifie", "check my work" | `verify` | a verdict backed by executed commands | Under the plugin the names are `maxgfr:blueprint`, `maxgfr:build`, `maxgfr:verify`; installed with `npx skills add` they are the bare names. ## Fire-and-forget `build`, `build peer`, `verify` and `blueprint auto` are **launched, not discussed**. Each has a deterministic Phase 0 — find the plan, pin the diff, make the worktree, detect the gates — and then calls the Workflow in the same turn. No clarifying question, no summary of what is about to happen, no "shall I proceed": the approval already happened, in the plan file, in as many words. The only refusal is a missing or unapproved plan, and it is one line. `blueprint` is the excep