/fabricate

Fill a target repo's database with data that behaves like the real thing: deterministic (the same seed always rebuilds the same dataset), realistic (valid foreign keys, believable distributions, consistent columns), and synthetic (every row is generated — the synthetic-only rule — no real personal data enters any repo, script, or database).

The deliverable is not the data itself. It is a seed script committed inside the target repo, written once and re-run by anyone from any checkout. You write or update that script; the script does the generating.

Ground rules

• Synthetic-only. Names, emails, phones, and every other value come from generated pools and a seeded PRNG. Email domains stay on reserved example domains. Never read, copy, mask, or "sample" production data — anonymization of real data is out of scope by design.
• Stack-agnostic. The script is written in the repo's own language, placed where that stack keeps database code (scripts/, db/, tools/ — whatever fits). React, Prisma, and Postgres appear in this skill as examples only; the repo's own ORM models, migrations, or SQL files are the truth.
• Config comes from docs/agentic-skills/data.md — profiles, volumes, locale blend, default seed, marker convention. If it is missing, run /agentic-skills-init first. If the repo has no database at all, agree with the user what to introduce (or whether to skip) before inventing one, and record the outcome in docs/agentic-skills/stack.md.
• Production-looking databases are refused (non-localhost hosts, production-like names, unexplained row counts). The guard's full rules live in docs/agentic-skills/data.md and ADR 0005; never weaken or bypass them, and never seed a database you are not certain is a development one.

The seed script pattern

• Seeded PRNG, never the platform's global random. Hash the run's seed into a PRNG (any small deterministic algorithm — the point is reproducibility, not cryptography). Give each table its own stream keyed by (seed, table name) so changing one table's volume never shifts another table's data.
• Pinned clock. Dates and times derive from a constant as-of timestamp in the script (overridable by flag), never from the wall clock. Identical seed, identical dates.
• Deterministic ID rule. Integer primary keys are assigned sequentially from 1 per table, in the fixed order the PRNG stream generates the rows. Use hash-derived opaque IDs only where the schema demands them. State the rule in one sentence — it goes into the manifest.