# Fast Data

> Create or refine JSON data models in src/data for Astro coded prototypes - content, fake data, UI states, workflow states, scenario fixtures, config. Reads BRIEF.md to honor assumption tags and scope. Use when the prototype's data layer needs shaping, not when adding a real database.

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