Fast review

Fast Preset Polish Pass

A fresh-eyes pass after a build session. The designer has been heads-down; this skill catches what they stopped seeing and tightens the prototype before it gets shared.

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: hard. fast-review compares the rendered prototype against BRIEF.md; without it there is nothing to review against. If BRIEF.md is missing, refuse to run and direct the user to fast-brief.

Workflow

1. Read BRIEF.md. Note the Question This Prototype Answers, First Product Surface, Core Workflow, Must-Show States, and the consolidated ## Assumptions and ## Open Questions sections. The Question is what the spec adherence and answers-the-question lenses check against.
2. Run the prototype (npm run dev) and open it in the browser.
3. Walk the primary flows at both desktop and mobile widths. Use screenshots when available.
4. Look at the prototype as a working product surface, not as isolated screens.
5. Collect assumption talking points (see Polish Lenses below). Cross-reference the ## Assumptions and ## Open Questions sections of BRIEF.md with records carrying _assumed: true in src/data. Produce a short list the designer can mention verbally when sharing the prototype - that is where uncertainty gets surfaced, not in the UI.
6. Fix the obvious things directly: spacing, alignment, missing states, inconsistent DaisyUI variants, raw Tailwind colors that should be semantic tokens, layouts that break at narrow widths.
7. Flag the judgment calls separately - hierarchy choices, copy edits, component choices that work but might be wrong for the audience.
8. Re-check after edits so layout, interaction, and content still hold together.

Polish Lenses

• hierarchy: the important thing is obvious without oversized type in dense UI
• spacing: groups, controls, and repeated items have intentional rhythm
• content fit: long text, missing data, and many items do not break the page
• responsiveness: mobile and desktop feel designed, not merely squeezed
• interaction: hover, active, disabled, selected, empty, loading, and error states are present where expected
• DaisyUI consistency: same purpose uses the same variant everywhere; no raw Tailwind palette colors leaking through; theme tokens are the only color source
• spec adherence: the prototype actually shows what BRIEF.md said it would. The First Product Surface is the surface that loads; the Core Workflow steps are walkable; every Must-Show State is reachable; nothing important from the brief is silently missing and nothing major is present that the brief did not call for. Scope drift is as much a bug as a layout one
• answers the question: the prototype moves the named Question This Prototype Answers forward. A stakeholder looking at this surface should be able to act, compare, or decide on that specific question - not "form a general impression." If the prototype is technically faithful to the brief but the Question is no closer to being answered, flag it
• assumption talking points: every [assumed] / [unsure] brief claim should be discoverable in the data (_assumed: true) and listed back to the designer as a talking point for the share conversation. The prototype itself stays clean - the discussion is where uncertainty gets surfaced, not the surface
• accessibility: contrast, keyboard paths, labels, focus states, and hit targets are reasonable
• product clarity: the screen helps the user act, compare, decide, or understand

Defaults

• Fast Preset prototypes use Astro, Tailwind CSS, and DaisyUI.
• DaisyUI components are expected and should feel intentionally designed, not like a default theme preview.
• Prefer icons for tool buttons when the repo has an icon set (@lucide/astro).
• Do not add visible instructional text explaining obvious UI mechanics.
• Avoid decorative card piles, oversized hero treatments, and one-note palettes for operational tools.
• Keep text inside controls and containers at all supported widths.
• Use real or representative visual assets when the experience depends on them.

Output Standard

Lead with what was fixed (file/line references when possible), then what was flagged for the designer's judgment, then the assumption talking points - the list of [assumed] / [unsure] items the designer should mention verbally when sharing the prototype. When asked to only review without editing, drop the fixes section and list issues by severity.