incremental-implementation

Name: incremental-implementation
Author: jmxt3

32stars3forks

How to install incremental-implementation?

jmxt3/gitscape.ai/incremental-implementation

$npx -y skills add jmxt3/gitscape.ai --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	Ship thin vertical slices: implement, test, verify, commit — one task at a time. Never write a large batch of changes all at once. Each increment should leave the system in a working, deployable state. This protects against regressions, makes reviews easier, and provides clean rollback points.
6
7	## When to Use
8
9	- Any change touching more than one file
10	- Implementing a task from an existing plan
11	- When you're tempted to "just write it all out first and then test"
12	- Any feature that takes more than one focused session to implement
13
14	When NOT to use: Single-line typo fixes or isolated config changes with no behavior impact.
15
16	## The Increment Loop
17
18	For every task, follow this exact loop:
19
20	### 1. Read Before Writing
21
22	- Read the task's acceptance criteria
23	- Load the relevant existing code (the files this task touches)
24	- Identify the pattern being extended, not invented
25	- Confirm the approach matches the spec
26
27	Stop if: The approach differs significantly from the spec. Update the spec or plan first.
28
29	### 2. Write a Failing Test (RED)
30
31	Write a test that describes the expected behavior. The test must fail before you write any implementation code.
32
33	```python
34	# Example for a FastAPI endpoint
35	def test_export_skill_returns_zip():
36	"""Skill export endpoint should return a valid zip file."""
37	response = client.post("/api/skills/export", json={"repo": "owner/repo"})
38	assert response.status_code == 200
39	assert response.headers["content-type"] == "application/zip"
40	```
41
42	If the test passes before you write the implementation, the test is wrong. Fix it.
43
44	### 3. Implement the Minimum (GREEN)
45
46	Write only the code needed to make the test pass. No more, no less.
47
48	- Follow existing patterns in the codebase
49	- No premature abstractions
50	- No "while I'm here" refactors
51	- No adding features that aren't in the acceptance criteria
52
53	### 4. Run All Tests
54
55	```bash
56	pytest tests/ -v # full suite
57	pytest tests/ -k "test_name" # targeted run for the new test
58	```
59
60	All existing tests must pass. If they don't, fix the regression before proceeding.
61
62	### 5. Build Check
63
64	Ensure the project builds/compiles cleanly:
65	```bash
66	# Python: check imports resolve
67	python -c "from api.app import create_app"
68	# TypeScript/JS: type check
69	npx tsc --noEmit
70	```
71
72	### 6. Commit
73
74	One commit per task. Stage only the files that task touched:
75
76	```bash
77	git add api/app/path/to/changed_file.py tests/test_changed.py
78	git commit -m "feat(skills): add zip export endpoint for skill download
79
80	- POST /api/skills/export accepts {repo: string}
81	- Returns application/zip with SKILL.md and supporting files
82	- Validates repo exists before building archive
83
84	Closes #42"
85	```
86
87	Never `git add -A` blindly — it absorbs unrelated local work and breaks clean rollback.
88
89	### 7. Mark the Task Complete and Stop
90
91	Update the task list and stop. Do not immediately start the next task. Present the result for human review if the task was Medium or larger.
92
93	## Feature Flags
94
95	For high-risk changes that must be deployed before they are activated:
96
97	```python
98	# api/app/config.py
99	FEATURE_FLAGS = {
100	"skill_hd_tier": os.getenv("FF_SKILL_HD_TIER", "false").lower() == "true",
101	}
102
103	# Usage
104	if settings.FEATURE_FLAGS["skill_hd_tier"]:
105	return generate_hd_skill(repo)
106	else:
107	return generate_standard_skill(repo)
108	```
109
110	Deploy with `FF_SKILL_HD_TIER=false`, enable via env var when ready.
111
112	## Safe Defaults
113
114	When adding new behavior, default to the current behavior and opt into new behavior:
115
116	```python
117	# BAD: new behavior is default, breaks existing users
118	def generate_skill(repo, format="enhanced"):
119	...
120
121	# GOOD: existing behavior is default
122	def generate_skill(repo, format="standard"):
123	if format == "enhanced" and feature_flags.hd_tier:
124	return _generate_enhanced(repo)
125	return _generate_standard(repo)
126	```
127
128	## Rollback-Friendly Changes
129
130	Every commit should be revertable with `git revert` without taking down the system:
131
132	- Never combine schema changes with behavior changes in one commit
133	- Never remove a field that other services still read — add the replacement first, migrate, then remove
134	- Database migrations go in their own commit, run before the code that depends on them
135
136	## Common Rationalizations
137
138	\| Rationalization \| Reality \|
139	\|---\|---\|
140	\| "I'll test at the end when it's all done" \| By then, failures are hard to localize. Test each slice so failures are obvious. \|
141	\| "The test is trivial for this part" \| Write it anyway. Trivial tests catch trivial regressions. \|
142	\| "I can see how it fits together — just let me write it all" \| You'll produce a 400-line diff that no one can review, with a bug buried on line 312. \|
143	\| "Refactoring this first will make the feat

People who liked this also viewed

6 picks

Type

incremental-implementation

32stars3forks

View on GitHub

How to install incremental-implementation?

jmxt3/gitscape.ai/incremental-implementation

$npx -y skills add jmxt3/gitscape.ai --skill incremental-implementation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Incremental Implementation
2
3	## Overview
4
5	Ship thin vertical slices: implement, test, verify, commit — one task at a time. Never write a large batch of changes all at once. Each increment should leave the system in a working, deployable state. This protects against regressions, makes reviews easier, and provides clean rollback points.
6
7	## When to Use
8
9	- Any change touching more than one file
10	- Implementing a task from an existing plan
11	- When you're tempted to "just write it all out first and then test"
12	- Any feature that takes more than one focused session to implement
13
14	When NOT to use: Single-line typo fixes or isolated config changes with no behavior impact.
15
16	## The Increment Loop
17
18	For every task, follow this exact loop:
19
20	### 1. Read Before Writing
21
22	- Read the task's acceptance criteria
23	- Load the relevant existing code (the files this task touches)
24	- Identify the pattern being extended, not invented
25	- Confirm the approach matches the spec
26
27	Stop if: The approach differs significantly from the spec. Update the spec or plan first.
28
29	### 2. Write a Failing Test (RED)
30
31	Write a test that describes the expected behavior. The test must fail before you write any implementation code.
32
33	```python
34	# Example for a FastAPI endpoint
35	def test_export_skill_returns_zip():
36	"""Skill export endpoint should return a valid zip file."""
37	response = client.post("/api/skills/export", json={"repo": "owner/repo"})
38	assert response.status_code == 200
39	assert response.headers["content-type"] == "application/zip"
40	```
41
42	If the test passes before you write the implementation, the test is wrong. Fix it.
43
44	### 3. Implement the Minimum (GREEN)
45
46	Write only the code needed to make the test pass. No more, no less.
47
48	- Follow existing patterns in the codebase
49	- No premature abstractions
50	- No "while I'm here" refactors
51	- No adding features that aren't in the acceptance criteria
52
53	### 4. Run All Tests
54
55	```bash
56	pytest tests/ -v # full suite
57	pytest tests/ -k "test_name" # targeted run for the new test
58	```
59
60	All existing tests must pass. If they don't, fix the regression before proceeding.
61
62	### 5. Build Check
63
64	Ensure the project builds/compiles cleanly:
65	```bash
66	# Python: check imports resolve
67	python -c "from api.app import create_app"
68	# TypeScript/JS: type check
69	npx tsc --noEmit
70	```
71
72	### 6. Commit
73
74	One commit per task. Stage only the files that task touched:
75
76	```bash
77	git add api/app/path/to/changed_file.py tests/test_changed.py
78	git commit -m "feat(skills): add zip export endpoint for skill download
79
80	- POST /api/skills/export accepts {repo: string}
81	- Returns application/zip with SKILL.md and supporting files
82	- Validates repo exists before building archive
83
84	Closes #42"
85	```
86
87	Never `git add -A` blindly — it absorbs unrelated local work and breaks clean rollback.
88
89	### 7. Mark the Task Complete and Stop
90
91	Update the task list and stop. Do not immediately start the next task. Present the result for human review if the task was Medium or larger.
92
93	## Feature Flags
94
95	For high-risk changes that must be deployed before they are activated:
96
97	```python
98	# api/app/config.py
99	FEATURE_FLAGS = {
100	"skill_hd_tier": os.getenv("FF_SKILL_HD_TIER", "false").lower() == "true",
101	}
102
103	# Usage
104	if settings.FEATURE_FLAGS["skill_hd_tier"]:
105	return generate_hd_skill(repo)
106	else:
107	return generate_standard_skill(repo)
108	```
109
110	Deploy with `FF_SKILL_HD_TIER=false`, enable via env var when ready.
111
112	## Safe Defaults
113
114	When adding new behavior, default to the current behavior and opt into new behavior:
115
116	```python
117	# BAD: new behavior is default, breaks existing users
118	def generate_skill(repo, format="enhanced"):
119	...
120
121	# GOOD: existing behavior is default
122	def generate_skill(repo, format="standard"):
123	if format == "enhanced" and feature_flags.hd_tier:
124	return _generate_enhanced(repo)
125	return _generate_standard(repo)
126	```
127
128	## Rollback-Friendly Changes
129
130	Every commit should be revertable with `git revert` without taking down the system:
131
132	- Never combine schema changes with behavior changes in one commit
133	- Never remove a field that other services still read — add the replacement first, migrate, then remove
134	- Database migrations go in their own commit, run before the code that depends on them
135
136	## Common Rationalizations
137
138	\| Rationalization \| Reality \|
139	\|---\|---\|
140	\| "I'll test at the end when it's all done" \| By then, failures are hard to localize. Test each slice so failures are obvious. \|
141	\| "The test is trivial for this part" \| Write it anyway. Trivial tests catch trivial regressions. \|
142	\| "I can see how it fits together — just let me write it all" \| You'll produce a 400-line diff that no one can review, with a bug buried on line 312. \|
143	\| "Refactoring this first will make the feat

People who liked this also viewed

6 picks

Type