lets-design
Skill1 starsChanged 10 days agoMITView on GitHub
Design a change with the user, from a rough ask, a ticket, or a problem: ground it in the code, grill until it's understood, size it, and design it. Small asks get options and trade-offs in conversation; big ones get alternative designs explored in parallel. Use when the user says let's design, or asks to design a change together.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- arenaSkill
- build-ticketSkill
- deep-reviewSkill
- design-it-twiceSkill
- designSkill
- domain-modelingSkill
- grillingSkill
- land-to-mainSkill
- lets-buildSkill
- model-tiersSkill
- prepare-commitSkill
- ready-ticketSkill
- reflectSkill
- review-diffSkill
- to-ticketsSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
If it's unclear which ticket, ask.
- Distinctive: line 21
Read the ask in full, and skim other open tickets.
- Distinctive: line 22
Read the project's glossary and the ADRs in the area, if it has them.
- Distinctive: line 23
Read the code the change touches, to know what the system does today.
- Very specific: line 30
Use the /grilling skill until the problem and requirements are sharp enough to design against.
- Very specific: line 49
Use /arena instead when the user asks for it, or would rather have one combined design than choose.
- Very specific: line 53
After /arena, the user reviews its combined sketch instead.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Let's Design
The agent does the design work. The user settles requirements and decisions, and approves the design. Design is the primary activity: there is no separate plan.
1. Ground
Identify the ask. The user may give a ticket id, URL, file path, or pasted text, or just describe it. If it's unclear which ticket, ask.
- Read the ask in full, and skim other open tickets; read the related ones. Don't expand scope from them.
- Read the project's glossary and the ADRs in the area, if it has them.
- Read the code the change touches, to know what the system does today.
Where the ask and the code disagree, trust the code for what is true today. Raise significant mismatches. Restate what's being asked, and why, in a few lines, so a misunderstanding shows up early.
2. Grill
Use the /grilling skill until the problem and requirements are sharp enough to design against.
3. Size
Say whether this is a small or a big design, and why. The user may overrule.
- Small: fits one implementation ticket, and a few decisions settle its shape.
- Big: needs several implementation tickets, or its shape isn't obvious.
4. Design
Small
Point out the key design decisions a solution has to make. For each that matters, give a small set of options with trade-offs and what you would pick, then wait for the user.
Big
- Explore alternatives as sketches with
/design-it-twice. Use/arenainstead when the user asks for it, or would rather have one combined design than choose; its task asks for a sketch-level proposal in the/designskill's shape, with the path to its template, and its synthesis note fills the proposal's Synthesis decision. - Compare and recommend; the user chooses a sketch, or a hybrid.
After
/arena, the user reviews its combined sketch instead. - Develop the chosen sketch into a detailed design with the user, working its decisions through as for a small design.
Either size
Settle, with the user, everything a detailed proposal in the /design skill's shape needs,
including its done checks.
Done
Present the settled design as a detailed proposal in the /design skill's shape.
The design is done when the user approves it. The user says where it goes next.
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.