Design
Agent skills for agentic coding tools. Extremely opinionated. Updated (almost) daily.
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.
One thing to look at
- 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.
What its author says it does
Copied from the file, not written here
Use when the requested deliverable is distinct competing approaches to compare before choosing what to implement.
SKILL.md
5.3 KB, 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>