Dry Run A Risky Change
Billing, plans, seats, permissions, access rules, auth, flag removals or data...
Install
npx skills add different-ai/openwork --skill dry-run-a-risky-change -g -a claude-code -y- Repository
- different-ai/openwork24.4k
- Category
- Design
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 1,768 tokens
- Runs scripts
- No, instructions only
What it does
Billing, plans, seats, permissions, access rules, auth, flag removals or data migrations that could lock real organizations out or change what they pay. Use before merging or deploying such a change to see exactly which production organizations it affects, prove the UI on production-shaped data, and only with explicit approval test against a PlanetScale copy of real data.
Dry-run a risky change
Tests prove the rule you wrote. They do not tell you which real organizations the rule changes. Before a risky change ships, answer three questions in order and stop at the first level that answers them:
- Who changes? Every production organization whose outcome differs before vs after (blocked, unblocked, billed differently, loses access).
- Does it look right to them? The real screens on organizations shaped like the affected ones.
- Does it behave right on real data? Only when 1 and 2 cannot answer it.
Confidentiality (AGENTS.md, hard rule): production names, ids, emails and counts stay in chat. Never put them in a branch, commit, fixture, screenshot, PR or issue. Describe affected organizations generically ("one grandfathered org with ~30 SSO users").
Level 1: read-only production dry run (always)
Run the new rule against production inputs without writing anything.
- Write the new rule's inputs as the smallest set of columns (plan metadata, member counts, subscription status, feature overrides). Express the rule either as SQL or by feeding query results into the PR's pure function.
- Read them with the platform admin MCP
den_query(read-only SQL against the Den database). Never use admin write tools (den_update_org_plan,den_set_org_capability,den_set_feature_rollout) during a dry run. - Compute before (current
devrule) and after (the PR) for every organization the rule can touch, and report only the ones that differ, plus anyone at or near a new limit. - Put the query (no results) in the PR as the pre-deploy check, and list the ops steps it implies (for example "give one org enough seats first").
den_query traps that produced wrong answers before:
