/plan-storage — Storage Plan interview

This skill runs a short, branching interview that converts a planned (or existing-but-undocumented) storage destination into a Storage Plan markdown file at docs/storage-plans/<dataset>.md in the consumer's project. It is an interview, not a template — every plan that lands has been pressure-tested against the Storage kill-switch (a named upstream Ingestion Plan), the storage-system-neutrality rule, the honest-deletion-mechanism test, the residency-inheritance test, the access-control-enforcement test, and the "is this actually an ADR moment?" routing test.

This skill is self-contained: the Storage Plan contract it writes against ships beside it at references/storage-plan.md, and the linter that enforces that contract ships at scripts/lint-storage-plan.sh. Read the contract for the frontmatter fields, enum domains, and body section order before running — do not duplicate that material into the interview; reference it.

Optional deeper reading — not required to run this skill (a per-skill install works without them): the full repo worldview (including the CONTEXT.md entries "Storage Plan" and "Storage kill-switch") in CONTEXT.md and the lifecycle reference in docs/data-engineering-101.md.

A Storage Plan is not an infrastructure-as-code template — not a Terraform module, not a DDL file, not a bucket-policy JSON. It is the operational and contractual model of the storage layer: the human-authored commitments (format, retention, residency, access, tiering, partitioning) that the actual infrastructure should reflect. The IaC that implements those commitments lives in the consumer's infrastructure repo and is out of scope — this skill emits no Terraform, no dbt config, no DDL. The plan is the contract the IaC should be reviewed against, not a substitute for it. It is the structural analogue of the Ingestion Plan one stage upstream, deliberately human-authored and never inferred from a cloud API (no BigQuery INFORMATION_SCHEMA scan, no Snowflake account-usage read, no S3 bucket listing).

Soul of the skill: the Storage kill-switch

The single load-bearing question this skill exists to force is:

Which Ingestion Plan(s) under docs/ingestion-plans/ does this storage destination receive data from?

If the user cannot point to at least one accepted-or-draft Ingestion Plan in related_ingestion_plans, the storage does not deserve a plan. A Storage Plan with no named upstream ingestion is the structural twin of an Ingestion Plan with no named upstream Source Profile, of a Source Profile with no consumer DGQ, and of a DGQ with action_change: nothing — documentation that floats free of the lineage graph, the failure mode this stage exists to refuse. Stage 3 is the stage where floating nodes are most economically damaging: orphan storage is orphan spend. Surface that conclusion explicitly. Recommend the user run /plan-ingestion first; come back to /plan-storage once the upstream ingestion path is planned.

Do not soften the kill-switch. Do not paper over the absence by inventing a plausible-sounding Ingestion Plan path on the user's behalf. The kill-switch (Turn 1) is the one place in this skill where the user must speak first; a recommendation there would coach them past the very gap the skill exists to surface.