Fast Prototype

Fast Preset Prototype

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: soft. Works without it but loses the First Product Surface anchor and assumption tagging. If BRIEF.md is missing, ask whether to run fast-brief first; if the user says proceed anyway, do so and skip the _assumed rendering step.

Workflow

1. Read BRIEF.md. The Question This Prototype Answers is the spine - every build decision should make that question easier for a stakeholder to act on. The First Product Surface, Core Workflow, Must-Show States, and Assumptions are how the Question gets answered concretely.
2. Read existing Astro code and src/data JSON before deciding architecture.
3. If the repo is not an Astro project, run fast-astro before building.
4. Identify the data layer: JSON files in src/data, page content, component variants, UI states, or config.
5. Preserve designer editability. Keep data files legible, grouped by product meaning, and easy to edit without touching app logic.
6. Build the smallest working Astro prototype for the First Product Surface in BRIEF.md. Pages compose components; they do not define UI primitives.
7. Extract any UI piece into src/components/ as soon as it appears more than once, or whenever a block grows past ~15 lines of markup. For a single-page prototype, files sit flat at src/components/*.astro. For multi-page prototypes, page-specific components live in src/components/<page>/, and components used by two or more pages live in src/components/shared/ - promote to shared/ on the second use, not preemptively. Components receive their data as props that mirror the shape of the JSON record they render.
8. Build with DaisyUI semantic classes first. Customize via theme tokens (see references/daisyui-theme.md), not by sprinkling Tailwind overrides across components.
9. Include the Must-Show States from BRIEF.md: empty, loading, error, selected, disabled, long copy, missing media, and many items where the brief calls for them.
10. Run the Astro app when possible. Verify visually in the browser after meaningful frontend changes.
11. Keep a short note of the data files, pages, and components changed.

Records carrying _assumed: true should render exactly like verified records - same components, same styling, no visible tell. The flag exists so fast-review and the designer can find them later, not so stakeholders see warning badges during a demo.

DaisyUI Usage

DaisyUI is the structural and visual default. Reach for raw Tailwind only when DaisyUI has no equivalent.

Class hierarchy when styling an element:

1. A DaisyUI component class first (btn, card, alert, badge, menu, tabs, stat, navbar, hero, dropdown, etc.).
2. A DaisyUI semantic modifier (btn-primary, card-bordered, alert-success, badge-outline).
3. A DaisyUI size/state modifier (btn-sm, btn-disabled, card-compact).
4. Tailwind utilities only for layout (grid, flex, gap-*), spacing (p-*, m-*), and sizing (w-*, max-w-*, min-h-*).

Color rule: never use raw Tailwind palette colors (bg-blue-500, text-red-600). All color goes through DaisyUI semantic tokens. This is the lever that lets a single theme swap re-skin the whole prototype.

Consistency rule: the same purpose gets the same variant everywhere. Every primary CTA is btn-primary. Every success notice is alert-success. Every card uses the same base recipe unless there is a deliberate reason to diverge.

Customization rule: when the prototype needs a custom look, change theme tokens in src/styles/global.css using the syntax in references/daisyui-theme.md. Do not restyle DaisyUI components with Tailwind overrides - extend layout and spacing only.

Defaults

• Treat JSON as a data/database substitute, not a one-off prompt input.
• For new prototypes from scratch, use latest stable Astro, Tailwind CSS, and DaisyUI.
• Use the repo's existing stack when one is already established.
• DaisyUI is mandatory. Components first, theme tokens second, custom utilities last.
• Componentize from screen one. Pages live in src/pages/, primitives live in src/components/. Component props mirror the JSON shape they render.
• When docs describe an entire system, prototype one decision-critical product surface first - whatever BRIEF.md names as First Product Surface.
• Use structured parsing and imports over string manipulation for data.
• Do not add backend, auth, database, analytics, or deployment unless the prototype needs it now.
• Favor fast iteration over reusable abstractions until duplication becomes painful - but extract reusable UI immediately; that is layout consistency, not premature abstraction.
• Prefer a real usable first screen over a marketing landing page.
• No single-file HTML/CSS/JS prototypes unless the user explicitly asks for a throwaway file.

Output Standard

The result should feel like a designer can keep working in the repo:

• clear files for data edits in src/data
• one concept per src/components/*.astro file
• predictable component/data mapping (props mirror JSON shape)
• DaisyUI semantic classes and theme tokens only - no raw Tailwind palette colors
• responsive layout that survives realistic content
• browser-verified behavior using the Astro dev server when available
• no heavy process notes unless the user asks for them