design-it-twice
Skill1 starsChanged 12 days agoMITView on GitHub
Explores radically different designs for one problem through parallel subagents, each under a different design constraint, then presents and compares them and recommends one. Use when the user wants alternative designs, says design it twice, or when the first idea's shape isn't obvious.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- etr/groundworktheir own version, first seen Nov 8, 2026
- SrdjanCoric/skillstheir own version, first seen Aug 2, 2026
- codybrom/clairvoyancetheir own version, first seen Jul 1, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- etr/groundwork★ 45same name
- SrdjanCoric/skills★ 18same name
- codybrom/clairvoyance★ 12same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- arenaSkill
- build-ticketSkill
- deep-reviewSkill
- designSkill
- domain-modelingSkill
- grillingSkill
- land-to-mainSkill
- lets-buildSkill
- lets-designSkill
- model-tiersSkill
- prepare-commitSkill
- ready-ticketSkill
- reflectSkill
- review-diffSkill
- to-ticketsSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Use this parallel sub-agent pattern to explore alternative designs for one problem.
- Distinctive: line 19
Before spawning sub-agents, write a user-facing explanation of the problem space:
- Very specific: line 32
Run them on the current model unless the user asks for others.
- Distinctive: line 46
Use this brief template:
- Distinctive: line 64
After comparing, give your own recommendation: which design you think is strongest and why.
- Distinctive: line 65
If elements from different designs would combine well, propose a hybrid.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Design It Twice
Use this parallel sub-agent pattern to explore alternative designs for one problem. Your first idea is unlikely to be the best.
1. Frame the problem space
Before spawning sub-agents, write a user-facing explanation of the problem space:
- The constraints any design would need to satisfy
- The dependencies it would rely on, and the existing code it must fit with
- A rough illustrative code sketch to ground the constraints, not a proposal, just a way to make the constraints concrete
Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
2. Spawn sub-agents
Spawn 3+ sub-agents in parallel, each with a fresh context window. Each must produce a radically different design.
Run them on the current model unless the user asks for others; resolve those with /model-tiers.
Share what you've already learned as grounding, so the sub-agents build on it rather than repeating the research. Include the project's glossary vocabulary, if it has one, so each sub-agent names things in the domain's language.
Give each agent a different design constraint. Choose constraints that pull the problem's real tensions apart, so the designs differ in shape, not detail. E.g., for the design of a module's interface, start from these:
- Agent 1: "Minimize the interface: aim for 1–3 entry points max. Maximise leverage per entry point."
- Agent 2: "Maximise flexibility: support many use cases and extension."
- Agent 3: "Optimise for the most common caller: make the default case trivial."
- Agent 4 (if applicable): "Design around ports & adapters for cross-seam dependencies."
Use this brief template:
Read and follow <absolute path to this skill's directory>/runner.md.
Problem: <one paragraph>
Constraint: <this agent's design constraint>
Proposal template: <absolute path to the design skill's directory>/proposal.md
Grounding: <paths to shared grounding, or "none">3. Present and compare
Present designs sequentially so the user can absorb each one, then compare them in prose. Contrast by:
- depth: how much the design hides behind how little callers must learn;
- locality: where change, bugs, and knowledge concentrate;
- fit: where it meets the existing system, and what that costs.
After comparing, give your own recommendation: which design you think is strongest and why. If elements from different designs would combine well, propose a hybrid. Be opinionated: the user wants a strong read, not a menu.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.