agentsclimarketplace

Fast data

Skill tibichi/fast-preset/skills/fast-data

Prototyping skills for AI coding agents. Astro, Tailwind CSS, DaisyUI workflow for designers. Turns product docs into a working coded prototype.

Install
npx -y skills add tibichi/fast-preset --skill fast-data

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.md

5.3 KB, as published. Nobody here has run it

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?

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.