lean
Skill1 starsChanged 6 months agoMITView on GitHub
Enforces MVP development principles — speed over perfection, utility first, simplicity. Use proactively when planning features, architecting solutions, reviewing code, or evaluating technical decisions to prevent over-engineering.
9 other projects use a version of this.
Adopted by
Most recently taken up by
- varelaia/claude-skills-publictheir own version, first seen Oct 26, 2026
- FareedKhan-dev/lean-agenttheir own version, first seen Oct 13, 2026
- mattbutlerengineering/skillstheir own version, first seen Oct 11, 2026
- kapadias/nonnatheir own version, first seen Oct 1, 2026
- utk2103/Prompt-Studiotheir own version, first seen Aug 22, 2026
- ousid/leantheir own version, first seen Jul 20, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- utk2103/Prompt-Studio★ 8same name
- naticorrea-03/claude-code-skills★ 4same name
- ousid/lean★ 4same name
- civillizard/claude-lean-skill★ 2same name
- FareedKhan-dev/lean-agent★ 1same name
- mattbutlerengineering/skills★ 1same name
- Co4an/claude-auto★ 0same name
- kapadias/nonna★ 0same name
- varelaia/claude-skills-public★ 0same 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 repository13 other files it gives its agents.
- agent-cliSkill
- askSkill
- blueprintSkill
- brainstormSkill
- carveSkill
- dispatchSkill
- handoffSkill
- improve-claude-mdSkill
- llm-councilSkill
- orientSkill
- react-auditSkill
- shipSkill
- tddSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
4
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
- Very specific: line 25
Use ready-made for logging/billing/auth — focus effort on value
- Distinctive: line 31
Read the proposed solution or code
- Distinctive: line 33
Check for unnecessary complexity
- Distinctive: line 34
Verify it solves one complete task A→Z
- Distinctive: line 43
Not solving own problem first
“Common” is measured: kept by at least 6 in 10 of the 8 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
Core Rules
| Rule | Test |
| Speed > Perfection | "Ugly but useful" ships; perfect never does |
| Utility First | v1.0 = "not-stupid", not brilliant |
| One Task Rule | Handles one complete process A→Z |
| 5-Min Test | Needs 5 tools to launch → dead; works in 5min → chance |
| No Over-Engineering | Build minimum needed, nothing more |
Development Approach
- Granular tasking: small specific tasks, not essays
- Iterative: Task → Build → Test → Repeat (not spec-driven)
- AI as accelerator: 3x faster, not replacement
- Founders code: keep "feel" for product
Architecture Principles
- Use ready-made for logging/billing/auth — focus effort on value
- Open-Closed: extend via overlays, don't fork core
- Security proportional to data sensitivity
When Invoked
- Read the proposed solution or code
- Flag over-engineering against core rules
- Check for unnecessary complexity
- Verify it solves one complete task A→Z
- Verify 5-minute launchability
Red Flags
- Too many abstractions for current needs
- Premature optimization
- Feature bloat beyond the one task
- Complex setup process
- Not solving own problem first
Output Format
Over-engineered: [specific issues found]
Simplify to: [concrete alternatives]
MVP path: [minimum implementation to ship]Skip sections with no issues. Be direct — "this is fine" if nothing to flag.
Examples
Over-engineered input
"We need a plugin system with dependency injection, event bus, and config schema validation for our MVP notification feature."
MVP response
Over-engineered: Plugin system + DI + event bus for a notification feature. Three abstractions for one task.
Simplify to: Single function that sends notifications via one channel.
MVP path: `sendNotification(userId, message)` → hardcode email provider → ship today, add SMS/push when users ask.Clean input
"Add a
/healthendpoint that returns 200."
MVP response
Clean. One task, ships in 5 minutes, no abstractions.Acceptance checklist
- Reviewed proposed solution against core rules
- Flagged specific over-engineering issues (if any)
- Provided concrete simplification alternatives (if needed)
- Verified one-task completeness
- Verified 5-minute launchability
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.