Fast Data

Fast Preset Data

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 is flying blind on entities, scope, and assumption tags. If BRIEF.md is missing, ask whether to run fast-brief first; if the user says proceed anyway, do so and skip the _assumed tagging step.

Workflow

1. Read BRIEF.md. Note the Data Files list, Key Entities, Must-Show States, and every [assumed] / [unsure] claim - those will become _assumed: true on the records they produce.
2. Inspect existing Astro pages, components, and JSON before proposing changes.
3. Place JSON files per page. If the prototype has one page, files sit flat at src/data/*.json. If it has multiple pages, each page gets a folder (src/data/<page>/) and anything used by two or more pages moves to src/data/shared/. Promote to shared/ on the second use, not preemptively.
4. Model data around product concepts the designer understands, not premature database tables.
5. Use IDs and references when the prototype represents workflows, approvals, people, accounts, events, content items, or relationships.
6. Separate stable content from volatile UI state when that makes editing clearer.
7. Stress the layout from inside the data. Include short, normal, long, missing, repeated, and unusual values so the prototype meets realistic content from the first render. When the product has meaningful states or workflows, ship the dataset with multiple scenarios (happy path, missing input, blocked, stale, completed) rather than one happy-path fixture.
8. Carry assumption tags forward. Any record derived from a [assumed] or [unsure] claim in BRIEF.md gets _assumed: true and, where useful, _source: "brief §<section>". Do not strip these out to make the data look tidy.
9. Keep object names and file names readable. Prefer cards.json, plans.json, timeline.json, or states.json over vague buckets.
10. Update consuming Astro code when changing shapes so the prototype still runs.
11. Add lightweight schema hints only when the repo already uses them or when the JSON shape is non-obvious.

Astro Data Heuristics

• Prefer JSON structures that import cleanly into .astro pages, layouts, and components.
• Keep data files under src/data, not root-level content/, data/, or separate prototype folders. Subfolders under src/data are page-scoped or shared/ only - no category buckets (no forms/, no widgets/).
• Use arrays for repeated UI collections.
• Use IDs only when components need stable selection, links, filtering, or relationships.
• Keep display copy close to the thing that renders it.
• Keep image/media fields explicit: src, alt, caption, credit when useful.
• Represent UI states deliberately: empty, loading, error, featured, disabled, selected, locked.
• Represent workflow states deliberately: queued, inProgress, needsApproval, approved, blocked, failed, complete.
• Avoid nesting so deeply that a designer cannot edit data confidently.

Review Checklist

• Can a designer change copy or records inside src/data without opening component code?
• Can data be added, removed, or reordered safely?
• Are edge cases represented?
• Does the naming match the product language in BRIEF.md and the docs?
• Do records derived from [assumed] / [unsure] brief items carry _assumed: true?
• Did any Astro imports, paths, or assumptions break after the model changed?