add-resource-command

Authoritative contract for adding a resource end-to-end. The work spans four layers — domain schema, commands, unit tests, e2e suite — plus a mandatory close-out (/review then /simplify) before the task is done. The order matters: earlier layers feed types into later ones, and deviating from house style at any step produces drift the type-checker can't catch.

This skill subsumes what was previously called "add-domain-resource." Adding a domain file alone is no longer the unit of work — a resource without a command isn't useful, and a command without an e2e test isn't trustworthy.

Step 0 — Pre-flight (mandatory)

Anchor to the existing house style. Skip this and you will produce drift the type-checker won't catch.

1. ls src/domain/ and read one existing resource file end-to-end (e.g. src/domain/user.ts).
2. Read src/domain/view.ts (the ColumnDef<T> / ResourceView<T> contract).
3. Read one existing list command and one existing get command (look under src/commands/<noun>/). Note how <Resource>ListEnvelope, outputSchema, parseId, renderList, renderItem, and defineMetabaseCommand compose.
4. Read one existing e2e test (tests/e2e/<noun>.e2e.test.ts) and the harness (tests/e2e/run-cli.ts, tests/e2e/bootstrap-data.ts). The add-e2e-test skill's runtime contract is binding here — re-read it before writing the e2e file.
5. Read src/output/types.ts to confirm listEnvelopeSchema and the ListEnvelope<T> interface.

What you must produce

For a typical list/get pair on a new resource: