From skills-for-humanity
Maps and classifies design constraints by hardness (hard limits vs. soft preferences) to define the solution space. Useful when starting a design task or reframing a problem.
How this skill is triggered — by the user, by Claude, or both
Slash command
/skills-for-humanity:s4h-design-constraintsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Every design problem has a solution space — the set of forms that could satisfy the need. Constraints are not what prevent good design; they are what define the problem precisely enough to be solved. A problem with no constraints has no solution because it has no shape. The designer's task is to understand the constraint set completely: which limits are genuinely fixed, which are preferences th...
Every design problem has a solution space — the set of forms that could satisfy the need. Constraints are not what prevent good design; they are what define the problem precisely enough to be solved. A problem with no constraints has no solution because it has no shape. The designer's task is to understand the constraint set completely: which limits are genuinely fixed, which are preferences that could move, and what territory they collectively leave open.
Christopher Alexander's work on pattern languages makes this explicit: every good design form is a response to a specific set of forces in tension. Understanding those forces — what they require, where they conflict, where they align — is how a designer finds the form that resolves them. Jony Ive's approach at Apple was similar: start with the hardest constraints (manufacturing tolerances, material properties, thermal dissipation) and let design decisions cascade from there. The hardest constraint is often the most generative.
This skill maps the full constraint set, classifies each constraint by hardness, surfaces the interactions between them, and identifies where the productive design space lies within the boundaries they collectively draw.
Step 1: Elicit the Full Constraint Set List every known constraint. Do not classify or judge yet — just enumerate. Include:
Framing check: Confirm the design context and the constraint domain before continuing. State what you've identified — the thing being designed and the primary constraint types in play — in one sentence, then use AskUserQuestion:
Step 2: Classify by Hardness For each constraint, classify:
For each soft or assumed constraint, note what it would take to move it.
Step 3: Map Constraint Interactions Some constraints compound: two constraints together rule out more territory than either does alone. Some constraints conflict: they cannot be satisfied simultaneously at full strength, requiring a trade-off. Some constraints are redundant: satisfying one automatically satisfies another.
Identify:
Step 4: Find the Tightest Constraint The tightest genuine constraint is the one with the smallest solution set. It determines where to start design. It is usually the most generative constraint — because it narrows the field to what's actually possible and often points toward what's uniquely possible within those limits.
Identify the tightest constraint or constraint pair. Ask: what does design look like if this constraint is accepted fully and treated as a design requirement?
Step 5: Map the Solution Space Given the hard constraint set, describe the territory that remains open. What categories of solution are viable? What are the dimensions of variation within that territory? Where are the most interesting sub-regions — areas with multiple viable directions, or areas where constraints interact in generative ways?
Before proceeding, use the AskUserQuestion tool. State your interpretation of the situation in 1–2 sentences — what is being designed and which constraints seem most significant — then ask:
Proceed based on their selection. If the user reframes, incorporate the correction before running any analysis.
Constraint inventory:
| Constraint | Domain | Classification | Notes |
|---|---|---|---|
| [Constraint] | [Domain] | Hard / Soft / Assumed | [What it would take to move, if soft] |
Constraint interactions:
| Pair | Type | Effect |
|---|---|---|
| [A] + [B] | Compounding / Conflicting / Redundant | [What this means for design] |
Tightest constraint:
[State it. What category of design decisions it forces.]
Solution space: [3–5 sentences describing the design territory that remains viable. What categories of solution are open, what dimensions of variation exist, and where the most interesting territory is.]
Design direction implied:
[One to two sentences. Given this constraint set, what kind of solution is it pointing toward?]
This skill is a close neighbour of /s4h-constraint-hardness-testing, which focuses on testing whether individual constraints are actually real. Design constraints goes further: it treats the full constraint set as a system and asks what solution space it collectively defines. Use hardness-testing when you need to challenge a specific constraint; use this skill when you need to understand how the full constraint map shapes the design problem.
The most common error is treating all constraints as equally hard and using them to justify not exploring territory that's actually open. Separate the hard from the soft before concluding that a class of solution is impossible.
After delivering this output, use AskUserQuestion to offer the next move:
/s4h-design-user-needs — Revisit what the user actually needs within this solution space/s4h-design-iteration — Begin the design cycle within the solution space you've mapped/s4h-constraint-rule-inversion — Flip the tightest constraint into a creative drivernpx claudepluginhub human-avatar/skills-for-humanityMaps 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".
Conducts design discovery before building features, components, or interfaces. Explores intent, users, constraints, and context via quick or full conversational modes.