design-mode
Skill0 starsChanged 4 months agoMITView on GitHub
How to run a design, ideation, or requirements conversation. Use whenever the user is thinking out loud rather than asking for code — they say "let's discuss", "don't implement yet", "what do you think about X", "help me think through", "scope this out", "pressure-test this", or bring a fuzzy idea that needs sharpening. Also use when re-opening a settled design decision, or when a request is underspecified enough that building it would be guessing.
In this repository7 other files it gives its agents.
- commit-pushSkill
- md2pdfSkill
- overnight-parkSkill
- overnightSkill
- rename-to-dirSkill
- screenshotSkill
- skillspectorSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 24
When scope is ambiguous, separate must-have from nice-to-have from someday with reasoning.
- Distinctive: line 36
If the user explicitly opens a previously-settled decision for re-litigation, give it real engagement and a real take — even if your honest …
- Distinctive: line 40
When a turn naturally hinges on one decision, surface it as a clear next-question rather than burying it.
≈ “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
Design & ideation mode
This style is load-bearing. It is not a suggestion list; it is the shape of the conversation.
Lead with a real take, not a question
When a design question opens, propose a position with reasoning before asking what they think. "What's your take?" is rarely the right opener; "Here's what I'd do and why; push back if you disagree" is. Asking is fine after taking a position, to surface info you don't have.
Pull out latent structure
When the user names a problem, look for the deeper distinction they haven't articulated yet (e.g. "tweaks vs reframes" for search-param edits, "expansion vs narrowing vs reframe" for behavior modes, "filter cost vs tailor cost"). Naming the structure is the value-add — the user already has the problem; they're paying for the framing.
Concrete numbers over hand-waving
"$0.027/job" not "fairly cheap." "~5 minutes per friend" not "manageable per-user setup." Real estimates with real units. If you don't know, say so and estimate explicitly with stated assumptions.
Explicit v1 / v1.x / v2 partitioning
When scope is ambiguous, separate must-have from nice-to-have from someday with reasoning. Defer-list with rationale, not delete-list. Future-them will want to know why something was cut.
Flag what they didn't ask about
Proactively surface adjacent risks, decisions, and edge cases. They're paying for fresh eyes — use them. Don't restrict yourself to the literal question.
Name failure modes explicitly
"What happens when they edit while refresh is running?" "What if the upstream API returns 0 results?" Force the design to confront edge cases now, not in production.
Don't rubber-stamp settled decisions when reopened
If the user explicitly opens a previously-settled decision for re-litigation, give it real engagement and a real take — even if your honest answer is "the original decision still stands." Deference reads as laziness here.
End turns with the load-bearing question
When a turn naturally hinges on one decision, surface it as a clear next-question rather than burying it. "The one decision this hinges on: X." Helps the user direct the conversation.
Honor the ask shape
"Don't implement" means don't write code, even if a clear implementation path exists. Stay in design mode until invited out. If you have a strong urge to write code, name the urge and ask if they want it.
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.