simplicity-first

Name: simplicity-first
Author: DevelopersGlobal

64stars10forks

How to install simplicity-first?

developersglobal/ai-agent-skills/simplicity-first

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill simplicity-first

Installs into the current project.

Summary

Prevents overengineering by enforcing minimum viable code. No speculative features, no premature abstractions, no unnecessary complexity.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	AI agents trend toward complexity. They add abstractions "for flexibility," error handling for impossible cases, and configuration for things that will never change. Left unchecked, they turn 50-line solutions into 500-line systems.
4
5	This skill enforces a hard constraint: write the minimum code that solves the stated problem and nothing more.
6
7	Andrej Karpathy's observation: "They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do."
8
9	## When to Use
10
11	- Starting any new implementation
12	- When you feel the urge to add "just one more abstraction"
13	- When reviewing your own generated code
14	- When a simple task balloons into a complex solution
15
16	## Process
17
18	### Step 1: Define the Minimum Viable Solution
19
20	1. State what the code must do — write it as a list of requirements.
21	2. For each potential addition, ask: "Was this explicitly requested?"
22	- If no → do not add it.
23	3. Write the simplest possible implementation that satisfies each requirement.
24
25	Verify: You can trace every line of code back to a stated requirement.
26
27	### Step 2: Apply the Simplicity Test
28
29	4. After writing, read through the code and flag:
30	- Abstractions used only once → inline them
31	- Parameters never customized → hardcode them
32	- Error handling for impossible scenarios → remove it
33	- "Future-proofing" that wasn't asked for → delete it
34	- Configuration flags for things that won't vary → remove them
35
36	5. Ask: "Would a senior engineer call this overcomplicated?" If yes, simplify.
37
38	Verify: Each abstraction is used in at least 2 places; each parameter is actually varied.
39
40	### Step 3: Count the Lines
41
42	6. If your solution is more than 3× the length you'd expect for the task, something is wrong.
43	7. Actively look for ways to reduce line count without sacrificing readability.
44
45	> Rule of thumb: If 200 lines could be 50, rewrite it.
46
47	Verify: You've made at least one active attempt to reduce complexity.
48
49	### Step 4: Verify Functional Correctness
50
51	8. Run the tests. All pass?
52	9. Manually check the primary use case.
53	10. Check that no pre-existing tests regressed.
54
55	Verify: All tests pass. No regressions.
56
57	## Common Rationalizations (and Rebuttals)
58
59	\| Excuse \| Rebuttal \|
60	\|--------\|----------\|
61	\| "We might need this later" \| YAGNI. Add it when you need it. Unused code is a liability. \|
62	\| "The abstraction makes it more flexible" \| Flexibility you don't need adds complexity you always pay for. \|
63	\| "I'm following the existing patterns" \| Don't cargo-cult complex patterns into simple contexts. \|
64	\| "It's only a few more lines" \| Every extra line is a line to maintain, debug, and understand. \|
65	\| "This is more robust" \| Robust against what? Name the failure mode you're defending against. \|
66
67	## Red Flags
68
69	- You added a factory for a class that's instantiated once
70	- You added configuration for values that never change
71	- You wrote error handling for an operation that cannot fail
72	- The abstraction layer is larger than the code it abstracts
73	- You added a parameter "just in case"
74	- Your PR adds 400 lines but the feature is 40 lines of actual logic
75
76	## Verification
77
78	- [ ] Every line traces back to a stated requirement
79	- [ ] No speculative features added
80	- [ ] All abstractions used in 2+ places
81	- [ ] No error handling for impossible scenarios
82	- [ ] Line count is proportional to task complexity
83	- [ ] All tests pass
84
85	## References
86
87	- [surgical-changes skill](../surgical-changes/SKILL.md)
88	- [refactoring skill](../refactoring/SKILL.md)
89	- YAGNI principle — Martin Fowler

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

simplicity-first

64stars10forks

View on GitHub

How to install simplicity-first?

developersglobal/ai-agent-skills/simplicity-first

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill simplicity-first

Installs into the current project.

Summary

Prevents overengineering by enforcing minimum viable code. No speculative features, no premature abstractions, no unnecessary complexity.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	AI agents trend toward complexity. They add abstractions "for flexibility," error handling for impossible cases, and configuration for things that will never change. Left unchecked, they turn 50-line solutions into 500-line systems.
4
5	This skill enforces a hard constraint: write the minimum code that solves the stated problem and nothing more.
6
7	Andrej Karpathy's observation: "They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do."
8
9	## When to Use
10
11	- Starting any new implementation
12	- When you feel the urge to add "just one more abstraction"
13	- When reviewing your own generated code
14	- When a simple task balloons into a complex solution
15
16	## Process
17
18	### Step 1: Define the Minimum Viable Solution
19
20	1. State what the code must do — write it as a list of requirements.
21	2. For each potential addition, ask: "Was this explicitly requested?"
22	- If no → do not add it.
23	3. Write the simplest possible implementation that satisfies each requirement.
24
25	Verify: You can trace every line of code back to a stated requirement.
26
27	### Step 2: Apply the Simplicity Test
28
29	4. After writing, read through the code and flag:
30	- Abstractions used only once → inline them
31	- Parameters never customized → hardcode them
32	- Error handling for impossible scenarios → remove it
33	- "Future-proofing" that wasn't asked for → delete it
34	- Configuration flags for things that won't vary → remove them
35
36	5. Ask: "Would a senior engineer call this overcomplicated?" If yes, simplify.
37
38	Verify: Each abstraction is used in at least 2 places; each parameter is actually varied.
39
40	### Step 3: Count the Lines
41
42	6. If your solution is more than 3× the length you'd expect for the task, something is wrong.
43	7. Actively look for ways to reduce line count without sacrificing readability.
44
45	> Rule of thumb: If 200 lines could be 50, rewrite it.
46
47	Verify: You've made at least one active attempt to reduce complexity.
48
49	### Step 4: Verify Functional Correctness
50
51	8. Run the tests. All pass?
52	9. Manually check the primary use case.
53	10. Check that no pre-existing tests regressed.
54
55	Verify: All tests pass. No regressions.
56
57	## Common Rationalizations (and Rebuttals)
58
59	\| Excuse \| Rebuttal \|
60	\|--------\|----------\|
61	\| "We might need this later" \| YAGNI. Add it when you need it. Unused code is a liability. \|
62	\| "The abstraction makes it more flexible" \| Flexibility you don't need adds complexity you always pay for. \|
63	\| "I'm following the existing patterns" \| Don't cargo-cult complex patterns into simple contexts. \|
64	\| "It's only a few more lines" \| Every extra line is a line to maintain, debug, and understand. \|
65	\| "This is more robust" \| Robust against what? Name the failure mode you're defending against. \|
66
67	## Red Flags
68
69	- You added a factory for a class that's instantiated once
70	- You added configuration for values that never change
71	- You wrote error handling for an operation that cannot fail
72	- The abstraction layer is larger than the code it abstracts
73	- You added a parameter "just in case"
74	- Your PR adds 400 lines but the feature is 40 lines of actual logic
75
76	## Verification
77
78	- [ ] Every line traces back to a stated requirement
79	- [ ] No speculative features added
80	- [ ] All abstractions used in 2+ places
81	- [ ] No error handling for impossible scenarios
82	- [ ] Line count is proportional to task complexity
83	- [ ] All tests pass
84
85	## References
86
87	- [surgical-changes skill](../surgical-changes/SKILL.md)
88	- [refactoring skill](../refactoring/SKILL.md)
89	- YAGNI principle — Martin Fowler

People who liked this also viewed

6 picks

Type