feature-list-json

Name: feature-list-json
Author: Archive228

712stars129forks

How to install feature-list-json?

archive228/loopkit/feature-list-json

$npx -y skills add Archive228/loopkit --skill feature-list-json

Installs into the current project.

Summary

Enumerate every end-to-end feature as strict JSON entries with passes:false, editable-passes-only discipline, and priority order. The ledger fresh-context sessions read to know what's done, what's next, and what they're forbidden to touch.

Files · 1

View on GitHub

SKILL.md

1	# feature_list.json
2
3	The ledger of every feature the product will eventually have. Fresh-context sessions read it to pick work; they flip exactly one boolean when done. JSON, not Markdown — the syntactic strictness is load-bearing. Prose gets edited freely; data gets edited carefully.
4
5	Format per entry:
6
7	```json
8	{
9	"category": "functional",
10	"description": "New chat button creates a fresh conversation",
11	"steps": [
12	"Navigate to main interface",
13	"Click the 'New Chat' button",
14	"Verify a new conversation is created",
15	"Check that chat area shows welcome state",
16	"Verify conversation appears in sidebar"
17	],
18	"passes": false
19	}
20	```
21
22	Categories: `functional`, `ux`, `data`, `infra`. Order the array in implementation order — the top is the next thing to build.
23
24	## When to apply
25
26	- Initializer agent at scaffold time: produce the full list, every entry `passes: false`. Aim for breadth — 200 well-scoped entries beats 30 vague ones.
27	- Coding agent at end of session: after end-to-end verification, flip exactly one `passes` from `false` to `true`.
28	- Any session at start: `jq '[.[] \| select(.passes==false)] \| length'` to see remaining work; pick the topmost unblocked entry.
29
30	## Procedure — initializer
31
32	1. Enumerate every user-observable behavior the spec implies. Login, list rendering, empty states, error states, keyboard shortcuts, mobile layout — all of it.
33	2. Write each as one entry. `description` is one sentence, `steps` is a user's actual action sequence (not implementation notes).
34	3. Order the array so an agent walking top-to-bottom builds prerequisites before dependents.
35	4. Every `passes` starts `false`. No exceptions, not even for the smoke test.
36	5. Validate: `jq '. \| length'` returns your count; `jq '[.[] \| select(.passes==true)] \| length'` returns 0.
37
38	## Procedure — coding agent
39
40	1. Read the file. Do not edit yet.
41	2. Pick the topmost entry with `passes: false` and satisfied prerequisites. If the top is blocked, drop to the deepest unblocked entry.
42	3. Implement. Test. Verify end-to-end via the runtime path (browser automation, HTTP, CLI) — not unit tests alone. See [[broken-window-check]] for what E2E means.
43	4. Only after E2E green: flip that single entry's `passes` to `true`.
44	5. Diff the file. The diff must be exactly one `false` → `true`. Nothing else.
45
46	## Anti-patterns
47
48	- Editing `description`, `steps`, or `category` — it is unacceptable to remove or edit these fields because it lets missing functionality slip past future sessions. The ledger is append-only in every field except `passes`.
49	- Flipping `passes: true` on unit-test evidence — unit tests pass while routes are misrouted, CORS is broken, or the button is unwired. Only end-to-end evidence flips the bit. See [[verification-before-completion]].
50	- Flipping multiple entries in one session — the single-feature-per-session rule (see [[one-feature-per-session]]) exists because packed sessions ship everything half-done. One flip per session.
51	- Adding new entries mid-project without spec change — if scope grew, note it in [[shift-notes]] and flag for a re-scope, don't quietly extend the ledger.
52	- Deleting "obsolete" entries — if a feature is no longer needed, leave it and mark it `passes: true` with a note, or negotiate removal explicitly. Silent deletion breaks priority counting.
53	- Markdown or YAML instead of JSON — measured in shift-work agent runs, JSON cuts spurious field edits ~7x vs. Markdown and premature-pass marking ~2x. The strictness does the work.
54
55	## Audit check
56
57	At session end, before committing:
58
59	```bash
60	git diff feature_list.json \| grep -E '^[-+]' \| grep -v 'passes'
61	```
62
63	If this prints anything other than the file header, you edited a forbidden field. Revert those hunks. Only `"passes": false` ↔ `"passes": true` lines are allowed to change.
64
65	## When NOT to apply
66
67	- Projects under ~20 features — the overhead of writing the list exceeds the benefit; a flat TODO in [[shift-notes]] is enough.
68	- Solo one-shot sessions with no handoff — the ledger's whole purpose is cross-session discipline.
69
70	## Related
71
72	- [[shift-notes]] — the prose companion; feature_list.json holds state, shift-notes holds context.
73	- [[broken-window-check]] — what "end-to-end verified" means before you flip a bit.
74	- [[one-feature-per-session]] — the rule that limits you to one flip per session.
75	- [[verification-before-completion]] — the general form of "no bit-flip without runtime evidence".

People who liked this also viewed

6 picks

Type

feature-list-json

712stars129forks

View on GitHub

How to install feature-list-json?

archive228/loopkit/feature-list-json

$npx -y skills add Archive228/loopkit --skill feature-list-json

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# feature_list.json
2
3	The ledger of every feature the product will eventually have. Fresh-context sessions read it to pick work; they flip exactly one boolean when done. JSON, not Markdown — the syntactic strictness is load-bearing. Prose gets edited freely; data gets edited carefully.
4
5	Format per entry:
6
7	```json
8	{
9	"category": "functional",
10	"description": "New chat button creates a fresh conversation",
11	"steps": [
12	"Navigate to main interface",
13	"Click the 'New Chat' button",
14	"Verify a new conversation is created",
15	"Check that chat area shows welcome state",
16	"Verify conversation appears in sidebar"
17	],
18	"passes": false
19	}
20	```
21
22	Categories: `functional`, `ux`, `data`, `infra`. Order the array in implementation order — the top is the next thing to build.
23
24	## When to apply
25
26	- Initializer agent at scaffold time: produce the full list, every entry `passes: false`. Aim for breadth — 200 well-scoped entries beats 30 vague ones.
27	- Coding agent at end of session: after end-to-end verification, flip exactly one `passes` from `false` to `true`.
28	- Any session at start: `jq '[.[] \| select(.passes==false)] \| length'` to see remaining work; pick the topmost unblocked entry.
29
30	## Procedure — initializer
31
32	1. Enumerate every user-observable behavior the spec implies. Login, list rendering, empty states, error states, keyboard shortcuts, mobile layout — all of it.
33	2. Write each as one entry. `description` is one sentence, `steps` is a user's actual action sequence (not implementation notes).
34	3. Order the array so an agent walking top-to-bottom builds prerequisites before dependents.
35	4. Every `passes` starts `false`. No exceptions, not even for the smoke test.
36	5. Validate: `jq '. \| length'` returns your count; `jq '[.[] \| select(.passes==true)] \| length'` returns 0.
37
38	## Procedure — coding agent
39
40	1. Read the file. Do not edit yet.
41	2. Pick the topmost entry with `passes: false` and satisfied prerequisites. If the top is blocked, drop to the deepest unblocked entry.
42	3. Implement. Test. Verify end-to-end via the runtime path (browser automation, HTTP, CLI) — not unit tests alone. See [[broken-window-check]] for what E2E means.
43	4. Only after E2E green: flip that single entry's `passes` to `true`.
44	5. Diff the file. The diff must be exactly one `false` → `true`. Nothing else.
45
46	## Anti-patterns
47
48	- Editing `description`, `steps`, or `category` — it is unacceptable to remove or edit these fields because it lets missing functionality slip past future sessions. The ledger is append-only in every field except `passes`.
49	- Flipping `passes: true` on unit-test evidence — unit tests pass while routes are misrouted, CORS is broken, or the button is unwired. Only end-to-end evidence flips the bit. See [[verification-before-completion]].
50	- Flipping multiple entries in one session — the single-feature-per-session rule (see [[one-feature-per-session]]) exists because packed sessions ship everything half-done. One flip per session.
51	- Adding new entries mid-project without spec change — if scope grew, note it in [[shift-notes]] and flag for a re-scope, don't quietly extend the ledger.
52	- Deleting "obsolete" entries — if a feature is no longer needed, leave it and mark it `passes: true` with a note, or negotiate removal explicitly. Silent deletion breaks priority counting.
53	- Markdown or YAML instead of JSON — measured in shift-work agent runs, JSON cuts spurious field edits ~7x vs. Markdown and premature-pass marking ~2x. The strictness does the work.
54
55	## Audit check
56
57	At session end, before committing:
58
59	```bash
60	git diff feature_list.json \| grep -E '^[-+]' \| grep -v 'passes'
61	```
62
63	If this prints anything other than the file header, you edited a forbidden field. Revert those hunks. Only `"passes": false` ↔ `"passes": true` lines are allowed to change.
64
65	## When NOT to apply
66
67	- Projects under ~20 features — the overhead of writing the list exceeds the benefit; a flat TODO in [[shift-notes]] is enough.
68	- Solo one-shot sessions with no handoff — the ledger's whole purpose is cross-session discipline.
69
70	## Related
71
72	- [[shift-notes]] — the prose companion; feature_list.json holds state, shift-notes holds context.
73	- [[broken-window-check]] — what "end-to-end verified" means before you flip a bit.
74	- [[one-feature-per-session]] — the rule that limits you to one flip per session.
75	- [[verification-before-completion]] — the general form of "no bit-flip without runtime evidence".

People who liked this also viewed

6 picks

Type