菜单
Attack a proposal's feasibility before endorsing it: extract its binding requirements — resources, limits, permissions, dependencies, deadlines — and test each against known constraints. One hard infeasibility ends the endorsement.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Check a deliverable against its actual consumer: who reads it, what they do next, what format and register they need, and what they will assert downstream on its basis. Activate when the deliverable has a named audience beyond the requester, or its text will be forwarded, announced, or acted on by someone absent from the conversation.
For any rule-like deliverable — code, regex, query, formula, validator, policy — enumerate the boundary inputs (empty, zero, one, max, duplicate, malformed, hostile) and actually exercise the most breakable three before shipping. Activate when the deliverable is executable or rule-like and will meet inputs the author didn't type.
State every claim at its actual evidence level — verified, inferred, assumed, guessed — and give credences only where an observable could score them; ban certainty language on unverified claims. Activate when a response makes claims about unobserved, future, or unverified state, or when the user asks how confident or likely something is.
Before intervening in a system, write the explicit causal chain from the proposed action to the intended outcome — every arrow marked verified or assumed — and check the weakest assumed arrow first. Activate when an intervention (fix, optimization, policy change, growth action) is proposed on a system whose mechanism has not been written down.
With multiple live hypotheses and a limited test budget, design the cheapest single test whose possible outcomes separate the hypotheses — with a results-to-verdict table committed before running anything. Activate when two or more competing hypotheses are on the table and the next step is choosing what test, experiment, or probe to run.
Enumerate every deliverable the request actually asked for and map each one to the work produced, so nothing asked-for is silently dropped, stubbed, or rounded up to done. Activate when a request contains multiple parts — an enumerated list, several 'and'/'also' clauses, or a spec with more than one required artifact — or before delivering a draft against such a request.
| name | feasibility-attack |
| description | Attack a proposal's feasibility before endorsing it: extract its binding requirements — resources, limits, permissions, dependencies, deadlines — and test each against known constraints. One hard infeasibility ends the endorsement. |
| license | MIT |
Trigger (observable): A novel proposal, plan, or idea is being evaluated or about to be endorsed, and it carries no cost, resource, or constraint check — enthusiasm and mechanism are present, arithmetic is not.
When NOT to activate: The proposal already includes a constraint-by-constraint feasibility case (then verify that case instead of rebuilding it); pure ideation where feasibility filtering was explicitly deferred; proposals already killed on other grounds.
A requirement-by-constraint table with pass / soft-hit (priced) / hard-hit (killing) results, ending in an explicit feasible / feasible-at-cost / infeasible verdict.
Known risk: Killing ideas on assumed constraints that were never checked ('the API probably caps at...'). Mitigation: each constraint must be cited or computed, or it's labeled assumed and can't carry a hard kill.
Max intended cost: ≤350 added output tokens; a few lookups to confirm claimed limits.
Evidence status: DESIGNED — specified from documented reasoning-failure modes; not yet executed as a packaged skill.
Lineage: Derived from a documented reasoning-failure mode — endorsing novel ideas on mechanism and enthusiasm without feasibility arithmetic — combined with two evidence-backed principles: close with an explicit verdict rather than an unranked defect list, and recognize when a constraint space is exhausted rather than continuing to search it.
