Data Faker is a skill that converts plain-English schema descriptions into realistic test datasets in JSON or CSV format. Instead of writing generation scripts or filling out online form tools, a developer describes the schema in a single sentence and receives structured output with up to 1,000 rows.

The skill applies semantic understanding to field names, automatically mapping over 30 recognized field patterns — including revenue, sku, ip_address, status, UUIDs, US-formatted addresses, prices, and ISO dates — to contextually appropriate generated values. This means a field named ‘ip_address’ receives a valid IP, not a random string.

Output is either a valid JSON array or an RFC 4180-compliant CSV file. Cross-record uniqueness is enforced to prevent primary key collisions, which matters when loading generated data into a database or test harness that expects unique identifiers. Custom enumeration values can be specified inline in the prompt using brackets or parentheses, and phone number formats are matched to specified countries. Numeric distributions are kept realistic rather than uniform-random.

Data Faker is the wrong choice when the required data must reflect production statistics or actual business distributions, when output must exceed 1,000 rows, or when integration with a live database schema via direct connection is needed. It operates purely from textual descriptions with no database connectivity.

Use cases

Generate a 500-row CSV of e-commerce orders with fields like order_id, sku, price, and status for integration test fixtures

Produce a JSON array of user records with UUIDs, US addresses, and phone numbers matched to a country for API mock data

Create seed data for a development database without writing a custom Faker script

Generate datasets with custom status enumerations by specifying allowed values inline in the prompt

Produce RFC 4180-compliant CSV files for import into spreadsheet tools or data pipeline tests

Quickly prototype a schema and validate field naming conventions before building a real data model

When to use it

When test fixtures are needed for a CI pipeline and writing generation scripts is impractical

When the schema can be described in plain English and field names follow recognizable patterns

When output must be free of primary key collisions across all generated rows

When both JSON and CSV output formats are acceptable targets

When not to use it

When more than 1,000 rows are required in a single generation run

When data must statistically mirror a real production dataset or actual business distributions

When the skill needs to connect directly to a database to read or write schema definitions

When the target system requires a format other than JSON array or RFC 4180 CSV

When no environment supports running a skill-type capability (requires a compatible skill runtime)