data

Review an OpenAPI 3.x contract (YAML or JSON) for consistency, versioning and client friendliness, after a bundled script lints it for missing operationIds, undeclared path parameters, responses without schemas or error cases, servers over http, missing security schemes, unused or dangling components and naming inconsistencies. Use when asked to "review this OpenAPI spec", when designing a REST API, before publishing a spec or generating clients, or when a client generator fails. Not for GraphQL or gRPC and not for implementing the API.

Profile a CSV or TSV file with a bundled script (column types, nulls, distinct counts, ranges and statistics, candidate keys, ragged and duplicate rows, mixed types, whitespace) and turn the profile into import decisions: column types for a table or schema, cleaning steps and validation rules. Use when asked to "summarise this CSV file", when handed a data file to load, analyse or validate, or when an import fails. Not for spreadsheets with formulas (export to CSV first) and not for files too large to read (use --sample).

Write a JSON Schema (draft 2020-12) for an API payload, configuration file or event by inferring a draft from sample documents with a bundled script (types, required fields, nullability, formats, enums, bounds) and then hand-finishing it: tighter constraints, descriptions, examples, additionalProperties and versioning. Use when asked to "write a JSON Schema", to validate JSON, document a payload, or create a schema from examples. Not for OpenAPI documents as a whole (use api-contract-review) and not for XML or protobuf.

Write and test regular expressions that match what they should and nothing else: a bundled script runs a pattern against labelled cases, shows each match and captured group, and warns on patterns that can backtrack catastrophically, with timing on adversarial inputs. Use when asked to write a regex (phone numbers, dates, log lines), "why does my pattern not match", to extract fields from text, or to check a regex used on user input. Not for parsing structured formats (JSON, HTML, URLs: use a parser) and not for full-text search.

Plan a database schema change as a sequence of backwards-compatible, reversible migration steps (expand, migrate data, contract) that work with the running application version, with lock and downtime analysis per step, a batched backfill for large tables, and a rollback plan. Use when asked "how do I rename this column safely?", when changing columns, tables, constraints or indexes on a live database, or reviewing a migration PR. Not for query tuning (use sql-query-review) and not for choosing a database.

Review SQL queries, ORM-generated SQL and query plans for correctness and performance: injection, implicit casts, NULL logic, non-sargable predicates, missing indexes, N+1 patterns, unbounded result sets, lock contention and transaction scope, using a fixed checklist and EXPLAIN reading notes for PostgreSQL, MySQL and SQLite. Use when asked "why is this query slow?", to review a query or migration, or to check ORM output. Not for schema design from scratch (use schema-migration-plan for changes) and not a replacement for a database profiler.