SkillsAdd

thaildhe172591/pythia

pythia-impact

Use before proposing or writing any change to an Oracle object - a procedure, package, function, trigger, view, or table. Impact analysis comes first, because what depends on an object decides how careful the change must be, and Oracle invalidates dependents in cascade.

Installation

$ npx skills add thaildhe172591/pythia --skill pythia-impact
View on skills.sh ↗ GitHub repository ↗

Also in this package

Other skills from thaildhe172591/pythia · top by installs.

npx skills add thaildhe172591/pythia
pythia-setup 61 pythia-explore 52 pythia-apply 50 pythia-review 49 pythia-write 49 pythia-skill-author 48 pythia-conventions 27 pythia-spec 23 using-pythia 23 plsql-skill-author 3

Browse all from thaildhe172591/pythia

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 3
License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,588 B
  • docs SUMMARY.md 291 B

History

  1. First recorded snapshot · 48 installs

SKILL.md

Impact Before Change

Announce at start: "Using pythia-impact to measure the blast radius first."

Phase: Learn — and the first Ask gate: a large blast radius reaches the developer before any code is written

Changing an Oracle object recompiles or invalidates everything that depends on it — immediately, schema-wide, for every user of a shared database. The cost of knowing first is one command.

The Iron Law

NO CHANGE PROPOSED WITHOUT ITS IMPACT MEASURED FIRST

The Workflow

  1. pythia impact <OBJECT> --depth 2 — everything that depends on it,

as a tree, ending with the line that matters: -- impact: N dependent objects, M currently VALID.

  1. pythia deps <OBJECT> --depth 2 — the other direction, what it uses;

read it when the change touches calls or table access.

  1. pythia invalid — the baseline. Anything already INVALID before the

change must not be blamed on the change later; apply compares against this automatically, but you should know the starting state too.

Reading the numbers

Result What to do
0 dependents Say so and proceed; verify after apply anyway.
1–9 dependents List them to the developer alongside the proposal.
10+ dependents, or any cross-schema dependent Show the tree and get an explicit go-ahead before writing any code.
Dependents already INVALID Point them out — the area is already unstable.

Tables deserve the same treatment as code: impact on a table shows every program that would be invalidated by an ALTER.

Red Flags — STOP if you catch yourself thinking

Thought Reality
"It's just a small helper" Helpers are the most-depended-on objects there are.
"I'll check impact after writing the code" Then the number cannot change the design. Too late.
"The preview in apply shows impact anyway" That line is confirmation of a number you already knew — not discovery.
"It's a new object, nothing depends on it" True — say that, with impact output as evidence, not as an assumption.

Hand-off

Impact known and acceptable → pythia-write to write the change following the codebase's conventions → pythia-apply to land it with preview and verification.