Prepare a Production Data Change
English | 中文
Create a review-ready description of a proposed production data change. Describe what changes, why it changes, how it is implemented, how it reaches production safely, and what evidence supports the change.
Use change request as the default term throughout the output. Do not assume a hosting, review, deployment, orchestration, or ticketing platform. If the user explicitly requests another label or an organization-specific format, use that label consistently without changing the required content.
Inputs
Collect the following facts or mark them as unknown:
- Change purpose, owner, scope, and intended outcome.
- Affected datasets, fields, types, nullability, defaults, keys, partitions, and grain.
- Implementation details, including transformation logic and configuration changes.
- Upstream producers and downstream consumers, with rollout ordering.
- Schema compatibility for existing readers, writers, historical partitions, and mixed-version operation.
- Release sequence, feature gating, migration steps, and any historical backfill or aggregate recomputation.
- Validation evidence from representative data, including invariant and reconciliation results.
- Risks, monitoring signals, stop conditions, rollback trigger, and rollback procedure.
Do not invent evidence, lineage, compatibility guarantees, backfill scope, or rollback capability. Ask focused questions when missing facts materially affect safety; otherwise label them as unresolved gates.
Workflow
- Establish the current and proposed dataset contract.
- Identify changes to fields, keys, partitions, and row grain.
- Trace upstream production and downstream consumption of every changed contract.
- Explain the implementation at the level needed to review correctness.
- Classify schema compatibility for old data, new data, and mixed-version readers and writers.
- Define the release and backfill sequence, including compatibility gates between stages.
- Summarize validation evidence with exact scope, expected result, observed result, and tolerance.
- State risks, monitoring, objective stop conditions, and a tested rollback path.
- Remove empty boilerplate only when the user requests a shorter format; never omit a material risk or unresolved gate.
Use references/change-template.md as the default structure. Use references/example.md as a fictional worked example.
Output Rules
- Lead with the outcome and reason, then provide reviewable implementation and operational detail.
- Use dataset and field names precisely. State the grain as “one row per …” and name the expected key.
- Distinguish adding a nullable field from changing grouping grain or key semantics.
- Explain historical values explicitly. A new field being
NULLin old partitions is a compatibility decision, not self-explanatory behavior. - Name every aggregate or consumer that requires recomputation, migration, staged rollout, or compatibility verification.
- Report validation as evidence, not intent. Planned checks belong in release gates; completed checks include observed results.
- For conserved measures, compare old and new outputs at the original grain and state the accepted tolerance.
- Keep platform links and execution commands out unless the user provides them and asks to include them.
Related Skills
- Detailed bounded historical rerun plan:
plan-safe-backfill. - Implementation or pipeline diff review:
review-data-pipeline. - Data-quality root-cause investigation:
investigate-data-quality. - YARN runtime failure evidence:
debug-spark-yarn.
Safety
This Skill writes documentation only. It does not approve, merge, deploy, alter schemas, publish data, run jobs, or start backfills. Never present planned validation as completed evidence. Do not expose credentials, private infrastructure, sensitive records, or proprietary identifiers. Mark irreversible schema or data operations, missing rollback capability, unresolved downstream compatibility, and unbounded backfills as blocking risks requiring explicit owner approval before execution.
