$npx -y skills add human-avatar/skills-for-humanity --skill s4h-design-constraintsUses constraints productively — maps hard limits, soft preferences, and how the tightest constraints define the solution space. Triggers: 'what are the design constraints', 'map the constraints', 'what are we working within', 'what's fixed', 'constraint-driven design', 'what does
| 1 | # Design: Design Constraints |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## Your Process |
| 12 | |
| 13 | **Step 1: Elicit the Full Constraint Set** |
| 14 | List every known constraint. Do not classify or judge yet — just enumerate. Include: |
| 15 | - Technical constraints (what the medium or material allows) |
| 16 | - Physical constraints (size, weight, space, material properties) |
| 17 | - Economic constraints (cost, time, resources) |
| 18 | - Regulatory or legal constraints (requirements that must be met) |
| 19 | - Organisational constraints (what the team, system, or process can support) |
| 20 | - User constraints (what users can understand, do, or accept) |
| 21 | - Aesthetic or brand constraints (what must be consistent with existing forms) |
| 22 | |
| 23 | **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`: |
| 24 | - **Question:** "I'm reading this as: [your one-sentence framing of the design context and constraints]. Is that right?" |
| 25 | - **Header:** "Framing" |
| 26 | - **Options:** |
| 27 | - **Yes — proceed** — framing is correct |
| 28 | - **Adjust** — one element is off; user will correct it before you continue |
| 29 | - **Reframe** — different situation than read; incorporate the correction before proceeding |
| 30 | |
| 31 | **Step 2: Classify by Hardness** |
| 32 | For each constraint, classify: |
| 33 | - **Hard:** genuinely fixed — physical law, signed contract, technical impossibility, binding regulation |
| 34 | - **Soft:** real but negotiable — someone's preference, a policy that could be changed, a convention rather than a rule |
| 35 | - **Assumed:** stated as a constraint but never tested — habit, fear, or unknown origin |
| 36 | |
| 37 | For each soft or assumed constraint, note what it would take to move it. |
| 38 | |
| 39 | **Step 3: Map Constraint Interactions** |
| 40 | 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. |
| 41 | |
| 42 | Identify: |
| 43 | - **Compounding pairs:** constraints that together eliminate a class of solution |
| 44 | - **Conflicting pairs:** constraints that create a trade-off requiring a design decision |
| 45 | - **Redundant constraints:** where satisfying one satisfies another for free |
| 46 | |
| 47 | **Step 4: Find the Tightest Constraint** |
| 48 | 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. |
| 49 | |
| 50 | 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? |
| 51 | |
| 52 | **Step 5: Map the Solution Space** |
| 53 | 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? |
| 54 | |
| 55 | --- |
| 56 | |
| 57 | ## Human Check-in |
| 58 | |
| 59 | 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: |
| 60 | |
| 61 | - **Question:** "My read: [your 1–2 sentence inte |