{
  "schema_version": 2,
  "kind": "shortening-method",
  "format": "agent-skill",
  "id": "schema-change",
  "name": "Schema change",
  "category": "Technical",
  "summary": "Reduce a data-model change note to compatibility, sequencing, and checks.",
  "use_cases": [
    "Database migration reviews",
    "Data contract changes"
  ],
  "word_count": 148,
  "url": "https://sho.rten.it/methods/schema-change/",
  "instructions_url": "https://sho.rten.it/methods/schema-change/SKILL.md",
  "skill_url": "https://sho.rten.it/methods/schema-change/SKILL.md",
  "json_url": "https://sho.rten.it/methods/schema-change/llms.txt",
  "plain_text_url": "https://sho.rten.it/methods/schema-change/prompt.txt",
  "license": "MIT",
  "sources_url": "https://sho.rten.it/sources/#schema-change",
  "skill_name": "schema-change",
  "skill_description": "Reduce a data-model change note to compatibility, sequencing, and checks. Use for Database migration reviews, Data contract changes.",
  "agents_md_url": "https://sho.rten.it/methods/schema-change/AGENTS.md",
  "sources": [],
  "instructions": "Condense supplied documentation for a database or data-schema change. Focus on the contract between stored data, readers, and writers, rather than general application release notes.\n\nState the before-and-after shape using exact table, field, type, and constraint names. Preserve nullability, defaults, key behavior, backfill scope, and compatibility with old readers or writers. Keep rollout order, lock or downtime risks, and irreversible operations when supplied. Distinguish a planned constraint from one already enforced.\n\nRemove repeated SQL narration and unrelated feature background. Keep validation evidence and remaining checks separate. Retain rollback limits, especially when data is deleted or transformed. Do not invent a safe migration sequence or infer that an additive change is automatically harmless.\n\nOutput Change, Rollout, and Verification, with Risks or Rollback when supported. Copy supplied SQL exactly if included. Do not execute the migration, claim production data was checked, or replace an unresolved compatibility question with an assurance.",
  "example": {
    "context": "Order currency migration",
    "before": "We propose adding orders.currency as a nullable CHAR(3) column with no default. Existing rows will be backfilled with USD, but only after the data team confirms that all historical orders were charged in USD; that confirmation is still pending. Deploy writers that always supply currency before making the column NOT NULL. Old readers ignore the new column and remain compatible. The backfill should run in batches of 1,000 rows. Before adding NOT NULL, verify that no null values remain. No production lock-time test has been run. Rollback can leave the nullable column in place; dropping it would discard currency values written since rollout.",
    "after": "Change: Proposed orders.currency, nullable CHAR(3), no default. Old readers remain compatible.\nRollout: Confirm all historical orders used USD (pending); backfill USD in 1,000-row batches. Deploy writers that supply currency before NOT NULL.\nVerification: Check for zero nulls before NOT NULL. Production lock time untested.\nRollback: The nullable column can remain. Dropping it loses currency values written since rollout.",
    "must_preserve": [
      "Proposed orders.currency nullable CHAR(3), no default",
      "Historical USD confirmation pending and required before backfill",
      "Backfill USD in batches of 1,000",
      "New writers must supply currency before NOT NULL",
      "Old readers compatible; verify no nulls before NOT NULL",
      "Production lock-time test not run",
      "Rollback can retain nullable column; drop loses postrollout values"
    ],
    "kind": "illustrative",
    "omitted": [
      "First-person proposal framing and repeated descriptions of the column."
    ]
  }
}