Design
Use when the requested deliverable is distinct competing approaches to compare before choosing what to implement.From its SKILL.md
npx -y skills add JHostalek/dotclaude --skill designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- skips confirmationTells the agent to proceed without asking first, 1 time: "Invoking this skill is the authorization to fan out — so spawn without asking".
- 10 stars10 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.3 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
problem = $ARGUMENTS
Senior Design Orchestrator. Purpose: produce genuinely orthogonal approaches — different core mechanisms, not surface variants of one idea — so the user can make a real tradeoff decision rather than choose between disguised versions of the same thing.
Invoking this skill is the authorization to fan out — the explorer panel is the mechanism, so spawn without asking. The caps below are the damper.
Governing principles
- Ideation ≠ filtering. Diverge first, constrain later — mixing the two kills divergence before it starts.
- Diversity comes from structure, not instruction. Independent clean contexts + distinct reasoning methods + unique provocations make convergence structurally hard. Instruction alone ("be creative") is insufficient.
- Don't refine approaches in your own context. The explorers' independent contexts created the diversity; merging revisions into your context destroys it. Send feedback back; let explorers revise in place.
Scale to problem complexity
- Quick (simple/bounded): skip defamiliarize, 3 explorers, one synthesis.
- Standard (default): defamiliarize, 4-5 explorers, one synthesis + optional gap-fill.
- Deep (high-stakes/ambiguous): defamiliarize, 6-8 explorers, multiple synthesis rounds.
Scale up if user signals high stakes or defamiliarize reveals hidden complexity.
Defamiliarize
Name the 2-3 obvious solutions first — you can't escape defaults you haven't named. Then reframe through these lenses (each yields a reframing, not a solution):
- Step-Back: abstract class of problem this belongs to, domain details stripped.
- Inversion: worst possible approach; which assumptions might be wrong.
- Distant Analogy: unrelated domain (biology, logistics, game theory) with the same structural shape.
- Constraint Removal: ideal w/ no constraints; ideal w/ the primary constraint 10x tighter.
Reframings seed the explorers — not the solutions. Run all four.
Diverge
| Explorer | Agent file | Reasoning style |
|---|---|---|
| Forward Build-Up | forward-build-up.md | Build up from smallest viable unit |
| Backward from Ideal | backward-from-ideal.md | Start from perfect outcome, work backward |
| Constraint-First | constraint-first.md | Solve hardest constraints first |
| Analogical Transfer | analogical-transfer.md | Map from a well-solved problem in another domain |
| Elimination | elimination.md | Remove everything unnecessary |
| Adversarial | adversarial.md | Attack the obvious solution, build what survives |
| Composition | composition.md | Compose existing proven primitives |
| Temporal | temporal.md | Design a trajectory across time, not a single state |
| Stakeholder | stakeholder.md | Design for conflicting stakeholder needs simultaneously |
Minimum coverage: Forward Build-Up, Backward from Ideal, Constraint-First, + one other relevant style. Invent a reasoning style when the problem needs an axis this catalog doesn't carry.
Spawn explorers, each with a clean context containing only:
- the problem statement,
- their assigned method from
${CLAUDE_SKILL_DIR}/agents/<name>.md, - relevant reframings,
- a unique provocation no other explorer gets (random constraint, forced analogy, "what if") — this breaks the homogenization that converges LLM outputs even across independent contexts,
- the anti-priming guard verbatim: "The orchestrator's reframings are starting points, not constraints. If the reframing feels wrong for your reasoning method, ignore it and start from the raw problem.",
- the output contract verbatim: "Return your approach with narrative trade-offs: core mechanism, what it enables, what it sacrifices, and what makes it fundamentally different from the obvious solution."
No teammate sees another's work. For codebase-aware problems: same codebase context to each, different reasoning methods.
Synthesize & verify distance
For each pair, name the core mechanism — the fundamental "how," not the framing. Shared core mechanism = variants, not alternatives. Audit assumptions ALL approaches share — those are the blind spots.
On convergence, diagnose then fix:
- Axis Collapse — cosmetically different, same underlying structure.
- Function Lock — all solve the same sub-problem first, anchoring everything.
- Domain Imprisonment — all stay inside the domain's conventions.
- Novelty Chase — different but purposelessly weird.
Spawn targeted fix subagents with the shared assumption declared off-limits.
<output_contract>
Save to docs/designs/<short-name>.md:
- Problem statement + reframings (including the named defaults)
- Solution landscape (where each approach sits)
- Each approach: core mechanism, what it enables, what it sacrifices, when to choose it
- Shared assumptions across all approaches
- Unexplored territory and why
For architecture/spatial designs, include concrete artifacts (Mermaid, ASCII wireframes, data-flow sketches) — visuals compare better than prose.
Length is not a quality signal here. An approach that can't be stated as a mechanism in a short paragraph hasn't been reduced to its mechanism yet, and no section restates another. </output_contract>
What ships with it: 9 files
6.3 KB alongside SKILL.md
agents/
- adversarial.md654 B
- analogical-transfer.md708 B
- backward-from-ideal.md652 B
- composition.md732 B
- constraint-first.md711 B
- elimination.md821 B
- forward-build-up.md624 B
- stakeholder.md883 B
- temporal.md711 B
Gives 0 of the 12 instructions most design frontend skills give in ~1.1k tokens
Counted across 1,179 of the 2,086 authors here whose files we hold, read 2026-09-06
- Commit to a bold aesthetic directionin 31 of 1179, across 24 files
- Prefer component composition over inheritancein 28 of 1179, across 14 files
- Animate only transform and opacity propertiesin 27 of 1179, across 22 files
- Memoize expensive computations with useMemoin 26 of 1179, across 13 files
- Use semantic HTML elementsin 24 of 1179, across 23 files
- Virtualize long lists for performancein 21 of 1179, across 10 files
- Use CSS variables for design tokensin 20 of 1179, across 14 files
- Implement loading, empty, and error statesin 20 of 1179
- Lazy load heavy components with Suspensein 19 of 1179, across 8 files
- Respect prefers-reduced-motion media queriesin 18 of 1179, across 10 files
- Prioritize CSS-only animations for HTMLin 18 of 1179, across 16 files
- Use compound components for related UI elementsin 18 of 1179, across 7 files
Said here and by no other author read
- spawn explorers without asking for permission
- name obvious solutions before reframing
- run all four defamiliarization lenses
- assign each explorer a unique reasoning style
- provide each explorer a unique provocation
- keep explorer contexts independent and clean
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.