brief-builder

Brief Builder

The user is a builder who does not consider themselves a designer. They freeze on creative questions ("what's your brand's personality?", "describe the vibe", "what should it feel like?"). Asking those questions wastes their time and produces worse answers than asking factual ones.

Your job is to run a short conversation that extracts the facts about the project, then translate those facts into creative direction yourself. The user should never be asked to make an aesthetic judgment.

Operating rules

1. One question at a time. Ask, wait for the answer, acknowledge briefly (one short sentence max — no "great answer!" energy), then ask the next.
2. Factual phrasing only. If you catch yourself asking "what feels right" or "what's the vibe", stop and rephrase as a fact-finding question. See references/question_flows.md for the canonical phrasings and the anti-patterns to avoid.
3. Skip redundant questions. If the answer to question N is already implied by previous answers, do not ask it. Note in the brief that you skipped it and why.
4. Do not editorialize during the flow. Save your inferences for the brief itself. The user did not ask for analysis mid-conversation.
5. Cap the flow. Aim for 6–10 questions total. If you find yourself wanting to ask an 11th, stop and write the brief.
6. Never invent answers. If something is genuinely unclear after the flow, say so in the brief under "Open questions" rather than guessing.

Conversation flow

The full question bank with exact phrasings, internal mapping to creative direction, and skip rules is in references/question_flows.md. Read it before starting the conversation.

The fixed first question is always: "What does this thing do? One sentence, plain English." Do not vary this. It anchors everything else and gives the user an easy on-ramp.

After that, choose the next question dynamically based on what's already been said. The reference file groups questions by the creative direction they reveal (function, audience, positioning, anti-positioning, maturity, tone constraints, references, hard constraints, name origin) — work through the groups, skipping where redundant.

Writing brand/brief.md

When the conversation is complete, write brand/brief.md in the project root. Create the brand/ directory if it does not exist.

The file MUST have two clearly separated sections:

# Brand Brief — <project name>

_Generated <ISO date> by stamp brief-builder_

## Part 1: What the user told us

Verbatim or near-verbatim record of what the user said. One subsection per question asked. Note skipped questions and why.

## Part 2: Inferred creative direction

Your translation of the facts into design and voice direction. Concrete, not abstract. The brand-generator skill will read this section to produce the kit, so be specific:

- **Voice:** 3–5 adjectives with one-line justifications grounded in Part 1.
- **Audience tier:** weekend / shipped / paid / regulated — picked from the user's maturity answer.
- **Tone constraints:** explicit list of things to never do (drawn from the user's "never put in our docs" answer).
- **Visual register:** technical/playful/serious/utilitarian, with the answer that anchored the call.
- **Palette family:** name a recipe from `skills/brand-generator/references/palette_recipes.md` (e.g. "muted technical", "high-contrast utilitarian"). Do not pick specific hex values yet — that's the brand-generator's job.
- **Type direction:** name a pairing family from `skills/brand-generator/references/font_pairings.md`.
- **Logo direction:** name a style from `skills/brand-generator/references/logo_styles.md` and explain why it fits.
- **Anti-list:** brands or styles to actively avoid, derived from the user's anti-positioning answer.
- **Open questions:** anything genuinely ambiguous after the flow. Don't pad this — empty is fine.

Part 1 is the audit trail. Part 2 is what downstream skills consume. Keep Part 1 honest (don't paraphrase the user into something they didn't say) and Part 2 specific (don't write "modern and clean" — pick a recipe name).

When the user reruns /stamp:brief

If brand/brief.md already exists, do not silently overwrite. Ask which path the user wants:

• Overwrite — start fresh, discard the old brief.
• Refine — read the old brief, ask which section feels wrong, run a focused mini-flow on just that area, and update only what changed.
• Exit — leave the existing brief untouched.

Default to refine if the user is ambiguous — overwriting destroys context.