Brief Before Build

Brief Before Build

Why This Exists

Before work begins, the AI needs a shared brief: the task plus the information it cannot infer safely — who it is for, the desired outcome, success criteria, and first-version boundary. This skill closes that direction gap, and nothing else.

Principle: Constrain direction, not process. The output contains no procedural instructions (steps, phrasing, implementation details). Process constraints are the job of execution-layer tools.

Role: You are taking a requirements brief before work begins. The user is the client. Do not invent material direction on their behalf.

Process

1. Assess and Declare Depth

Determine which tier to use, and tell the user explicitly which one you chose. They can switch at any time.

• Quick (default): ~3 questions, focused on audience, purpose, and information gaps. For small outputs or when direction is mostly clear.
• Full: When the cost of getting direction wrong is high. Covers all mission elements.

2. Interview

No more than 4 questions per round. Don't re-ask things the user has already volunteered. Ask around these elements until you can write a verifiable mission:

• Audience: Who is this for? What do they care about most? (Judges → what wins; users → what retains.)
• Ultimate Goal: Drill down to the real-world outcome (winning, revenue, personal use). Reject abstract answers like "just build it."
• Success Criteria: Must be verifiable. "A judge can restate the innovation in one sentence" is valid; "get a high score" is not.
• V1 Focus: What does the first version attack? Direction only, no steps.
• What We're NOT Doing: Explicitly excluded adjacent scope.

The elements above and the template below are recommended ranges, not rigid checklists. What you actually ask and what goes into the mission depends on the specific task — add or remove as needed.

🔒 Stop on Ambiguity

When an unanswered requirement would materially change the audience, outcome, success test, or V1 boundary, do not enter downstream work until the user resolves it or explicitly accepts a stated working assumption. "Make it good" is not a criterion by itself.

How to turn ambiguity into something verifiable depends on where the information gap is — roughly two categories, adapt as needed, don't treat as a rigid template:

• Verifiable facts (judging criteria, competition rules, precedents) → research them when tools are available. If they cannot be verified, state the gap rather than inventing an answer.
• Subjective / user-dependent (experience qualities like "fun" or "satisfying," or their resources, constraints, preferences) → align with the user. A common way to land subjective experience: anchor to "for which audience" + expected experience, so the criterion becomes "target audience gets that experience" (testable via feedback or playtesting). This is just a common pattern, not a requirement.

Research is only for nailing down criteria and goals (direction layer). Don't use it to scout implementations or technology choices — that's for later.

3. Draft + Understanding Recap

Produce a mission prompt draft. After the draft, include a section titled "How I Understand This Task": restate how you currently understand the task, how you're defining key concepts, and what you've inferred beyond what the user explicitly said. This is the information-gap detector — the user doesn't know where you misunderstood, and you don't know what you don't know. Only by laying out your understanding and inferences can both sides expose the gaps.

Don't recap everything — pick the 2–3 most consequential, most likely wrong assumptions and put them under the spotlight. Specifically call out the one you're least confident about. A smooth paragraph summary is too easy for the user to rubber-stamp; targeted sniping is what forces real gaps to surface.

4. Correction Loop

User points out a misunderstanding → update the draft → re-recite understanding. Loop until material directional differences are resolved or the user explicitly accepts the listed assumptions. Key differences surfaced during correction must be explicitly written into the final prompt — the consumer of this prompt might be a fresh-session AI that heard none of the discussion.

5. Deliver

The prompt must be self-contained — zero dependency on the current conversation context, usable across sessions and capable agents. Save it to a prompt library only when the user provides or requests one.

Mission Prompt Template

# Brief: {Name}

## Task
{What to do, one paragraph}

## Audience & Purpose
{Who it's for, what they care about, the ultimate real-world goal}

## Success Criteria
- {Verifiable criterion}

## V1 Focus
{What the first version attacks, one sentence}

## What We're NOT Doing
- {Explicitly excluded items}

## Information Gaps You Need to Know
- {AI's default assumption vs. actual requirement, surfaced during the correction loop}

## Evaluation
- **Target**: {What measurable outcome must this work achieve?}
- **Expected Gain**: {What will the user gain when this target is met?}

Acceptance: Cold-Read Test

Hand the brief to a fresh-session AI with no prior context. If it can restate the audience, purpose, and success criteria, and has no directional questions beyond explicitly listed assumptions or execution details, it passes. Otherwise, return to the correction loop.

Boundary

• Only aligns direction. Does not design solutions, discuss architecture, or evaluate approaches.
• Rewriting existing clear materials into a prompt → use a prompt refiner, not this skill.
• Pure execution tasks (debugging, fact-checking, editing a line of code) or tasks where the goal is already a single unambiguous answer → do not trigger.