# Blueprint > Design a new thing BEFORE building it — fuzzy idea to executable blueprint. Use for 'blueprint this', 'design this', 'architect this', 'scope this out', 'I have an idea for X'. NOT murky-problem diagnosis or plan stress-tests (premortem). - Skill: `dylanpulver/blueprint` (Agent Skill) - Install (CLI): `npx skillmds@latest add dylanpulver/blueprint` - Raw SKILL.md: https://api.skillmd.com/api/skills/dylanpulver/blueprint/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dylanpulver (https://skillmd.com/u/dylanpulver) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dylanpulver/blueprint --- # blueprint Take a new thing from fuzzy idea to a design worth executing. The premise (*the pattern is in the threading*): outcomes are mostly decided by choices made before building starts — so spend real effort there, once, and produce ONE artifact a fresh session can execute from cold. The whole skill in one breath: **frame it in a sentence, explore wider than instinct, commit to one shape and defend the pick, attack it before reality does, ship a doc with a kill switch.** Compose, don't reinvent: if you have companion skills for mental-model lenses, structured research, or premortems, route through them rather than duplicating them here. ## GATE Blueprint only what's expensive to reverse or genuinely novel. Known-shape feature or obvious build → plan mode or just build. Repeatable output type → build a pipeline skill for it. Murky "something is wrong" diagnosis → a diagnosis pass, not a blueprint. Say which and stop. Design depth scales with cost of change (Fowler, verified): where tests + CI make change cheap, skipping design is licensed — where change is expensive (data models, public interfaces, hardware, money), it isn't. "Skip upfront design" is a privilege earned by cheap-change infrastructure, never a default. ## FRAME — converge on what this is **Through-line.** One sentence, zero jargon (Heilmeier's first question): what this really is, for whom, and what changes in the world when it exists. Everything downstream is tested against it. Can't write the sentence → the idea isn't ready; say what's missing. For product-shaped things, optionally force the future artifact (Amazon's move — the forcing function is verified, the template isn't): draft the three-sentence day-one announcement a real user would care about, before any architecture. **Interrogate — once, batched, with candidate answers.** ONE AskUserQuestion covering only what swings the design: hard constraints · success criterion (observable) · kill criterion · appetite (an afternoon / a week / a venture). Propose concrete candidate answers as the options — the user picks or corrects; never ask open-ended what you can draft. Infer everything else. Never a second round. Appetite is a design constraint, not an estimate (Shape Up: "appetites start with a number and end with a design"): the time budget is fixed and scope varies to fit it. Every shape in EXPLORE must fit the appetite or name what it drops to fit — never the reverse ("it'll take as long as it takes"). ## EXPLORE — diverge wider than instinct **Steal first** (the reuse ladder, applied to design): 1. Your own repos — does something already do 80% of this? 2. The world — tool/library/product that exists. Unfamiliar domain → do a real prior-art survey (build-vs-buy); don't recall prior art from memory. **Outside view** (Kahneman): name the reference class — who has tried things like this, and what's the base rate? Then find the **desire line**: what do the intended users *already do* (workaround, spreadsheet, hack) that this would pave? An existing desire line is evidence; none found → say so, that's a red flag the interrogate answers must overcome. And Xerox PARC: if others built it and lost, learn whether distribution/timing/model — not the invention — decided it. **Lenses.** Pull 3-5 mental-model lenses that fit the situation (via a lens skill if you have one). Each surviving lens must propose a concrete design MOVE (a mechanism, a cut, an inversion) — drop lenses that only describe. **Three shapes — archetypes, forced apart** so they can't be variants of one idea: - **The lazy shape** — max reuse, near-zero build; the design that's mostly assembly. - **The straight shape** — the obvious, solid way a competent team would build it. - **The inverted shape** — change the problem so the hard part disappears (the clever one; it's allowed to fail, its job is to stretch the space — Ashby: see the possibility set before accepting the restriction). Four lines each: mechanism · deliberately does NOT do · cost vs appetite · reversal cost. ## COMMIT — one shape, defended **Pick one, name the tiebreaker in a sentence.** Never present options without a pick. **Thread the loom.** Split the two registers: - *Locked at setup*: architecture, data model, interfaces, names, incentives — expensive to change later. Decide NOW, each ADR-shaped: the decision, the one-line why, AND the accepted trade-off (what choosing this costs us — a decision recorded without its consequences is half a record). - *Free to evolve*: list it and refuse to design it. YAGNI applies inside blueprints — but only where the GATE's cheap-change condition holds. **The one hard part.** Every real design has exactly one load-bearing difficulty. Zero found → you haven't understood it; three → the scope is wrong. **Elegance gate.** The mechanism must be explainable in two sentences, and each surviving component should feel inevitable given the through-line. Anything that needs an apology gets redesigned or cut here, not defended in the doc. ## ATTACK — break it before reality does 1. Run a premortem on the chosen design (assume it failed; list why); fold real findings back in. 2. Via-negativa pass: walk every component against the through-line; what doesn't serve it gets cut, one line each. The blueprint that survives should feel slightly too small. **Loop-back rule:** any phase may overturn the through-line — that's a finding, not a failure. Rewrite the sentence, then re-test what's downstream of it. One loop-back is healthy; two means GATE was wrong — stop and say so. ## SHIP — the artifact Write `BLUEPRINT-.md` at the target repo root (scratchpad if no repo yet): through-line · constraints + appetite · leverage list (reuse/buy) · outside view (base rate + desire line) · chosen shape + tiebreaker, rejected shapes one line each · locked-at-setup decisions (why + trade-off) · the one hard part · **rabbit holes** (the known risky patches, marked before anyone falls in — Shape Up's most-omitted ingredient) · non-goals · **mid-term exam** (the early checkpoint that shows it's on track — Heilmeier) · **done means:** checkable criteria · kill criterion · first three moves. **Moves are risk-ordered, not build-ordered: move 1 is the cheapest experiment that could kill the design** — it attacks the one hard part or the desire-line assumption, never scaffolding. Prefer a pretotype-grade test (Savoia): fake the thing before building it — a facade, a non-functional mock, a manual stand-in — hours and dollars, not weeks. The doc is timely, not polished (Oxide's RFD norm): it ships rough with a status line — `STATUS: discussion` → `committed` when the user green-lights → `abandoned` if killed — and stays mutable until committed. It must be executable from cold (handoff-compatible). End with the green-light ask: "Blueprint ready — say go and I start with move 1." **The verdict line.** When the success or kill criterion later resolves, append one line to the blueprint doc: `VERDICT : shipped|killed|pivoted — `. Blueprints are judged by what got built, not by how the doc read. ## Depth control Default is one pass, no ceremony. "deep blueprint" → additionally run a deep research pass on the domain and a multi-lens review of the chosen shape before SHIP. Depth is the user's call — the appetite answer covers it; never deep-dive uninvited. Never import evaluation ceremony (ATAM-style scoring matrices, weighted criteria workshops): decades of evidence show industry doesn't use them even in lightweight forms — the tiebreaker sentence is the whole evaluation. Mechanisms here marked "verified" trace to a sourced research pass over the design-before-build literature (Fowler, Shape Up, Heilmeier, Savoia, Oxide RFDs) — steal from them, don't re-litigate them.