# Fast Prototype

> Build or iterate an Astro/Tailwind/DaisyUI coded prototype where JSON files in src/data are the editable data layer. Reads BRIEF.md to drive scope; _assumed records are tracked but render exactly like verified records (no visible tells). Use when the user wants a working prototype rather than a plan or spec.

- Skill: `tibichi/fast-prototype` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tibichi/fast-prototype`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tibichi/fast-prototype/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-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