# Fast Review > Polish pass for an Astro/Tailwind/DaisyUI prototype before sharing - visual quality, responsive behavior, interaction states, DaisyUI consistency, and unresolved assumptions still showing in the UI. Use after a build session, before showing the prototype to stakeholders, or when something feels off. - Skill: `tibichi/fast-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add tibichi/fast-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/tibichi/fast-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: tibichi (https://skillmd.com/u/tibichi) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tibichi/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//`, `src/data//`); 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.