Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.
RBA RBA Skills

test-data-generator

Standalone Web-only skill. Copy it into Claude, or drop it into your project.
Open Claude.ai

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

Test Data Generator

Generate realistic, schema-valid synthetic data to seed CMS environments, relational databases, or test fixtures. Every record uses plausible-but-fictional values, covers edge cases the QA team needs, and contains no real PII.

Usage

/test-data-generator <SchemaOrTableDescription> [options]

Options

Flag Values Default
--format csv | json | sql | sitecore-yaml | umbraco-json json
--rows integer 1–500 20
--locale comma-separated BCP-47 tags en-GB
--platform sitecore | umbraco | optimizely | agnostic agnostic
--edge-cases flag included by default
--no-edge-cases flag omit edge-case rows

Quick examples

/test-data-generator ArticlePage --platform sitecore --rows 30 --locale en-GB,fr-FR
/test-data-generator "products table: id,name,price,category,sku" --format sql --rows 50
/test-data-generator BlogPost --format json --rows 25 --locale en-US,de-DE,ja-JP
/test-data-generator "Customer: firstName,lastName,email,phone,address,dateOfBirth" --format csv --rows 100

Phase 1 — Understand the schema

Before generating a single row, read the project to understand the exact shape of the schema.

1a — If a platform is specified

Read existing schema files using these discovery rules:

Sitecore — Glob for *.items.yaml, *.master, or serialised template JSON under src/ or items/. Parse field names, field types (Single-Line Text, Rich Text, Date, Droplink, Number, Checkbox, Image, etc.), and Required flags.

Umbraco — Glob for *.uSync, *.json under uSync/ or umbraco/Data/, or Orval-generated TypeScript types under src/. Parse property aliases, Data Types, and Mandatory flags.

Optimizely — Glob for *.cs files with [ContentType] attribute. Parse property names, [Required] attributes, and [Display] labels.

Agnostic / database — accept a schema as free text, a CREATE TABLE DDL block, a TypeScript interface, a JSON Schema object, or a Zod schema. Parse column/field names, types, constraints, and foreign-key hints.

1b — If no platform file is found

Ask the user to supply one of:

  • A CREATE TABLE DDL snippet
  • A TypeScript interface or Zod schema
  • A plain-text field list (name: type, description, constraints)
  • A JSON/CSV header row

Do not proceed to generation until the schema is resolved.

1c — Schema summary

After discovery, print a brief Schema snapshot table before generating data:

Field / Column Resolved Type Required Localised Notes

List every field. Flag ambiguities (e.g. "email column has no constraint — assuming unique, valid format"). If the user confirms, proceed to Phase 2.

Phase 2 — Plan the data set

Before writing rows, plan what to include. A good data set covers four categories:

Category Proportion of rows Purpose
Happy-path baseline ~60 % Realistic, typical records that represent the 80th-percentile use case
Edge cases ~20 % Values that stress field boundaries and UI rendering (see reference.md § Edge-case catalogue)
Locale variants Per locale requested Same content in each requested locale, matched by a shared seed_id
Relationship anchors As needed Root records other rows reference (categories, authors, tags)

Announce the plan in one sentence: e.g. "Generating 30 rows: 18 baseline, 6 edge-case, 6 fr-FR locale variants."

If --no-edge-cases is set, replace edge-case rows with additional baseline rows.

Phase 3 — Generate data

PII rules — non-negotiable

  • No real personal data. All names, emails, phone numbers, and addresses must be demonstrably fictional. Use the fictional-data pools in reference.md § Synthetic pools.
  • Email pattern: <first>.<last><N>@example.com or test+<slug>@rbademo.invalid. Never use a real TLD that could resolve.
  • Phone pattern: +44 7700 9XXXXX (Ofcom reserved), +1 555-0XXX (NANP fictional range). Never generate a real subscriber number.
  • Names: use the pools in reference.md § Name pools — diverse, multi-cultural, clearly fictional.
  • Addresses: fictional street numbers + street names from the pools; real city names are fine (London, Paris, Berlin), fictional postcodes/zip codes only.
  • Dates of birth / ages: never generate a real individual's birth date. Use ranges: adults 18–80 years old, randomly distributed.
  • Financial data: amounts in plausible retail ranges ($0.99–$999.99); no real card numbers, IBANs, or account numbers — use the placeholder patterns in reference.md.

Value quality rules

  • Text fields: use realistic domain language. A heroHeadline for a financial services site should read like a real headline, not "Lorem ipsum" or "Test headline 1". Infer domain from the schema name or a --domain hint. Fallback domain: general professional services.
  • Rich text fields: generate 2–4 paragraphs of coherent, domain-appropriate prose. No lorem ipsum. Wrap in <p> tags when the format is HTML-bearing.
  • Slugs / aliases: derived from the title/name field; lowercase, hyphens, no special chars.
  • Dates: use realistic past dates (articles published in the last 2 years); future dates only for expiryDate, scheduledDate, or fields whose name implies futurity.
  • Numbers / prices: plausible range for the domain. Document the assumed range in a comment.
  • Enums / droplinks: cycle through the full set of allowed values across the dataset so every option is exercised at least once.
  • Booleans: distribute roughly 70 % true / 30 % false unless domain logic suggests otherwise.
  • Images: use placeholder URL pattern https://placehold.co/<W>x<H> with realistic dimensions. Never use a real CDN URL that could break. See reference.md § Image placeholders.
  • GUIDs / IDs: generate valid UUID v4 values (format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx). Never reuse IDs across rows.
  • Foreign keys / references: if the schema has a FK column, generate the anchor records first (Phase 2) and reference their IDs consistently.

Edge-case inclusions

Unless --no-edge-cases is set, include at least one row for each applicable edge case from reference.md § Edge-case catalogue. Mark each with a _seed_note comment or column so QA engineers know why the row exists.

Common required edge cases:

Edge case Example
Maximum field length Title at 255 chars, slug at 200 chars
Minimum content Required fields only, all optional fields null/empty
Special characters in text Apostrophes, ampersands, < > " in a headline
HTML-injection probe <script>alert(1)</script> in a rich text field (escaped)
Unicode / non-Latin script Arabic, Chinese, or Cyrillic in a text field
RTL content Arabic or Hebrew locale row
Zero price / free tier Price = 0.00
Boundary dates Publish date = today, expiry date = yesterday (expired content)
Very long slug 200-char slug to test URL truncation
Null optional reference FK column null where nullable

Phase 4 — Emit output

Emit the data in the requested format. Use the format templates in templates.md.

JSON (default)

Emit a top-level array of objects. Use camelCase keys matching the schema aliases. Wrap in a { "items": [...] } envelope when the schema has a known entity name.

CSV

First row is the header; subsequent rows are data. Quote all string values. Use \n line endings. Emit a companion _README row or a commented header block explaining any _seed_note column.

SQL inserts

Emit INSERT INTO <table> (<cols>) VALUES ...; statements, one per row. Precede with a -- Generated by test-data-generator comment block with the generation date, row count, and schema source. Use parameterised-style literals (properly escaped strings, no raw interpolation).

Sitecore YAML (--format sitecore-yaml)

Emit serialised items in Sitecore Serialization / SCS format. See templates.md § Sitecore YAML for the canonical structure. Each item gets a deterministic GUID derived from its seed index (not truly random — predictable for source control).

Umbraco JSON (--format umbraco-json)

Emit uSync-compatible JSON objects with contentTypeAlias, name, values[] blocks. See templates.md § Umbraco JSON for the canonical structure.

Phase 5 — Locale variants

For each locale in --locale:

  • Translate / localise string/text fields using appropriate language and cultural conventions.
  • Keep non-localised fields (IDs, slugs, booleans, numbers, dates) identical or clearly linked via a shared seed_id column.
  • Adjust phone formats and address formats for the locale (see reference.md § Locale data).
  • For RTL locales (Arabic ar-*, Hebrew he-*): note RTL requirement in a _seed_note.
  • Emit locale variants as a separate named block or file segment, clearly labelled.

Phase 6 — Post-generation checklist

Before presenting output, verify:

  • No real PII present — run a mental scan for real names, real email domains, real phone numbers, real addresses.
  • Every required field has a non-null value.
  • Every enum/reference field uses only values from the allowed set.
  • At least one edge-case row is present (unless --no-edge-cases).
  • All IDs are unique within the dataset.
  • Foreign-key references resolve to an anchor row in the same dataset.
  • Output syntax is valid for the requested format (JSON parses, SQL is syntactically correct, CSV has consistent column counts).
  • Locale variants share a seed_id with their source row.

Output structure

Present in this order:

  1. Schema snapshot (Phase 1c) — confirm what was parsed.
  2. Generation plan (Phase 2) — one-sentence summary of the dataset plan.
  3. Data output — the generated rows in the requested format.
  4. Edge-case index — table listing which edge cases are included and in which row.
  5. Usage notes — any import commands, environment variables, or manual steps needed to load the data into the target system (see reference.md § Import commands).

Hard rules

  • Never generate real PII. If the schema's field names suggest real personal data, generate fictional equivalents using the patterns above. Do not soften this rule even if asked.
  • Never use lorem ipsum. Generate domain-appropriate prose for every text field.
  • Never reuse UUIDs across rows in the same dataset.
  • Never write outside the project's seed/fixture directory without asking. Infer the correct path from the project structure (see Phase 1); if ambiguous, ask before writing.
  • Respect the row limit — --rows caps at 500 to avoid token-limit issues. For larger sets, offer to split into multiple files.
  • Always include at least one edge-case row unless --no-edge-cases is explicitly set.

Reference files

  • reference.md — synthetic data pools (names, addresses, phone patterns, image placeholders), edge-case catalogue, locale data, import commands per platform, field-type value rules.
  • templates.md — format templates: JSON envelope, CSV header pattern, SQL INSERT block, Sitecore YAML item, Umbraco uSync JSON.
  • examples.md — worked examples: ArticlePage seed (Sitecore, en-GB + fr-FR), products table (SQL, 20 rows), BlogPost fixtures (JSON, with edge cases annotated).
Technical details
Source
Standalone skill
Author
Dakota Smith
Skill name
test-data-generator
Maturity
experimental
Security review
No security review
Argument hint
<SchemaOrTableDescription> [--format csv|json|sql] [--rows N] [--locale en-GB,fr-FR,...] [--platform sitecore|umbraco|optimizely|agnostic] [--edge-cases]
Allowed tools
  • Read
  • Write
  • Edit
  • Glob
File
skills/test-data-generator/SKILL.md

To use this skill in Claude Code, copy SKILL.md into your local .claude/skills/test-data-generator/ directory. Standalone skills are not exposed via claude plugin install — that path is reserved for plugin bundles.

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.