simplify
Skill0 starsChanged 4 months agoMITView on GitHub
Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean.
119 other projects use a version of this.
Adopted by
Most recently taken up by
- thistleknot/skillstheir own version, first seen Nov 8, 2026
- PeanutGT/NutsSkillstheir own version, first seen Nov 8, 2026
- Ovich/charrettetheir own version, first seen Nov 8, 2026
- caidanw/skillstheir own version, first seen Nov 8, 2026
- Ovich/swarmstormtheir own version, first seen Nov 8, 2026
- alexandrosandre/agentic-engineeringtheir own version, first seen Nov 8, 2026
Used with
Projects with it also use codex-system, design-tracker and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
gaebalaiSkillcodex-system
PROACTIVELY consult Codex CLI, your highly capable supporter with exceptional reasoning and task completion abilities. Codex is a trusted expert you should ALWAYS consult BEFORE making decisions on: design choices, implementation approaches, debugging strategies, refactoring plans, or any non-trivial problem. When uncertain, consult Codex. Don't hesitate - Codex provides better analysis. Explicit triggers: "think deeper", "analyze", "second opinion", "consult codex".
Also in 3 projects that use this
gaebalaiSkilldesign-tracker
PROACTIVELY track and document project design decisions without being asked. Activate automatically when detecting architecture discussions, implementation decisions, pattern choices, library selections, or any technical decisions. Also use when user explicitly says "記録して", "設計どうなってる", "record this". Do NOT wait for user to ask - record important decisions immediately.
Also in 3 projects that use this
mike22890Skillclonedeps
将项目依赖的第三方库源码克隆到本地,便于深入阅读和调试。当需要查看库的实现细节、阅读源码、调试第三方依赖、理解 SDK/framework 内部机制、查看 node_modules 之外的原始代码、分析开源库架构、学习他人代码、查看依赖的 TypeScript 类型定义时使用。
Also in 3 projects that use this
mdrubelamin2Skillverification-planning
Plans how to prove a change works or broke nothing: frames the claim, designs an evidence path from the system itself, and requires every check to be able to fail.
Also in 3 projects that use this
devbrother2024Skillartifact-design
단독 self-contained HTML 산출물(랜딩 페이지, 정적 문서·리포트, 독립 대시보드, 데모·게임, 개발 전 UX/UI 대안 비교 목업)을 만들 때 팔레트·타이포그래피·레이아웃을 의도적으로 설계하고 템플릿·AI스러운 디자인을 피하도록 돕는 디자인 가이드. HTML/CSS를 쓰기 전에 로드한다. "랜딩 만들어줘", "이 내용 단일 HTML로 예쁘게", "UX 대안 HTML로 비교해줘", "디자인 잡아줘"처럼 단독 HTML 아티팩트를 만들거나 비교하는 요청에 활성화하고, 기존 앱(React·Vue 등)의 인앱 컴포넌트 수정이나 순수 백엔드·로직 작업에는 쓰지 않는다.
Also in 3 projects that use this
codebycoreySkillbatch
Create multiple proposals from free-form feature descriptions. Use when planning several features at once, batch creating proposals, or setting up related changes.
Also in 4 projects that use this
- +3 more from gaebalai
Other versions119 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 119
- Z3Prover/z3★ 13ksame name
- aaddrick/claude-desktop-debian★ 5.5ksame name
- CherryHQ/cherry-studio-app★ 4.1ksame name
- elliothux/open-compute★ 3.3ksame name
- meta-pytorch/OpenEnv★ 2.8ksame name
- huggingface/OpenEnv★ 2.8ksame name
- bholmesdev/hubble.md★ 1.5ksame name
- kdlbs/kandev★ 1.1ksame name
- truffle-ai/dexto★ 659same name
- deadlock-mod-manager/deadlock-mod-manager★ 584same name
109 more not listed
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 repository55 other files it gives its agents.
- AGENTS.mdAGENTS.md
- scripts/AGENTS.mdAGENTS.md
- src/AGENTS.mdAGENTS.md
- .cursor/rules/publish-version-bump.mdcCursor rule
- .cursor/rules/release-version-sync.mdcCursor rule
- antigravitySkill
- auditSkill
- autoplanSkill
- bootstrapSkill
- brainstormSkill
- browseSkill
- ceo-reviewSkill
- clarifySkill
- cleanupSkill
- code-reviewSkill
- codexSkill
- component-inventorySkill
- context-restoreSkill
- context-saveSkill
- critiqueSkill
- cronSkill
- csoSkill
- cursorSkill
- debugSkill
- deepen-planSkill
- design-reviewSkill
- devex-reviewSkill
- document-reviewSkill
- eng-reviewSkill
- executing-plansSkill
- fableSkill
- finishSkill
- frontend-designSkill
- grill-meSkill
- grokSkill
- implementSkill
- learnSkill
- office-hoursSkill
- onboardSkill
- plan-design-reviewSkill
- planSkill
- polishSkill
- qaSkill
- reviewSkill
- shipfastSkill
- shipthoroughSkill
- specSkill
- statusSkill
- subagent-driven-developmentSkill
- test-driven-developmentSkill
- ui-auditSkill
- ui-ux-pro-maxSkill
- using-git-worktreesSkill
- verification-before-completionSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
21 rules. 0 are common, 19 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 111 edited versions we read keep these.
19
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
If you are running this skill in Codex, read ../references/codex-compatibility.md before following host-specific tool instructions.
- Distinctive: line 16
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
- Distinctive: line 26
If you don't find *exact* information and have to infer from existing design and functionality, stop and call the AskUserQuestionTool to …
- Distinctive: line 29
Do not proceed until you have answers — simplifying the wrong things destroys usability.
- Distinctive: line 33
Use the frontend-design skill for design principles and anti-patterns.
- Distinctive: line 55
If any of these are unclear from the codebase, stop and call the AskUserQuestionTool to clarify.
- Distinctive: line 61
Create a ruthless editing strategy:
- Distinctive: line 75
Reduce scope: Remove secondary actions, optional features, redundant information
- Distinctive: line 79
Remove redundancy: If it's said elsewhere, don't repeat it here
- Distinctive: line 82
Reduce color palette: Use 1-2 colors plus neutrals, not 5-7 colors
- Distinctive: line 87
Consistent spacing: Use one spacing scale, remove arbitrary gaps
- Distinctive: line 92
Full-width: Use available space generously instead of complex multi-column layouts
- Distinctive: line 108
Essential information only: Remove marketing fluff, legalese, hedging
- Distinctive: line 109
Remove redundant copy: No headers restating intros, no repeated explanations, say it once
- Very specific: line 118
If docs/architecture/COMPONENTS.md exists, read it before creating or specifying UI components — reuse or extend an existing component on …
- Distinctive: line 126
Remove necessary functionality (simplicity ≠ feature-less)
- Distinctive: line 129
Remove information users need to make decisions
- Distinctive: line 135
Ensure simplification improves usability:
- Distinctive: line 145
If you removed features or options:
- Distinctive: line 146
Document why they were removed
- Distinctive: line 147
Consider if they need alternative access points
“Common” is measured: kept by at least 6 in 10 of the 111 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
Host Compatibility
If you are running this skill in Codex, read ../references/codex-compatibility.md before following host-specific tool instructions. Claude Code should continue to use the Claude-specific tools and command wrappers described here.
<!-- Vendored from impeccable v1.0.0 (Paul Bakaus, Apache 2.0). See skills/vendored/impeccable/LICENSE and skills/vendored/impeccable/NOTICE.md. -->Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
Preparation (required, before any changes)
Context Gathering (Do This First)
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
Attempt to gather these from the current thread or codebase.
- If you don't find exact information and have to infer from existing design and functionality, stop and call the AskUserQuestionTool to confirm whether you got it right.
- Otherwise, if you can't fully infer or your level of confidence is medium or lower, stop and call the AskUserQuestionTool with clarifying questions first to complete your context.
Do not proceed until you have answers — simplifying the wrong things destroys usability.
Use frontend-design skill
Use the frontend-design skill for design principles and anti-patterns. Do not proceed until it has executed and you know all the do's and don'ts.
Assess Current State
Analyze what makes the design feel complex or cluttered:
- Identify complexity sources:
- Too many elements: Competing buttons, redundant information, visual clutter
- Excessive variation: Too many colors, fonts, sizes, styles without purpose
- Information overload: Everything visible at once, no progressive disclosure
- Visual noise: Unnecessary borders, shadows, backgrounds, decorations
- Confusing hierarchy: Unclear what matters most
- Feature creep: Too many options, actions, or paths forward
- Find the essence:
- What's the primary user goal? (There should be one)
- What's actually necessary vs nice-to-have?
- What can be removed, hidden, or combined?
- What's the 20% that delivers 80% of value?
If any of these are unclear from the codebase, stop and call the AskUserQuestionTool to clarify.
Keep in mind: simplicity is not about removing features — it's about removing obstacles between users and their goals. Every element should justify its existence.
Plan Simplification
Create a ruthless editing strategy:
- Core purpose: What's the one thing this should accomplish?
- Essential elements: What's truly necessary to achieve that purpose?
- Progressive disclosure: What can be hidden until needed?
- Consolidation opportunities: What can be combined or integrated?
Simplification is hard: it requires saying no to good ideas to make room for great execution. Cut decisively.
Simplify the Design
Systematically remove complexity across these dimensions:
Information Architecture
- Reduce scope: Remove secondary actions, optional features, redundant information
- Progressive disclosure: Hide complexity behind clear entry points (accordions, modals, step-through flows)
- Combine related actions: Merge similar buttons, consolidate forms, group related content
- Clear hierarchy: one primary action, few secondary actions, everything else tertiary or hidden
- Remove redundancy: If it's said elsewhere, don't repeat it here
Visual Simplification
- Reduce color palette: Use 1-2 colors plus neutrals, not 5-7 colors
- Limit typography: One font family, 3-4 sizes maximum, 2-3 weights
- Remove decorations: Eliminate borders, shadows, backgrounds that don't serve hierarchy or function
- Flatten structure: Reduce nesting, remove unnecessary containers—never nest cards inside cards
- Remove unnecessary cards: Cards aren't needed for basic layout; use spacing and alignment instead
- Consistent spacing: Use one spacing scale, remove arbitrary gaps
Layout Simplification
- Linear flow: Replace complex grids with simple vertical flow where possible
- Remove sidebars: Move secondary content inline or hide it
- Full-width: Use available space generously instead of complex multi-column layouts
- Consistent alignment: Pick left or center, stick with it
- Generous white space: Let content breathe, don't pack everything tight
Interaction Simplification
- Reduce choices: Fewer buttons, fewer options, clearer path forward (paradox of choice is real)
- Smart defaults: Make common choices automatic, only ask when necessary
- Inline actions: Replace modal flows with inline editing where possible
- Remove steps: Can signup be one step instead of three? Can checkout be simplified?
- Clear CTAs: one obvious next step, not five competing actions
Content Simplification
- Shorter copy: Cut every sentence in half, then do it again
- Active voice: "Save changes" not "Changes will be saved"
- Remove jargon: Plain language always wins
- Scannable structure: Short paragraphs, bullet points, clear headings
- Essential information only: Remove marketing fluff, legalese, hedging
- Remove redundant copy: No headers restating intros, no repeated explanations, say it once
Code Simplification
- Remove unused code: Dead CSS, unused components, orphaned files
- Flatten component trees: Reduce nesting depth
- Consolidate styles: Merge similar styles, use utilities consistently
- Reduce variants: Does that component need 12 variations, or can 3 cover 90% of cases?
- Consolidate duplicate components:
<!-- concern:component-reuse -->Ifdocs/architecture/COMPONENTS.mdexists, read it before creating or specifying UI components — reuse or extend an existing component on purpose match, cite what you found, and apply the rule of three (seereferences/component-inventory.md). Use the inventory's "Possible duplicates" section to spot cross-file components to merge — with the user's approval, since consolidation has blast radius.
Never:
- Remove necessary functionality (simplicity ≠ feature-less)
- Sacrifice accessibility for simplicity (clear labels and ARIA still required)
- Make things so simple they're unclear (mystery ≠ minimalism)
- Remove information users need to make decisions
- Eliminate hierarchy completely (some things should stand out)
- Oversimplify complex domains (match complexity to actual task complexity)
Verify Simplification
Ensure simplification improves usability:
- Faster task completion: Can users accomplish goals more quickly?
- Reduced cognitive load: Is it easier to understand what to do?
- Still complete: Are all necessary features still accessible?
- Clearer hierarchy: Is it obvious what matters most?
- Better performance: Does simpler design load faster?
Document Removed Complexity
If you removed features or options:
- Document why they were removed
- Consider if they need alternative access points
- Note any user feedback to monitor
Remember: You have great taste and judgment. Simplification is an act of confidence - knowing what to keep and courage to remove the rest. As Antoine de Saint-Exupéry said: "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."
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.

