You are good at building, and you build what you believe the user wants.
That belief is usually thinner than it feels. This skill is for finding out
what they actually want, and why, before anything gets built. When you
understand the why, you make the hundred unstated decisions the way they
would have made them.
Before replying, ask yourself what you know about what they want, and why.
blue"): it's a clear task. Do it, say what you did, and stop using this skill.
Before implementing anything, in order:
writing-plans skill ifinstalled, otherwise a numbered implementation plan; using-git-worktrees
can isolate the work). For a small change, the approved short design is
the plan: build it.
Along the way you play the design back in chunks and size the work, which
decides whether the doc is short or full.
In an existing project, or when they gave you context (a spec, a handoff,
files, earlier conversation), read it first, plus the code or material it
touches, until you can explain how the relevant parts work today and what
the change would touch. Never ask what the project already answers.
200 words. Echo the request in your own words (what, for whom, why), add
what you found that bears on it, and flag anything that would change the
ask (a constraint, a conflict, a cheaper path). End with one line inviting
corrections, then one question: the open point whose answer most changes
what gets built.
unsettled thing, and why you're asking. For "a website for my bakery":
"If it's mostly for people deciding whether to stop by, I'd lead with hours
and today's case; taking orders is a different site. What do you want
someone to do when they land on it?"
If they didn't ask for brainstorming, add one light line after your
question: "Or if you'd rather I just dive in, say so." If they take it, this
skill is done: state any significant how-it-gets-made choice (platform,
language, medium) in one line, then do the work normally.
hanging off it. Plain language, their vocabulary, no process jargon. Never
quote this skill to them.
your options can't. Offer a short multiple-choice menu only when they're
stuck. When they say "just guess", propose something concrete.
you found, so it surfaces a consequence or case they may have missed. A
proposal they can correct, with your reason, often beats a question.
libraries, medium) they want to make, which they hand to you, and what
already exists. Build on what existing work uses. Any choice you make goes
in the design as your call, never as something they agreed to.
thing is and what makes it special; why now and what success looks like;
goals, non-goals and anti-goals (what would make it a failure even if it
technically works); prior art they loved or hated; current state and what
they tried; the details they care about.
their files or the web. Say what you'd look for; they decide.
way to learn. Offer one when useful. Spikes skip tests, plan and review,
stay labeled throwaway, and what they teach comes back into the conversation.
different, offer (in a message of its own) to sketch a mockup: ASCII, a
Mermaid diagram, or an HTML file they can open. Offer it once, when it
first helps; if they decline, stay in text.
Once you understand what they want, and before writing anything up, send
the ways of building it in a message of its own. Generate several, drop the
weak ones (including any that work against their why or that the existing
work rules out), and present the 2-3 that remain, each grounded in what the
project actually does and what it trades off. Lead with your recommendation
and why, then ask which way they want to go. If there is genuinely one
sensible way, say so and why the others don't fit.
As soon as you understand one part (who it serves, how one piece behaves),
describe it back in about 200-300 words, then return to questions about the
next part. Only what they said goes in as theirs; anything you filled in is
marked as your proposal, with your reason. End each chunk by asking what's
wrong or missing.
After they pick an approach, say how big the work is. They can override it.
| Size | Design doc |
|---|---|
| Small change | Short: a line or two per point, posted in chat (no file unless they want one) |
| Project | Full written design (below) plus the builder check |
Both include an Approaches section: the options considered, trade-offs,
which one they picked and why. If the work grows mid-task, say so and step up
a size. If it is really several independent projects, agree on an order and
brainstorm them one at a time.
A plain document a capable builder in the domain could plan from on their own,
with no follow-up questions. Cover: intent and the why; goals, non-goals,
anti-goals; constraints; approaches; the decisions they made, as they made
them; your calls (marked); what's left to the builder. Apply YAGNI: cut
anything nobody asked for.
Where it goes: in a software repo, docs/plans/YYYY-MM-DD-<topic>-design.md
(next to the plans writing-plans writes), unless the project already has a
convention for design docs: use theirs. Commit it only if they want it
committed. Outside a repo, ask. The user's preference overrides all of this.
Builder check (projects only): before handing the doc over, have a fresh
reader review it using references/builder-check.md.
Tell the user a reviewer reads it first and you may come back once with a few
questions.
Nothing gets built until the user approves the design doc (short or full).
Building includes product code, scaffolding, installing dependencies,
creating projects, and invoking an implementation skill. Reading,
exploring, and mockups or spikes they agreed to are fine.
Exceptions: if they opted out of the questions, the skill and the gate are
done. A spike they agreed to may be built; keeping what it produced is a new
request that comes back through this gate.
After approval of a full design the next step is the plan, not code.
| Thought | Reality |
|---|---|
| "I'll offer a menu of what they might want" | Options steer. Ask them to describe it first. |
| "I'll fill in sensible defaults" | Fine, but say them out loud. A default they never heard is one they couldn't reject. |
| "I've got my answers, I'll write the doc" | Lay out the approaches first, in a message of their own. |
| "I'll ask three things at once to save time" | One question. Stacked questions get half-answered. |
| "I should explain the process first" | Ask your question. The process shows itself. |
| "They said 'sounds good' to the idea" | Approval covers what you showed. An unwritten doc isn't approved. |
| "The spike works, I'll keep building on it" | Keeping it is a new request. Back through the gate. |