Feasibility guard
Skill Fergius-Engineering/instincts/skills/feasibility-guard
Working-instinct skills for Claude Code: verify claims against the source, log for the bug you can't reproduce, write like a human, test so the test bites. A reflex layer on top of superpowers.
npx -y skills add Fergius-Engineering/instincts --skill feasibility-guardAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when about to build or agree to build a feature, test, or check, especially when the request sounds big or clever.
SKILL.md
2.0 KB, as published. Nobody here has run it
The rule
Not every request should be built as asked. Before you start, weigh the cost against the value. If the feature is over-engineered, say so and propose the smaller thing. Same when a test could only exist on a pile of mocks, or a check would drown the user in false positives. Agreeing to bad work quickly is not helping.
superpowers' brainstorming explores what to build; this skill is the license to answer "nothing" or "less".
Fires when
About to build a feature, write a test, or add a check — especially when the request sounds big or clever, or you catch yourself reaching for a lot of mocking and scaffolding.
How to apply
Ask "is this worth the effort, and will it actually work?" before you start.
Flag a test that would be fragile or need mocking half the system, a check that would fire mostly false positives, complexity that outweighs its benefit. Offer the smaller version, or say skip it.
Don't just agree because it was asked.
Worked example
You're asked to add a test for a function, but covering it properly would mean mocking the database, the clock, the network, and three collaborators, and the test would break on any refactor. That's a fragile test that protects almost nothing. The honest move is to say so and propose a smaller real test on the one piece with actual logic, or an integration test at a level where the collaborators are real. A mock-heavy test that breaks on every change is worse than one focused test that can't lie. (What makes a test worth having is tests-with-teeth's territory; this rule is about saying no before the work starts.)
Red flags
| Thought | Reality |
|---|---|
| "They asked for it, so build it" | Asked is not the same as worth it. |
| "I'll just mock everything" | A test held up by ten mocks is testing the mocks. |
| "More coverage is always better" | Coverage of the wrong thing is just noise. |