菜单
Tests whether a stated constraint is real — distinguishing genuine limits from assumptions, habits, or politics dressed as facts. Triggers: 'is this really a constraint', 'challenge the assumption', 'who says we can't', 'is this actually fixed', 'test the constraint'.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Master orchestration skill. Takes any situation in plain English, identifies the underlying goal, designs a multi-skill reasoning workflow, and executes it sequentially — feeding each skill's output into the next. Use when you say 'help me think through this', 'I need to figure out what to do', 'where do I start', or any time you want structured thinking applied end-to-end rather than routed to a single tool.
Tests whether the parts of something form a unified whole — finding the jarring inconsistencies that accumulate when different contributors work without a shared vision. TRIGGERS: 'coherence check', 'does this feel unified', 'something feels off', 'inconsistent', 'check the whole', 'does this hang together'.
Tests whether a solution is more complex than it needs to be — distinguishing necessary complexity from accidental complexity that accreted over time. TRIGGERS: 'elegance test', 'is this too complex', 'over-engineered', 'is there a simpler way', 'does this feel right'.
Identifies the underlying formal pattern at work — because most successful designs, arguments, and solutions share deep structural patterns, and naming the pattern unlocks the playbook. TRIGGERS: 'what pattern is this', 'pattern recognition', 'why does this work', 'identify the form', 'what structure is at play', 'what archetype is this'.
Finds the simpler version while preserving what matters — not arbitrary reduction, but finding the core and discarding what is not it. TRIGGERS: 'find the simple version', 'simplify this', 'what's the essence', 'less but better', 'strip it back', 'what could we remove'.
Entry point for the aesthetic toolkit. Routes to the right aesthetic skill based on your situation. Use when you say 'aesthetic', 'check the design', 'does this feel right', 'is this elegant', 'is this too complex', 'what pattern is this', 'find the simpler version', or want an aesthetic lens applied without knowing which specific tool fits.
| name | s4h-constraint-hardness-testing |
| description | Tests whether a stated constraint is real — distinguishing genuine limits from assumptions, habits, or politics dressed as facts. Triggers: 'is this really a constraint', 'challenge the assumption', 'who says we can't', 'is this actually fixed', 'test the constraint'. |
Organisations accumulate phantom constraints — rules that were real once and calcified, or beliefs that were never tested, or someone's preference that got repeated until it sounded like policy. This skill separates genuine limits from assumed ones before any energy is spent working around or accepting them.
Step 1: State the Constraint Write it exactly as it's been stated or assumed. Don't clean it up — the imprecision is often where the phantom lives.
Framing check: Confirm the specific constraint and the goal it is blocking before continuing. State what you've identified — the exact constraint as you understand it and the goal or action it prevents — in one sentence, then use AskUserQuestion:
Step 2: Source It Who said this constraint exists? When? Is the source a law or regulation, a signed contract, a technical impossibility, a leadership decision, a team preference, or unknown? The source determines the hardness ceiling.
Step 3: Consequence Test What actually happens if this constraint is violated? State the consequence concretely. If the answer is "I'm not sure" or "someone would be unhappy," the constraint is not hard. Distinguish real consequences (fine, contract breach, system failure) from assumed ones (pushback, awkwardness, political cost).
Step 4: Precedent Check Has anyone tried to change or violate this constraint before? What happened? No precedent often means no one has tested it — not that it can't be changed.
Step 5: Conditions Test Under what circumstances would this constraint not apply? A truly hard constraint has no exceptions. If you can find a scenario where it wouldn't hold, the constraint is softer than stated.
Step 6: Classify
Before proceeding, use the AskUserQuestion tool. State your interpretation of the situation in 1–2 sentences — what is being analyzed and what the core question is — then ask:
Proceed based on their selection. If the user reframes, incorporate the correction before running any analysis.
Constraint as stated:
[Exact wording]
Source: [Law/contract/technical/decision/preference/unknown] — [specific origin]
Consequence if violated:
[Concrete statement] — Real / Assumed
Precedent: [What happened when tested, or "untested"]
Conditions where it wouldn't apply:
[If any]
Classification: Hard / Soft / Assumed / Outdated
Recommended action:
| Classification | Action |
|---|---|
| Hard | Accept — design around it |
| Soft | Negotiate explicitly |
| Assumed | Test it — ask the source directly |
| Outdated | Challenge it — propose removal |
The most dangerous class is Assumed, because it looks like Hard. Before accepting any constraint that cannot be sourced precisely, treat it as Assumed and test it — the cost of testing is almost always lower than the cost of a permanent workaround.
After delivering this output, use AskUserQuestion to offer the next move:
/s4h-constraint-workaround-mapping — Route around the hard constraints/s4h-constraint-scope-reduction — Reduce scope to avoid constraints that can't be bypassed/s4h-decision-option-mapping — See what options remain given hard and soft constraints