القائمة
Use when about to build or agree to build a feature, test, or check, especially when the request sounds big or clever.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when about to show any prose a human will read - docs, README, commit bodies, UI copy, store text.
Use when building any mechanic that could fail on a machine out of reach - a shipped product, a CLI a user runs, a server.
Use when doing any work in a project that has the instincts plugin installed
Use when touching build scripts, release or packaging steps, publish flows, or CI config.
Use when about to build something someone proposed, especially when the proposer sounds confident and the idea sounds obviously fine.
Use when adding any cross-cutting change - a new gate, limit, permission check, or rule that must apply everywhere.
| name | feasibility-guard |
| description | Use when about to build or agree to build a feature, test, or check, especially when the request sounds big or clever. |
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".
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.
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.
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.)
| 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. |
