# Dry Run A Risky Change

Billing, plans, seats, permissions, access rules, auth, flag removals or data...

- Repository: https://github.com/different-ai/openwork (24362 stars)
- Category: Design
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add different-ai/openwork --skill dry-run-a-risky-change -g -a claude-code -y`
Codex: `npx skills add different-ai/openwork --skill dry-run-a-risky-change -g -a codex -y`
Cursor: `npx skills add different-ai/openwork --skill dry-run-a-risky-change -g -a cursor -y`
Gemini CLI: `npx skills add different-ai/openwork --skill dry-run-a-risky-change -g -a gemini-cli -y`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as 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:

1. **Who changes?** Every production organization whose outcome differs
   before vs after (blocked, unblocked, billed differently, loses access).
2. **Does it look right to them?** The real screens on organizations shaped
   like the affected ones.
3. **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.

1. 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.
2. 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.
3. Compute **before** (current `dev` rule) 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.
4. 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:

The rest: https://github.com/different-ai/openwork/blob/HEAD/.opencode/skills/dry-run-a-risky-change/SKILL.md