incremental-delivery

Name: incremental-delivery
Author: UnpaidAttention

84stars18forks

How to install incremental-delivery?

unpaidattention/fable5-methodology/incremental-delivery

$npx -y skills add UnpaidAttention/fable5-methodology --skill incremental-delivery

Installs into the current project.

Summary

Build large multi-part deliverables — multi-file projects, migrations, long documents, N-of-the-same-thing work — in verified increments with dependency ordering, checkpoints, a running state note, and consistency sweeps. Trigger this when a task will produce 3+ files, spans more

Files · 1

View on GitHub

SKILL.md

1	# Incremental Delivery
2
3	Never "write everything, then test everything" — that strategy converts N independent small
4	bugs into one entangled debugging session at the end. Small verified steps beat large
5	unverified strides even when the stride looks 20% faster; something always goes wrong.
6
7	## Step 1: Order the units
8
9	1. Dependency order: shared types/schemas → pure logic → I/O adapters → interfaces
10	(API/CLI/UI) → integration glue. Consumers are written after the things they consume exist
11	and are verified.
12	2. Risk first within that order: the unfamiliar API, the format never parsed, the
13	algorithm you're unsure of — prove it in isolation before the plan depends on it. If it
14	fails, the plan changes while changing is cheap.
15	3. Pattern before replication: building N similar things? Build ONE end-to-end, verify it,
16	THEN replicate. A flaw in the pattern costs 1× to fix before replication and N× after.
17
18	## Step 2: Checkpoint after every unit
19
20	1. After each coherent unit, run the fastest available check: compile, import, unit test, or a
21	smoke run. Never stack a second untested layer on a first.
22	2. In a git repo, commit (or otherwise mark) each known-good point so revert has a target.
23	3. If a unit balloons mid-way: split it, checkpoint the finished half. Do not power through to
24	a distant checkpoint.
25
26	## Step 3: Maintain the state note
27
28	On any task long enough to survive a session break (or that another model might resume), keep
29	a running note — a scratch file or persistent todo — containing:
30
31	- Units done / units remaining (the ordered list, checked off).
32	- Decisions later units must honor: naming scheme, error envelope shape, ID types, field
33	formats — recorded the moment they're made.
34	- Open questions and assumptions so far.
35	- The exact next action, written for a cold reader.
36
37	Consult the note BEFORE starting each new unit — your memory of a decision made 8 units ago
38	has drifted; the note hasn't. Write it as if a different, colder model will resume from it,
39	because one might.
40
41	## Step 4: Propagate interface changes immediately
42
43	When unit 7 forces a change to unit 2's interface (renamed field, new parameter, changed
44	return shape):
45
46	1. Grep for EVERY consumer of the old interface — do not fix only the ones you remember.
47	2. Propagate the change to all of them NOW, not "after finishing unit 7".
48	3. Re-run the earlier units' checks. Deferred propagation is how half-renamed codebases happen.
49
50	## Step 5: Final consistency sweep
51
52	After the last unit, one deliberate pass over the WHOLE deliverable:
53
54	- Same naming conventions from first file to last? (Early files follow the original plan;
55	late files follow how the plan evolved — reconcile them.)
56	- Same error format / response envelope / logging shape everywhere?
57	- Do early sections still accurately describe what later sections actually do? Documents
58	drift exactly like code.
59	- Re-read the ORIGINAL request one final time and check every stated requirement and process
60	instruction against the finished whole — long tasks decay instructions silently.
61
62	## Checklist per unit
63
64	- [ ] Consulted the state note before starting?
65	- [ ] Unit's own check run and passing?
66	- [ ] Any new cross-cutting decision recorded in the note?
67	- [ ] Any interface change propagated to ALL existing consumers and their checks re-run?
68	- [ ] State note updated (done list, next action)?
69
70	## Worked example
71
72	Task: build a CLI tool with 5 subcommands reading a config, calling an API, and writing
73	reports.
74
75	- Order: (1) config loader + types [everything consumes it], (2) API client for ONE endpoint —
76	riskiest, unfamiliar API — proven with a live smoke call, (3) first subcommand end-to-end
77	[the pattern], (4–6) remaining subcommands [replication], (7) shared `--help`/error polish.
78	- Checkpoint: after unit 2, the smoke call reveals the API paginates — recorded in the note:
79	"all list endpoints must paginate; client returns iterators, not lists." Units 3–6 honor it;
80	without the note, subcommand 5 (written hours later) would have returned truncated lists.
81	- Unit 4 renames a config field for clarity → grep finds 3 consumers (units 1, 3, and a test);
82	all updated in the same edit session; unit-1 and unit-3 tests re-run green.
83	- Sweep: subcommands 3 and 6 format

People who liked this also viewed

6 picks

Type

incremental-delivery

84stars18forks

View on GitHub

How to install incremental-delivery?

unpaidattention/fable5-methodology/incremental-delivery

$npx -y skills add UnpaidAttention/fable5-methodology --skill incremental-delivery

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Incremental Delivery
2
3	Never "write everything, then test everything" — that strategy converts N independent small
4	bugs into one entangled debugging session at the end. Small verified steps beat large
5	unverified strides even when the stride looks 20% faster; something always goes wrong.
6
7	## Step 1: Order the units
8
9	1. Dependency order: shared types/schemas → pure logic → I/O adapters → interfaces
10	(API/CLI/UI) → integration glue. Consumers are written after the things they consume exist
11	and are verified.
12	2. Risk first within that order: the unfamiliar API, the format never parsed, the
13	algorithm you're unsure of — prove it in isolation before the plan depends on it. If it
14	fails, the plan changes while changing is cheap.
15	3. Pattern before replication: building N similar things? Build ONE end-to-end, verify it,
16	THEN replicate. A flaw in the pattern costs 1× to fix before replication and N× after.
17
18	## Step 2: Checkpoint after every unit
19
20	1. After each coherent unit, run the fastest available check: compile, import, unit test, or a
21	smoke run. Never stack a second untested layer on a first.
22	2. In a git repo, commit (or otherwise mark) each known-good point so revert has a target.
23	3. If a unit balloons mid-way: split it, checkpoint the finished half. Do not power through to
24	a distant checkpoint.
25
26	## Step 3: Maintain the state note
27
28	On any task long enough to survive a session break (or that another model might resume), keep
29	a running note — a scratch file or persistent todo — containing:
30
31	- Units done / units remaining (the ordered list, checked off).
32	- Decisions later units must honor: naming scheme, error envelope shape, ID types, field
33	formats — recorded the moment they're made.
34	- Open questions and assumptions so far.
35	- The exact next action, written for a cold reader.
36
37	Consult the note BEFORE starting each new unit — your memory of a decision made 8 units ago
38	has drifted; the note hasn't. Write it as if a different, colder model will resume from it,
39	because one might.
40
41	## Step 4: Propagate interface changes immediately
42
43	When unit 7 forces a change to unit 2's interface (renamed field, new parameter, changed
44	return shape):
45
46	1. Grep for EVERY consumer of the old interface — do not fix only the ones you remember.
47	2. Propagate the change to all of them NOW, not "after finishing unit 7".
48	3. Re-run the earlier units' checks. Deferred propagation is how half-renamed codebases happen.
49
50	## Step 5: Final consistency sweep
51
52	After the last unit, one deliberate pass over the WHOLE deliverable:
53
54	- Same naming conventions from first file to last? (Early files follow the original plan;
55	late files follow how the plan evolved — reconcile them.)
56	- Same error format / response envelope / logging shape everywhere?
57	- Do early sections still accurately describe what later sections actually do? Documents
58	drift exactly like code.
59	- Re-read the ORIGINAL request one final time and check every stated requirement and process
60	instruction against the finished whole — long tasks decay instructions silently.
61
62	## Checklist per unit
63
64	- [ ] Consulted the state note before starting?
65	- [ ] Unit's own check run and passing?
66	- [ ] Any new cross-cutting decision recorded in the note?
67	- [ ] Any interface change propagated to ALL existing consumers and their checks re-run?
68	- [ ] State note updated (done list, next action)?
69
70	## Worked example
71
72	Task: build a CLI tool with 5 subcommands reading a config, calling an API, and writing
73	reports.
74
75	- Order: (1) config loader + types [everything consumes it], (2) API client for ONE endpoint —
76	riskiest, unfamiliar API — proven with a live smoke call, (3) first subcommand end-to-end
77	[the pattern], (4–6) remaining subcommands [replication], (7) shared `--help`/error polish.
78	- Checkpoint: after unit 2, the smoke call reveals the API paginates — recorded in the note:
79	"all list endpoints must paginate; client returns iterators, not lists." Units 3–6 honor it;
80	without the note, subcommand 5 (written hours later) would have returned truncated lists.
81	- Unit 4 renames a config field for clarity → grep finds 3 consumers (units 1, 3, and a test);
82	all updated in the same edit session; unit-1 and unit-3 tests re-run green.
83	- Sweep: subcommands 3 and 6 format

People who liked this also viewed

6 picks

Type