/profile-source — Source Profile interview

This skill runs a short, branching interview that converts an upstream source the data team does not own into a Source Profile markdown file at docs/sources-of-record/<system>-<entity>.md in the consumer's project. It is an interview, not a template — every profile that lands has been pressure-tested against the Generation kill-switch (a named consumer DGQ), the schema-authority honesty test, the streaming/batch neutrality rule, and the "is this actually an ADR moment?" routing test.

A Source Profile is not a statistical column-stats profile (cardinality, null rates, distributions). It is the operational and contractual model of the source — schema authority, delivery model, late-arrival behaviour, pager, replay window — deliberately human-authored and never inferred from a live connection. The Generation kill-switch is the one thing it must carry: an accepted profile names at least one consumer DGQ, or a source nobody consumes does not deserve a profile.

This skill is self-contained: the Source Profile contract it writes against ships beside it at references/source-profile.md, and the linter that enforces that contract ships at scripts/lint-source-profile.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 "Source Profile" and "Generation kill-switch") in CONTEXT.md and the lifecycle reference in docs/data-engineering-101.md.

Soul of the skill: the Generation kill-switch

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

Which Decision-Grade Question under docs/requirements/ is going to consume this source?

If the user cannot point to at least one accepted-or-draft DGQ in consumed_by, the source does not deserve a profile. A Source Profile with no named consumer is the structural twin of a DGQ with action_change: nothing — documentation for documentation's sake, the failure mode this stage exists to refuse. Surface that conclusion explicitly. Recommend the user do their exploratory poking informally — a scratch note, a Slack thread — and come back once a DGQ exists.

Do not soften the kill-switch. Do not paper over the absence by inventing a plausible-sounding consumer DGQ 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.