Help us improve
Share bugs, ideas, or general feedback.
From skills-for-humanity
Applies constraint reasoning to limits blocking progress. Diagnoses whether a constraint is real, reframes it creatively, reduces scope to minimum viable, or maps workarounds.
npx claudepluginhub human-avatar/skills-for-humanityHow this skill is triggered — by the user, by Claude, or both
Slash command
/skills-for-humanity:s4h-constraintThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Applies constraint reasoning to any situation where limits are shaping (or blocking) what's possible. Diagnoses what kind of constraint work is needed and applies the right tool.
Maps the full constraint landscape for decisions, designs, or plans — distinguishing hard limits from soft preferences, surfacing hidden constraints, and finding conflicts between them.
Turns limitations into creative fuel by strategically imposing constraints to force novel thinking and break habitual patterns. Use when brainstorming feels stuck, working with limited resources, or user mentions "think outside the box" or "tight constraints".
Generates multiple solution approaches with trade-offs using structured frameworks (SCAMPER, First Principles) and hands off to planning. Includes Vision Mode for product-level rethinks and Design-It-Twice Mode for interface exploration.
Share bugs, ideas, or general feedback.
Applies constraint reasoning to any situation where limits are shaping (or blocking) what's possible. Diagnoses what kind of constraint work is needed and applies the right tool.
| You need to... | Tool |
|---|---|
| Test whether a stated constraint is actually real | hardness-testing |
| Flip a constraint into a creative driver | rule-inversion |
| Find the minimum that satisfies the actual requirement | scope-reduction |
| Find paths around a fixed constraint to reach the same goal | workaround-mapping |
Framing check: Confirm the specific constraint and the goal it is blocking before continuing. State what you've identified — the constraint itself and what it is preventing — in one sentence, then use AskUserQuestion:
Question: "I'm reading this as: [your one-sentence framing of the constraint and the goal it is blocking]. Is that right?"
Header: "Framing"
Options:
Constraint feels like it might be an assumption, habit, or politics → hardness-testing
Constraint is real but you want it to generate rather than block → rule-inversion
Scope has grown beyond what's actually needed → scope-reduction
Constraint is genuinely fixed and you need to route around it → workaround-mapping
Unclear → hardness-testing first; most "constraints" dissolve under scrutiny
After diagnosing which tool fits, use the AskUserQuestion tool to confirm direction. Construct the question dynamically to include your diagnosis:
Proceed based on their selection.
Tests whether a stated constraint is real.
Ask: who said this was fixed? When was that decided, and under what conditions? Has anyone tested it recently? Classify the constraint: physical law (truly hard), technical limit (hard but may change), organizational rule (soft — someone could change it), habit or assumption (not a constraint at all). For soft constraints: what would it take to move them? The goal is to separate genuine limits from constraints that are merely convenient to accept.
Output: Constraint classification (hard/soft/assumption), evidence for the classification, and for soft constraints: what it would take to move them.
Flips a constraint into a creative driver.
Take the constraint and state it as a design requirement: "We must [constraint]." Now ask: what would a solution look like that didn't merely tolerate this limit but was actually better because of it? The constraint removes options — which remaining options does it make uniquely possible? Limitations forced some of the most interesting design decisions in history; they don't just restrict, they focus.
Output: The constraint reframed as a requirement, 3-5 directions that only become possible under this constraint, and the most promising one to develop.
Finds the minimum that satisfies the actual requirement.
Separate what is wanted from what is needed. For each element of the current scope: what is the actual job it does? Could that job be done more simply, or not done at all? Apply the question: if we had to deliver this in half the time/budget/scope, what would we cut first? Often the answer reveals which parts were never truly necessary. The minimum viable version is usually clearer than the full version.
Output: The actual core requirement. Everything that can be removed. The simplest version that genuinely satisfies the need.
Finds paths around a fixed constraint without removing it.
Accept the constraint as fixed. Now map the solution space that exists within it: what can be done if this limit is permanent? Are there alternative routes to the same destination that don't require crossing this constraint? Are there partial solutions that get 80% of the value without hitting the limit at all? Routing around a constraint is often faster and more durable than trying to remove it.
Output: Map of available paths given the fixed constraint, with effort and value estimates for each. The most viable workaround with reasoning.