principle-attack-the-premise
Apply when two or more fixes that share one premise have failed the same gate. Take a census of which actors hold the imbalance before the next fix, then question the premise instead of writing another fix that assumes it.
Install
npx skills add https://github.com/cursor/plugins --skill principle-attack-the-premiseSKILL.md
Attack the Premise
When two or more fixes that share one premise have failed the same gate, suspect the premise, not the fixes.
Why: Each failure under a shared premise is evidence about the premise.
Pattern:
- Write the premise down. The premise is the one sentence that every failed fix assumed.
- Take a census before the next fix. Count the imbalance per actor. The census shows which actors hold the imbalance, not how large it is. Write the census as a rerunnable script per Build the Lever.
- Read the skew. If the same few actors hold most of the imbalance on every run, something assigns them that role. Find what assigns the role. That assignment is the next "why" per Fix Root Causes.
- Remove the asymmetry instead of compensating for it, per the Laziness Protocol. Rotate the role between actors, randomize the assignment, or move the role, so that no actor holds it on every run. A return path, a shared pool, a batched hand-off, or a periodic rebalance leaves the assignment in place and adds work on every run.
Stop:
- Do not start the next fix before the premise is written down and the census exists.
- If the census is even across actors, the premise is not the cause. Look for the cause elsewhere and keep the census as evidence.
This principle is distinct from Redesign from First Principles, which rebuilds a design around a new requirement. It questions a fact the current design assumes.
Related skills
improve-codebase-architecturemattpocock1MScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.codebase-designmattpocock691KShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.web-design-guidelinesvercel-labs676KReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".code-reviewmattpocock631KReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".