incremental-implementation

Name: incremental-implementation
Author: pimenov

20stars2forks

How to install incremental-implementation?

pimenov/codex-first-skills-pack/incremental-implementation

$npx -y skills add pimenov/codex-first-skills-pack --skill incremental-implementation

Installs into the current project.

Summary

Breaks large or multi-file implementation work into small verified slices that keep the project working after each step. Use when building a feature, bugfix, refactor, migration, integration, UI flow, or operational change that could become a large diff; when more than one file/m

Files · 1

View on GitHub

SKILL.md

1	# Incremental Implementation
2
3	## Overview
4
5	Build in small complete slices. Each slice should have a clear purpose, a bounded file set, a focused verification step, and a checkpoint before moving on.
6
7	This skill turns "do the whole thing" into "make one safe step true, prove it, then continue."
8
9	When the user asks to work in small verified steps, explicitly name this skill before planning or editing. The behavior is not enough; the user should be able to see that the slice gate is active.
10
11	## Relationship To Other Skills
12
13	- Use `context-engineering` first when the right slice boundary depends on project structure or source of truth.
14	- Use `test-driven-development` for behavior-sensitive slices where a failing check should come first.
15	- Use `debugging-and-error-recovery` when a slice fails unexpectedly.
16	- Use `code-review-and-quality` before calling a multi-slice change done.
17	- Use `doubt-driven-review` before risky production, auth, data, migration, or irreversible steps.
18	- Use `source-driven-development` when a slice depends on current framework, SDK, API, CLI, or platform behavior.
19
20	## Do Not Use
21
22	- Tiny one-file changes where the scope is already smaller than a slice.
23	- Pure documentation or copy edits with no implementation risk.
24	- Mechanical formatting changes that should be one bounded operation.
25	- Emergency rollback or incident stabilization where the first priority is restore-safe-state.
26	- Cases where slicing would hide a required atomic change, such as a schema and code deploy that must ship together.
27
28	## Core Loop
29
30	```text
31	PLAN SLICE -> IMPLEMENT -> VERIFY -> CHECKPOINT -> NEXT SLICE
32	```
33
34	### 1. PLAN SLICE: Choose The Smallest Useful Step
35
36	Before editing, define:
37
38	- current target outcome;
39	- what is in this slice;
40	- what is explicitly out of scope;
41	- files or modules likely touched;
42	- proof for this slice;
43	- rollback or stop-line if it fails.
44
45	Good slice shapes:
46
47	- one end-to-end vertical path;
48	- one contract/type/interface before consumers;
49	- one risky unknown proven with a spike or focused check;
50	- one bug reproduction plus fix;
51	- one mechanical move before behavior changes;
52	- one UI state or route before the whole flow.
53
54	Bad slice shapes:
55
56	- "update backend, frontend, tests, copy, config, and cleanup";
57	- "refactor while adding the feature";
58	- "touch every nearby file while I am here";
59	- "implement everything, then see if it builds."
60
61	### 2. IMPLEMENT: Keep The Change Narrow
62
63	Within a slice:
64
65	- edit only files needed for that slice;
66	- prefer the simplest implementation that satisfies the slice;
67	- avoid speculative abstractions;
68	- do not modernize or clean adjacent code unless it is required;
69	- keep behavior changes separate from mechanical refactors;
70	- keep incomplete user-visible work hidden behind a safe default or feature flag when needed.
71
72	If the slice expands while coding, stop and split it instead of silently widening scope.
73
74	### 3. VERIFY: Prove The Slice
75
76	Run the smallest useful check first:
77
78	- focused unit/integration/component test;
79	- typecheck or build for touched stack;
80	- lint only when relevant to touched files;
81	- browser/manual smoke for UI behavior;
82	- dry-run or read-only smoke for operational work.
83
84	Then widen checks only when the blast radius justifies it.
85
86	Do not rerun the same expensive command repeatedly on unchanged code. Rerun after meaningful edits.
87
88	### 4. CHECKPOINT: Preserve A Safe Boundary
89
90	After a verified slice, leave a clear recovery point.
91
92	In git repositories:
93
94	- inspect `git status --short`;
95	- review the diff for only this slice;
96	- stage explicit files only when committing;
97	- commit only when the user asked for commits or the repo workflow makes it clearly appropriate;
98	- never auto-commit secrets, generated noise, unrelated user changes, or dirty-tree leftovers.
99
100	Outside git or when not committing:
101
102	- summarize the slice in chat or `SESSION_NOTES.md` when durable tracking matters;
103	- name files changed and checks run;
104	- record remaining slices and stop-lines;
105	- leave temporary/debug artifacts cleaned up unless intentionally saved as evidence.
106
107	Checkpoint does not always mean commit. It means the next step starts from a known state.
108
109	### 5. NEXT SLICE: Continue Or Stop Deliberately
110
111	Continue only if:
112
113	- the last slice is verified or its gap is explicitly accepted;
114	- the next slice has a clear scope;
115	- no new approval gate appeared;
116	- the workspace is sti

People who liked this also viewed

6 picks

Type

incremental-implementation

20stars2forks

View on GitHub

How to install incremental-implementation?

pimenov/codex-first-skills-pack/incremental-implementation

$npx -y skills add pimenov/codex-first-skills-pack --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 small complete slices. Each slice should have a clear purpose, a bounded file set, a focused verification step, and a checkpoint before moving on.
6
7	This skill turns "do the whole thing" into "make one safe step true, prove it, then continue."
8
9	When the user asks to work in small verified steps, explicitly name this skill before planning or editing. The behavior is not enough; the user should be able to see that the slice gate is active.
10
11	## Relationship To Other Skills
12
13	- Use `context-engineering` first when the right slice boundary depends on project structure or source of truth.
14	- Use `test-driven-development` for behavior-sensitive slices where a failing check should come first.
15	- Use `debugging-and-error-recovery` when a slice fails unexpectedly.
16	- Use `code-review-and-quality` before calling a multi-slice change done.
17	- Use `doubt-driven-review` before risky production, auth, data, migration, or irreversible steps.
18	- Use `source-driven-development` when a slice depends on current framework, SDK, API, CLI, or platform behavior.
19
20	## Do Not Use
21
22	- Tiny one-file changes where the scope is already smaller than a slice.
23	- Pure documentation or copy edits with no implementation risk.
24	- Mechanical formatting changes that should be one bounded operation.
25	- Emergency rollback or incident stabilization where the first priority is restore-safe-state.
26	- Cases where slicing would hide a required atomic change, such as a schema and code deploy that must ship together.
27
28	## Core Loop
29
30	```text
31	PLAN SLICE -> IMPLEMENT -> VERIFY -> CHECKPOINT -> NEXT SLICE
32	```
33
34	### 1. PLAN SLICE: Choose The Smallest Useful Step
35
36	Before editing, define:
37
38	- current target outcome;
39	- what is in this slice;
40	- what is explicitly out of scope;
41	- files or modules likely touched;
42	- proof for this slice;
43	- rollback or stop-line if it fails.
44
45	Good slice shapes:
46
47	- one end-to-end vertical path;
48	- one contract/type/interface before consumers;
49	- one risky unknown proven with a spike or focused check;
50	- one bug reproduction plus fix;
51	- one mechanical move before behavior changes;
52	- one UI state or route before the whole flow.
53
54	Bad slice shapes:
55
56	- "update backend, frontend, tests, copy, config, and cleanup";
57	- "refactor while adding the feature";
58	- "touch every nearby file while I am here";
59	- "implement everything, then see if it builds."
60
61	### 2. IMPLEMENT: Keep The Change Narrow
62
63	Within a slice:
64
65	- edit only files needed for that slice;
66	- prefer the simplest implementation that satisfies the slice;
67	- avoid speculative abstractions;
68	- do not modernize or clean adjacent code unless it is required;
69	- keep behavior changes separate from mechanical refactors;
70	- keep incomplete user-visible work hidden behind a safe default or feature flag when needed.
71
72	If the slice expands while coding, stop and split it instead of silently widening scope.
73
74	### 3. VERIFY: Prove The Slice
75
76	Run the smallest useful check first:
77
78	- focused unit/integration/component test;
79	- typecheck or build for touched stack;
80	- lint only when relevant to touched files;
81	- browser/manual smoke for UI behavior;
82	- dry-run or read-only smoke for operational work.
83
84	Then widen checks only when the blast radius justifies it.
85
86	Do not rerun the same expensive command repeatedly on unchanged code. Rerun after meaningful edits.
87
88	### 4. CHECKPOINT: Preserve A Safe Boundary
89
90	After a verified slice, leave a clear recovery point.
91
92	In git repositories:
93
94	- inspect `git status --short`;
95	- review the diff for only this slice;
96	- stage explicit files only when committing;
97	- commit only when the user asked for commits or the repo workflow makes it clearly appropriate;
98	- never auto-commit secrets, generated noise, unrelated user changes, or dirty-tree leftovers.
99
100	Outside git or when not committing:
101
102	- summarize the slice in chat or `SESSION_NOTES.md` when durable tracking matters;
103	- name files changed and checks run;
104	- record remaining slices and stop-lines;
105	- leave temporary/debug artifacts cleaned up unless intentionally saved as evidence.
106
107	Checkpoint does not always mean commit. It means the next step starts from a known state.
108
109	### 5. NEXT SLICE: Continue Or Stop Deliberately
110
111	Continue only if:
112
113	- the last slice is verified or its gap is explicitly accepted;
114	- the next slice has a clear scope;
115	- no new approval gate appeared;
116	- the workspace is sti

People who liked this also viewed

6 picks

Type