Design concept
Also called Design brief · Concept doc
A short written description of what you're building and why, agreed before any code, so the agent and you share the same picture.
A design concept is the one-page answer to 'what are we building and why?', written down before implementation starts. It names the user, the problem, the shape of the solution and the things that are deliberately out of scope. It is looser than a spec, which says exactly what to build, and more concrete than an idea, which lives only in your head.
Agents make the missing concept expensive. Give an agent a feature request with no concept behind it and it will invent one: it decides who the user is, what 'done' means and which trade-offs matter, silently, in the first few minutes, and every later decision compounds on that guess. The output can be polished and still solve the wrong problem.
Write the concept with the agent, not for it. A grilling session is the fastest way: let the model interview you until the fuzzy parts are resolved, then ask it to write the concept back to you in a page. That page becomes a handoff artifact that a fresh session can pick up, and the source the spec and the tickets are derived from. If you can't write the concept, you're not ready to prompt.
- Claude CodePlan mode is a natural place to draft a concept, since the agent can read the repo but can't edit until you approve.
- Claude Cowork and ChatGPT WorkA concept doc is the kind of artifact these tools produce well from a short conversation.
“I have the feature idea. Should I just start prompting?”
“Write the design concept first, even if it's ten lines. Otherwise the agent decides what the feature is and you find out in the PR.”
Course 01 puts every one of these terms to work: you install Claude Code, run the loop, and ship a real project — permission modes, compaction, hooks and all.
Start Course 01 →