incremental-implementation

Name: incremental-implementation
Author: addyosmani

14kinstalls8.6kforks

How to install incremental-implementation?

addyosmani/agent-skills/incremental-implementation

$npx -y skills add addyosmani/agent-skills --skill incremental-implementation

Installs into the current project.

Summary

Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

Files · 1

View on GitHub

SKILL.md

1	# Incremental Implementation
2
3	## Overview
4
5	Build in thin vertical slices — implement one piece, test it, verify it, then expand. Avoid implementing an entire feature in one pass. Each increment should leave the system in a working, testable state. This is the execution discipline that makes large features manageable.
6
7	## When to Use
8
9	- Implementing any multi-file change
10	- Building a new feature from a task breakdown
11	- Refactoring existing code
12	- Any time you're tempted to write more than ~100 lines before testing
13
14	When NOT to use: Single-file, single-function changes where the scope is already minimal.
15
16	## The Increment Cycle
17
18	```
19	┌──────────────────────────────────────┐
20	│ │
21	│ Implement ──→ Test ──→ Verify ──┐ │
22	│ ▲ │ │
23	│ └───── Commit ◄─────────────┘ │
24	│ │ │
25	│ ▼ │
26	│ Next slice │
27	│ │
28	└──────────────────────────────────────┘
29	```
30
31	For each slice:
32
33	1. Implement the smallest complete piece of functionality
34	2. Test — run the test suite (or write a test if none exists)
35	3. Verify — confirm the slice works as expected (tests pass, build succeeds, manual check)
36	4. Commit -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)
37	5. Move to the next slice — carry forward, don't restart
38
39	## Slicing Strategies
40
41	### Vertical Slices (Preferred)
42
43	Build one complete path through the stack:
44
45	```
46	Slice 1: Create a task (DB + API + basic UI)
47	→ Tests pass, user can create a task via the UI
48
49	Slice 2: List tasks (query + API + UI)
50	→ Tests pass, user can see their tasks
51
52	Slice 3: Edit a task (update + API + UI)
53	→ Tests pass, user can modify tasks
54
55	Slice 4: Delete a task (delete + API + UI + confirmation)
56	→ Tests pass, full CRUD complete
57	```
58
59	Each slice delivers working end-to-end functionality.
60
61	### Contract-First Slicing
62
63	When backend and frontend need to develop in parallel:
64
65	```
66	Slice 0: Define the API contract (types, interfaces, OpenAPI spec)
67	Slice 1a: Implement backend against the contract + API tests
68	Slice 1b: Implement frontend against mock data matching the contract
69	Slice 2: Integrate and test end-to-end
70	```
71
72	### Risk-First Slicing
73
74	Tackle the riskiest or most uncertain piece first:
75
76	```
77	Slice 1: Prove the WebSocket connection works (highest risk)
78	Slice 2: Build real-time task updates on the proven connection
79	Slice 3: Add offline support and reconnection
80	```
81
82	If Slice 1 fails, you discover it before investing in Slices 2 and 3.
83
84	## Implementation Rules
85
86	### Rule 0: Simplicity First
87
88	Before writing any code, ask: "What is the simplest thing that could work?"
89
90	After writing code, review it against these checks:
91	- Can this be done in fewer lines?
92	- Are these abstractions earning their complexity?
93	- Would a staff engineer look at this and say "why didn't you just..."?
94	- Am I building for hypothetical future requirements, or the current task?
95
96	```
97	SIMPLICITY CHECK:
98	✗ Generic EventBus with middleware pipeline for one notification
99	✓ Simple function call
100
101	✗ Abstract factory pattern for two similar components
102	✓ Two straightforward components with shared utilities
103
104	✗ Config-driven form builder for three forms
105	✓ Three form components
106	```
107
108	Three similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests.
109
110	### Rule 0.5: Scope Discipline
111
112	Touch only what the task requires.
113
114	Do NOT:
115	- "Clean up" code adjacent to your change
116	- Refactor imports in files you're not modifying
117	- Remove comments you don't fully understand
118	- Add features not in the spec because they "seem useful"
119	- Modernize syntax in files you're only reading
120
121	If you notice something worth improving outside your task scope, note it — don't fix it:
122
123	```
124	NOTICED BUT NOT TOUCHING:
125	- src/utils/format.ts has an unused import (unrelated to this task)
126	- The auth middleware could use better error messages (separate task)
127	→ Want me to create tasks for these?
128	```
129
130	### Rule 1: One Thing at a Time
131
132	Each increment changes one logical thing. Don't mix concerns:
133
134	Bad: One commit that adds a new component, refactors an existing one, and updates the build config.
135
136	Good: Three separate commits — one for each change.
137
138	### Rule 2: Keep It Compilable
139
140	After each increment, the project must build and existing tests must pass. Don't leave the codebase in a broken state between slices.
141
142	### Rule 3: Feature Flags for Incomplete Features
143
144	If a feature isn't ready for users but you need to merge increments:
145
146	```ty

People who liked this also viewed

6 picks

Type

incremental-implementation

14kinstalls8.6kforks

View on GitHub

How to install incremental-implementation?

addyosmani/agent-skills/incremental-implementation

$npx -y skills add addyosmani/agent-skills --skill incremental-implementation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Incremental Implementation
2
3	## Overview
4
5	Build in thin vertical slices — implement one piece, test it, verify it, then expand. Avoid implementing an entire feature in one pass. Each increment should leave the system in a working, testable state. This is the execution discipline that makes large features manageable.
6
7	## When to Use
8
9	- Implementing any multi-file change
10	- Building a new feature from a task breakdown
11	- Refactoring existing code
12	- Any time you're tempted to write more than ~100 lines before testing
13
14	When NOT to use: Single-file, single-function changes where the scope is already minimal.
15
16	## The Increment Cycle
17
18	```
19	┌──────────────────────────────────────┐
20	│ │
21	│ Implement ──→ Test ──→ Verify ──┐ │
22	│ ▲ │ │
23	│ └───── Commit ◄─────────────┘ │
24	│ │ │
25	│ ▼ │
26	│ Next slice │
27	│ │
28	└──────────────────────────────────────┘
29	```
30
31	For each slice:
32
33	1. Implement the smallest complete piece of functionality
34	2. Test — run the test suite (or write a test if none exists)
35	3. Verify — confirm the slice works as expected (tests pass, build succeeds, manual check)
36	4. Commit -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)
37	5. Move to the next slice — carry forward, don't restart
38
39	## Slicing Strategies
40
41	### Vertical Slices (Preferred)
42
43	Build one complete path through the stack:
44
45	```
46	Slice 1: Create a task (DB + API + basic UI)
47	→ Tests pass, user can create a task via the UI
48
49	Slice 2: List tasks (query + API + UI)
50	→ Tests pass, user can see their tasks
51
52	Slice 3: Edit a task (update + API + UI)
53	→ Tests pass, user can modify tasks
54
55	Slice 4: Delete a task (delete + API + UI + confirmation)
56	→ Tests pass, full CRUD complete
57	```
58
59	Each slice delivers working end-to-end functionality.
60
61	### Contract-First Slicing
62
63	When backend and frontend need to develop in parallel:
64
65	```
66	Slice 0: Define the API contract (types, interfaces, OpenAPI spec)
67	Slice 1a: Implement backend against the contract + API tests
68	Slice 1b: Implement frontend against mock data matching the contract
69	Slice 2: Integrate and test end-to-end
70	```
71
72	### Risk-First Slicing
73
74	Tackle the riskiest or most uncertain piece first:
75
76	```
77	Slice 1: Prove the WebSocket connection works (highest risk)
78	Slice 2: Build real-time task updates on the proven connection
79	Slice 3: Add offline support and reconnection
80	```
81
82	If Slice 1 fails, you discover it before investing in Slices 2 and 3.
83
84	## Implementation Rules
85
86	### Rule 0: Simplicity First
87
88	Before writing any code, ask: "What is the simplest thing that could work?"
89
90	After writing code, review it against these checks:
91	- Can this be done in fewer lines?
92	- Are these abstractions earning their complexity?
93	- Would a staff engineer look at this and say "why didn't you just..."?
94	- Am I building for hypothetical future requirements, or the current task?
95
96	```
97	SIMPLICITY CHECK:
98	✗ Generic EventBus with middleware pipeline for one notification
99	✓ Simple function call
100
101	✗ Abstract factory pattern for two similar components
102	✓ Two straightforward components with shared utilities
103
104	✗ Config-driven form builder for three forms
105	✓ Three form components
106	```
107
108	Three similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests.
109
110	### Rule 0.5: Scope Discipline
111
112	Touch only what the task requires.
113
114	Do NOT:
115	- "Clean up" code adjacent to your change
116	- Refactor imports in files you're not modifying
117	- Remove comments you don't fully understand
118	- Add features not in the spec because they "seem useful"
119	- Modernize syntax in files you're only reading
120
121	If you notice something worth improving outside your task scope, note it — don't fix it:
122
123	```
124	NOTICED BUT NOT TOUCHING:
125	- src/utils/format.ts has an unused import (unrelated to this task)
126	- The auth middleware could use better error messages (separate task)
127	→ Want me to create tasks for these?
128	```
129
130	### Rule 1: One Thing at a Time
131
132	Each increment changes one logical thing. Don't mix concerns:
133
134	Bad: One commit that adds a new component, refactors an existing one, and updates the build config.
135
136	Good: Three separate commits — one for each change.
137
138	### Rule 2: Keep It Compilable
139
140	After each increment, the project must build and existing tests must pass. Don't leave the codebase in a broken state between slices.
141
142	### Rule 3: Feature Flags for Incomplete Features
143
144	If a feature isn't ready for users but you need to merge increments:
145
146	```ty

People who liked this also viewed

6 picks

Type