setup-relentless-data-skills

/setup-relentless-data-skills — scaffold a consumer project for the data lifecycle

This skill prepares a consumer project (not this upstream repo) to use the data-lifecycle skills: it writes a thin ## Data skills index block into the project's CLAUDE.md/AGENTS.md and creates the docs/<stage-area>/ directories where each stage's artefact will land. It is a setup ritual the user runs once — a sibling to the advisor (meta) skills under skills/meta/ (ADR-0002): it has no lifecycle position, writes no durable lifecycle artefact, and has no linter, so it lives outside the numbered 00-…05- spine. It is prompt-driven, not a script — explore, present what you found, confirm with the user, then write.

This skill is self-contained: the vocabulary it leans on is inlined just below, and it ships with no references/ contract and no scripts/ linter — there is nothing to read or run beside it. It writes into the consumer's repo at runtime, which is the point.

Vocabulary this skill assumes (the minimum it needs; the full worldview is optional deeper reading, linked at the end):

Lifecycle spine. The ordered chain of stages each skill serves: Requirements (Stage 0) → Generation (1) → Ingestion (2) → Storage (3) → Transformation (4) → Serving (5), closing back to Requirements. Each stage produces one durable, version-controlled markdown artefact under a stable docs/<stage-area>/ directory.
Stage-area directory. The plural-noun directory a stage's artefacts live in, in the consumer project: docs/requirements/, docs/adr/, docs/sources-of-record/, docs/ingestion-plans/, docs/storage-plans/, docs/model-plans/, docs/serving-surfaces/ (ADR-0001). This skill creates them; the stage skills fill them.
Kill-switch. The named condition under which a stage refuses to produce its artefact — no consumer DGQ → no Source Profile; no upstream Source Profile → no Ingestion Plan; and so on down the chain. The ## Data skills block this skill writes names each one, so the consumer internalises the chain rather than treating the skills as form-fillers.

Optional deeper reading — not required to run this skill: the full repo worldview in CONTEXT.md and the lifecycle reference in docs/data-engineering-101.md.

What this skill is — and is not

It is a one-time, idempotent scaffolding pass. It explores, confirms three decisions, then writes an index block and creates directories. Re-running it updates the block in place and adds any newly-chosen stage dirs — it never duplicates the block and never overwrites an existing directory or its contents.
It authors no lifecycle artefact and has no linter. Like the advisor skills under skills/meta/, it is exempt from ADR-0001's one-skill/one-artefact/one-lint pattern. The durable, lint-gated artefacts are produced downstream by the stage skills it scaffolds for.
It stays in its lane. It configures only the data-lifecycle skills. If the project also uses the engineering skills (to-issues, triage, to-prd, …), their setup is a separate concern — leave any ## Agent skills block from /setup-matt-pocock-skills untouched; the two blocks coexist.

Soul of the skill: scaffold only what will hold content

The repo's load-bearing opinion is decisions, not templates — refuse to build an artefact for a decision nobody will act on. The setup analogue is the soul of this skill:

Scaffold only the stage directories the project will actually populate. An empty docs/<stage-area>/ that never receives an artefact is the same dead weight the lifecycle refuses upstream — do not litter the consumer with folders nobody will fill.

So this skill does not blindly mkdir all seven directories. It asks which stages are in play (Decision B below) and scaffolds only those — and it teaches the chain in the block it writes, so a consumer who skips Stage 1 understands they cannot honestly accept a Stage 2 Ingestion Plan later. Refuse, explicitly, to create the full set "just in case."

Process

1. Explore

Read the consumer repo's starting state; don't assume:

git remote -v — is there a remote, and where (GitHub / GitLab / none)?
CLAUDE.md and AGENTS.md at the repo root — does either exist? Is there already a ## Data skills section? A ## Agent skills section (leave it alone)?
CONTEXT.md and CONTEXT-MAP.md at the root — single-context or multi-context layout?
docs/ — which docs/<stage-area>/ directories already exist? (docs/adr/ is often already present.)

2. Present findings and ask — one decision at a time

Summarise what's present and missing. Then walk the user through three decisions one at a time — present, get the answer, move on. Assume the user may not know the lifecycle; each decision opens with a one-line explainer.

Decision A — Which file gets the index block.

The ## Data skills block is a short pointer the stage skills (and you) read to know where each artefact lands and which /verb writes it.

If CLAUDE.md exists, propose it. Else if AGENTS.md exists, propose it. If neither exists, ask which to create — don't pick for them. Never create AGENTS.md when CLAUDE.md exists, or vice versa.

Decision B — Which lifecycle stages this project uses (this is the soul — do not skip it).

The lifecycle runs Requirements → Generation → Ingestion → Storage → Transformation → Serving, each chaining back to the one before. A project that only models data already in a warehouse may skip Generation/Ingestion; a raw-ingestion project may skip Transformation/Serving.

Present the seven stage-areas with their one-line jobs and let the user pick which are in play. Default is all, but make them choose honestly — name the kill-switch chain so they see that scaffolding Stage 3 without Stage 2 leaves a dir that can never hold a passing artefact. Scaffold only the chosen stages' directories.

Decision C — Output layout.

Where the docs/<stage-area>/ directories live.

Single-context — docs/<stage-area>/ at the repo root. Most projects (ADR-0001).
Multi-context — a CONTEXT-MAP.md at the root points to per-context roots, each with its own docs/ subtree (typically a monorepo). If CONTEXT-MAP.md exists, scaffold per context root and label the index block accordingly.

3. Confirm the draft

Show the user, and let them edit before writing:

the ## Data skills block (only rows for the stages chosen in Decision B);
the list of directories to create, each with the one-line seed README.md it will carry.

4. Write

Pick the file per Decision A's rule. If a ## Data skills block already exists, update it in place — never append a duplicate, never disturb the surrounding sections or a sibling ## Agent skills block.

Insert the block (rows only for chosen stages):

## Data skills

Data-lifecycle skills that interrogate each artefact before any pipeline is written, and refuse to produce a downstream artefact that does not chain back to its upstream one. Order: DGQ → Source Profile → Ingestion Plan → Storage Plan → Model Plan → Serving Surface → (back to a DGQ).

| Stage | Skill | Writes to | Kill-switch |
| --- | --- | --- | --- |
| 0 · Requirements | `/gather-requirements` | `docs/requirements/` | if nothing changes when the answer flips, the ask is rejected — not built |
| 0 · Decisions | `/write-adr` | `docs/adr/` | refuses single-option decisions |
| 1 · Generation | `/profile-source` | `docs/sources-of-record/` | no consumer DGQ → no profile |
| 2 · Ingestion | `/plan-ingestion` | `docs/ingestion-plans/` | no upstream Source Profile → no plan |
| 3 · Storage | `/plan-storage` | `docs/storage-plans/` | no upstream Ingestion Plan → no plan |
| 4 · Transformation | `/model-data` | `docs/model-plans/` | no upstream Storage Plan → no model |
| 5 · Serving | `/serve-data` | `docs/serving-surfaces/` | needs BOTH an upstream Model Plan AND a DGQ it informs |

Cross-cutting: `/triage-lineage` reads the whole graph and tells you where to start; it writes nothing.

Worldview: <https://github.com/sleeplessv/relentless-data-skills/blob/main/CONTEXT.md> · Lifecycle reference: <https://github.com/sleeplessv/relentless-data-skills/blob/main/docs/data-engineering-101.md>

Create each chosen directory with a one-line seed README.md so it survives in git and signposts itself — e.g. for docs/sources-of-record/:

# Source Profiles — Per-source Source Profile artefacts (<system>-<entity>.md) written by /profile-source. Kill-switch: an accepted profile must name at least one consumer DGQ — no consumer, no profile.

Skip any directory that already exists; do not touch its contents.

5. Done

Tell the user setup is complete: which /verb writes into each scaffolded directory, the order to use them in, and that /triage-lineage will tell them where to start once artefacts exist. Mention they can re-run this skill to add stages later, and point them at the worldview and lifecycle reference (absolute URLs above) for the full picture.