Fast Brief

Fast Preset Brief

Fast Preset Conventions

These rules hold across every Fast Preset skill. Other skills assume them - do not deviate.

• Source of truth: BRIEF.md at the repo root. fast-brief writes it; every other skill reads it as step one.
• Files organized per page. UI primitives live in src/components/; prototype data lives in src/data/. Single-page prototypes stay flat (src/components/*.astro, src/data/*.json). The moment a second page is added, each page gets its own folder (src/components/<page>/, src/data/<page>/); anything used by more than one page moves to src/components/shared/ / src/data/shared/. Promote to shared/ on the second use, not before. Pages compose components; props mirror the JSON shape they render.
• Colors: DaisyUI semantic tokens only (bg-primary, text-error, bg-base-100/200/300, text-base-content, etc.). Never raw Tailwind palette colors (bg-blue-500, text-red-600).
• Variants: the same purpose uses the same DaisyUI variant everywhere. Every primary CTA is btn-primary. Every success notice is alert-success.
• Assumption tags: uncertainty stays tracked, not rendered. In BRIEF.md prose, every claim ends in [verified], [assumed], or [unsure] with a reason. In src/data JSON, records derived from [assumed] or [unsure] brief items carry _assumed: true (optionally _source: "brief §X") so they stay findable for the designer and so fast-review can collect them as talking points. The prototype UI itself stays clean - do not render badges, borders, or any other visible tell. The prototype is a design artifact, not a confidence dashboard; assumptions are surfaced in the share conversation, not on the surface.

BRIEF.md dependency: writes it. This skill creates BRIEF.md at the repo root; the rest of the flow reads what it produces.

Workflow

1. Read the source docs end to end before drafting anything.
2. Doubts pass. Before writing the brief, list what is wrong, ambiguous, or low-confidence in the source material. Look for: contradictions between sections, concepts named two different ways, requirements that imply each other but are not connected, passages that read as AI-generated boilerplate (generic phrasing, mismatched terminology, suspiciously round numbers), missing context the designer probably needs to ask about. Lead with the Question. If the source docs do not make clear what decision this prototype is meant to inform, that is the most important doubt - surface it first and ask the user before drafting anything else. A prototype with no nameable Question is decoration. Present this list to the user before producing the brief. This is not a separate skill - it is the first thing fast-brief does.
3. Separate durable product concepts from implementation detail. Keep enough constraints to design responsibly, but do not turn the prototype into a full architecture project.
4. Identify the smallest slice that lets the Question get answered. The First Product Surface is whatever screen, flow, or surface a stakeholder needs in front of them to make progress on that decision. If the slice would not move the Question forward, it is the wrong slice - even if it shows off more of the product.
5. Extract the prototype ingredients: users and roles, core workflows, entities and relationships, statuses and state transitions, approval points and handoffs, important rules and constraints, content types and example records.
6. Recommend the JSON files that will drive the prototype, named after product meaning (cards.json, tickets.json, plans.json).
7. Mark what is intentionally out of scope.
8. Write BRIEF.md at the repo root following the exact schema in references/brief-schema.md. Every prose claim ends with an inline [verified], [assumed], or [unsure] tag and a reason. The consolidated ## Assumptions section lists every [assumed] and [unsure] claim so fast-review and the designer can scan them at a glance.

Scoping Heuristics

• Prefer a working product surface over a complete representation of the business.
• For workflow-heavy products, prototype the operational console or review queue before the invisible backend.
• For AI products, show human approval, confidence, provenance, failure states, and data boundaries.
• For content-heavy products, identify where JSON should hold editable copy, examples, states, and fixtures.
• If docs describe many phases, build the first phase or the most decision-critical slice.

Tag Discipline

• If everything looks [verified], the brief is hiding gaps. Reread the source docs and find at least the assumptions you made about scope, audience, or state coverage.
• Default to [assumed] when in doubt. Designers can confirm an assumption faster than they can spot a hidden one.
• [unsure] is for the docs failing the brief, not the brief failing the docs. Name the specific problem: "two sections disagree on field name," "boilerplate language, no concrete numbers," etc.
• A claim with no tag is a bug. Reject your own draft if you find one.

Output Standard

End the conversation with:

1. The path to the written BRIEF.md.
2. A short summary of the doubts surfaced in step 2 (one line each).
3. A pointer to the next skill - usually fast-data, then fast-prototype. If the repo is not yet an Astro project, run fast-astro first.