principle-attack-the-premise

Diagnose repeated fix failures by questioning the shared premise behind them.

1|Updated Aug 27, 2025
One-click install
npx skills add https://github.com/IgorGanapolsky/Random-Timer --skill principle-attack-the-premise-igorganapolsky
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-attack-the-premise
Source: https://github.com/IgorGanapolsky/Random-Timer/tree/main/.cursor/skills/principle-attack-the-premise
Command: npx skills add https://github.com/IgorGanapolsky/Random-Timer --skill principle-attack-the-premise-igorganapolsky

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When two or more fixes built on the same assumption keep failing the same gate, teams often write yet another fix instead of questioning the assumption itself. This Skill redirects debugging effort from patching symptoms to testing the premise that all failed fixes share. ## Core Features & Use Cases - Premise Identification: Write down the single sentence every failed fix assumed, making the hidden assumption explicit and testable. - Actor Census: Run a rerunnable census script that counts which actors hold the imbalance before attempting the next fix. - Asymmetry Removal: Rotate, randomize, or relocate the role causing the skew instead of adding compensating work like return paths or periodic rebalances. - Use Case: A load-balancing fix has failed three times under the assumption that traffic is uniform. Use this Skill to census per-node load, discover one node always holds the hot role, and rotate that role instead of adding another retry layer. ## Quick Start Ask the AI to apply the attack-the-premise principle to analyze why your last two fixes for the same failing gate did not work.

Frequently Asked Questions about principle-attack-the-premise

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug when multiple fixes keep failing the same test?▼

Write down the one premise every failed fix assumed, then take a census of which actors hold the imbalance before trying another fix. If the same few actors hold the imbalance on every run, find what assigns them that role and remove the asymmetry.

What is premise-based root cause analysis?▼

Premise-based root cause analysis treats each failure under a shared assumption as evidence about the assumption itself. Instead of writing another fix, you question the fact the current design assumes and test it with a rerunnable census.

When should I stop writing fixes and question the premise?▼

Stop after two or more fixes sharing one premise have failed the same gate. Do not start the next fix until the premise is written down and a census of the imbalance across actors exists.

What if the census shows the imbalance is evenly distributed?▼

If the census is even across actors, the premise is not the cause of the failures. Keep the census as evidence and look for the cause elsewhere in the system.

How is attacking the premise different from redesigning from first principles?▼

Attacking the premise questions a fact the current design assumes, while redesign from first principles rebuilds a design around a new requirement. Use premise attack for repeated failures; use redesign when requirements themselves change.