@erclx/aitk 0.61.0 → 0.62.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "aitk",
3
3
  "description": "Automated governance, versioning, and discovery tools for Claude Code.",
4
- "version": "0.61.0",
4
+ "version": "0.62.1",
5
5
  "author": {
6
6
  "name": "Eric Le",
7
7
  "url": "https://github.com/erclx"
@@ -60,38 +60,10 @@ git fetch origin main
60
60
  git merge-tree --write-tree origin/main HEAD
61
61
  ```
62
62
 
63
- A zero exit means the branch still merges. Skip to step 6. A non-zero exit means
64
- it does not. Stash the fixes first when `git status --porcelain` reports
65
- anything, since a rebase refuses to run over a dirty tree, then rebase onto
66
- `origin/main` and restore them:
67
-
68
- ```bash
69
- git stash push -u
70
- git rebase origin/main
71
- git stash pop
72
- ```
73
-
74
- Pop only when the stash ran. On a clean tree, which is what a run whose findings
75
- were all conscious-accepts leaves behind, `git stash push` saves nothing and
76
- exits zero, so the pop restores an unrelated entry from an earlier session.
77
-
78
- Never merge `main` into the branch. The repository squash-merges, so a merge
79
- commit here reads as noise on the pull request.
80
-
81
- Resolve every conflict under these rules, which apply to a hunk from the rebase
82
- and a hunk from the stash pop alike:
83
-
84
- - Never take one side wholesale with `--ours` or `--theirs`. Both sides are valid content, so the drop is silent and passes every check.
85
- - Never resolve a generated file by hand. A file the project check rebuilds, such as an `index.md` carrying no `auto: false`, takes either side to clear the conflict and gets its real content from the regen below.
86
- - Where two branches wrote prose into one file, keep both sides and rewrite what the merge broke. A section that opens by counting what follows needs the count updated rather than the two versions concatenated.
87
- - When a hunk needs a decision the tree does not carry, stop rather than guessing, and name where the branch was left. The two sources recover differently. A hunk raised by the rebase takes `git rebase --abort`, which restores the old base: `❌ Conflict needs a decision at <file>. Branch left on its old base.` A hunk raised by the stash pop arrives after the rebase already landed, so no abort applies and the conflict stays in the tree: `❌ Conflict needs a decision at <file>. Branch rebased, fixes left conflicted in the tree.` A guess that compiles is the failure this stage would otherwise introduce, and either case reaches the operator as an ordinary finding on the next review pass.
88
-
89
- Both sides of every hunk sit in the conflict and `git log origin/main` names what
90
- landed, so the tree carries the context. Do not wait on the orchestrator for it.
91
-
92
- Re-run the project check after the rebase. It rebuilds the generated files and
93
- covers what the replayed commits broke, and step 6 commits the result alongside
94
- the fixes.
63
+ A zero exit means the branch still merges. Skip to step 6, which is the ordinary
64
+ run. A non-zero exit means it does not, so read
65
+ `${CLAUDE_SKILL_DIR}/references/rebase-conflicts.md` for the stash-and-rebase
66
+ sequence, the conflict resolution rules, and the check to re-run afterward.
95
67
 
96
68
  `git merge-tree` reads committed history, so this test says nothing about the
97
69
  fixes still sitting in the working tree. A branch that merges clean as committed,
@@ -118,8 +90,9 @@ with `git push --force-with-lease`, then post the reply below.
118
90
 
119
91
  Once the fixes are commits, re-run step 5's staleness test against the new head.
120
92
  A conflict that appears only now is one the fixes introduced against lines `main`
121
- moved, which the earlier test could not see. Rebase again under step 5's rules
122
- and force-push, then continue. The second push costs one extra force-push in a
93
+ moved, which the earlier test could not see. Rebase again under
94
+ `${CLAUDE_SKILL_DIR}/references/rebase-conflicts.md` and force-push, then
95
+ continue. The second push costs one extra force-push in a
123
96
  case that needs the fix and the sibling to touch the same lines.
124
97
 
125
98
  Then write a summary reply to `.claude/.tmp/address-review/reply-<number>.md`
@@ -0,0 +1,37 @@
1
+ ---
2
+ title: Rebase a stale branch
3
+ description: The stash-and-rebase sequence, the conflict resolution rules, and the two recovery messages a hunk needing a decision takes
4
+ ---
5
+
6
+ # Rebase a stale branch
7
+
8
+ Mechanics for Step 5 of `claude-address-review` once `git merge-tree` exits non-zero. A branch that still merges skips this file entirely, which is the ordinary run.
9
+
10
+ ## The sequence
11
+
12
+ Stash the fixes first when `git status --porcelain` reports anything, since a rebase refuses to run over a dirty tree, then rebase onto `origin/main` and restore them:
13
+
14
+ ```bash
15
+ git stash push -u
16
+ git rebase origin/main
17
+ git stash pop
18
+ ```
19
+
20
+ Pop only when the stash ran. On a clean tree, which is what a run whose findings were all conscious-accepts leaves behind, `git stash push` saves nothing and exits zero, so the pop restores an unrelated entry from an earlier session.
21
+
22
+ Never merge `main` into the branch. The repository squash-merges, so a merge commit here reads as noise on the pull request.
23
+
24
+ ## Resolving a conflict
25
+
26
+ These rules apply to a hunk from the rebase and a hunk from the stash pop alike:
27
+
28
+ - Never take one side wholesale with `--ours` or `--theirs`. Both sides are valid content, so the drop is silent and passes every check.
29
+ - Never resolve a generated file by hand. A file the project check rebuilds, such as an `index.md` carrying no `auto: false`, takes either side to clear the conflict and gets its real content from the regen below.
30
+ - Where two branches wrote prose into one file, keep both sides and rewrite what the merge broke. A section that opens by counting what follows needs the count updated rather than the two versions concatenated.
31
+ - When a hunk needs a decision the tree does not carry, stop rather than guessing, and name where the branch was left. The two sources recover differently. A hunk raised by the rebase takes `git rebase --abort`, which restores the old base: `❌ Conflict needs a decision at <file>. Branch left on its old base.` A hunk raised by the stash pop arrives after the rebase already landed, so no abort applies and the conflict stays in the tree: `❌ Conflict needs a decision at <file>. Branch rebased, fixes left conflicted in the tree.` A guess that compiles is the failure this stage would otherwise introduce, and either case reaches the operator as an ordinary finding on the next review pass.
32
+
33
+ Both sides of every hunk sit in the conflict and `git log origin/main` names what landed, so the tree carries the context. Do not wait on the orchestrator for it.
34
+
35
+ ## After the rebase
36
+
37
+ Re-run the project check. It rebuilds the generated files and covers what the replayed commits broke, and step 6 commits the result alongside the fixes.
@@ -107,35 +107,7 @@ Skip this step silently when `.claude/wireframes/` does not exist or has no surf
107
107
 
108
108
  Reuse the diff from the baseline above and filter for UI-affecting paths. UI-affecting paths are framework-dependent. Default heuristic: any file under a `components/`, `features/`, `pages/`, `app/`, `routes/`, or `screens/` folder, plus any `*.tsx`, `*.jsx`, `*.vue`, or `*.svelte` file anywhere in the diff.
109
109
 
110
- For each UI-affecting path, derive a candidate surface slug from the file's basename and parent folder (e.g. `web/src/features/mock/MockDemoStrip.tsx` `mock-demo-strip` or `mock`). Cross-reference against the surface files in `.claude/wireframes/`:
111
-
112
- - **Contradicted sections:** when a surface file exists for a path in the diff and the diff renames or removes a literal string that appears in the wireframe prose (e.g. provider name, button label, copy string), output a one-line report entry and stop. Do not auto-rewrite prose. Operator resolves.
113
- - **Uncovered surfaces:** when a UI-affecting path has no matching surface file by slug, write `.claude/wireframes/<slug>.md` with this stub:
114
-
115
- ```markdown
116
- ---
117
- title: <Slug as title case>
118
- description: TODO: describe the surface.
119
- ---
120
-
121
- # <Slug as title case>
122
-
123
- TODO: describe when and where this surface appears.
124
-
125
- ## Behavior
126
-
127
- - TODO
128
- ```
129
-
130
- Skip the write when the slug would collide with an existing file (different surface, same slug). Surface the collision in the report instead.
131
-
132
- Output one line per finding:
133
-
134
- - `⚠ Wireframe drift in .claude/wireframes/<surface>.md: <contradicted string>`
135
- - `📝 Stubbed: .claude/wireframes/<surface>.md`
136
- - `⚠ Slug collision: <slug> matches existing <existing-surface>.md, review and rename`
137
-
138
- If the sweep finds nothing, skip silently.
110
+ Skip silently when the filter leaves nothing, which is every branch touching no UI. Otherwise read `${CLAUDE_SKILL_DIR}/references/wireframe-sweep.md` for the slug derivation, the two findings it reports, the stub it writes, and the output lines.
139
111
 
140
112
  ## Step 5: diagram staleness sweep
141
113
 
@@ -147,49 +119,7 @@ Follow `.claude/standards/diagrams.md` for the marker fields this step writes, o
147
119
 
148
120
  Both findings key on something literally entering or leaving the tree. Anything looser fires on ordinary feature work and rebuilds the ignored warning this sweep replaced.
149
121
 
150
- **Contradicted entries.** For each entry, collect the backticked code paths its explanation cites. When a cited path is in the diff as a delete or a rename and no longer exists in the tree, append a `stale` key to that entry's frontmatter naming the path:
151
-
152
- ```yaml
153
- stale: 'src/gov/install.ts no longer exists'
154
- ```
155
-
156
- Append that key alone. Never edit `verified`, `title`, `description`, or `category`, and never touch the body. When the entry already carries `stale`, extend the existing line rather than adding a second key.
157
-
158
- **Uncovered kinds.** The standard fixes one source signal per kind. Stub a kind when the diff adds its signal file and no entry covers that kind. The trigger is the signal appearing, never a file under it changing, so a branch editing a component folder that `components.md` already covers produces nothing here.
159
-
160
- | Signal added by the diff | Kind stubbed when absent |
161
- | ------------------------------------------------------------------------------------------------------------------ | ------------------------ |
162
- | `.claude/REQUIREMENTS.md` | `system-context.md` |
163
- | `.claude/ARCHITECTURE.md` | `components.md` |
164
- | A deploy or infrastructure config (`Dockerfile`, `.github/workflows/*`, `vercel.json`, `fly.toml`, `compose.yaml`) | `deployment.md` |
165
-
166
- Leave `request-flow.md` and `data-pipeline.md` out. Neither has a source signal a diff can point at, so a rule covering them would guess at when they went stale.
167
-
168
- Write the stub at `.claude/diagrams/<kind>.md`:
169
-
170
- ```markdown
171
- ---
172
- title: <Kind as title case>
173
- description: 'TODO: name the question this entry settles.'
174
- category: <the category the standard fixes for this kind>
175
- verified: 'TODO: never verified'
176
- ---
177
-
178
- # <Kind as title case>
179
-
180
- TODO: draw this. `<signal path>` entered the tree with no entry covering this kind.
181
-
182
- Run `/claude-diagram <kind>` to replace the stub.
183
- ```
184
-
185
- No mermaid fence. An empty stub is visible debt that reaches review through the branch diff, while a generated diagram nobody rendered is invisible debt that reads as verified. A fence here invites the next session to fill it in without a render.
186
-
187
- Output one line per finding:
188
-
189
- - `⚠ Diagram stale: .claude/diagrams/<kind>.md cites <path>, which left the tree`
190
- - `📝 Stubbed: .claude/diagrams/<kind>.md`
191
-
192
- If the sweep finds nothing, skip silently. An ordinary change that adds no signal and deletes no cited path produces no output at all.
122
+ Past the skip above, read `${CLAUDE_SKILL_DIR}/references/diagram-sweep.md` for the two findings, the signal table deciding an uncovered kind, the stub it writes, and the output lines. Both tests need the cited paths and the signal list that file carries, so the folder check is the only one the body can settle on its own.
193
123
 
194
124
  ## Step 6: flag CLAUDE.md drift
195
125
 
@@ -0,0 +1,58 @@
1
+ ---
2
+ title: Diagram staleness sweep
3
+ description: The contradicted-entry marker, the source-signal table that decides an uncovered kind, the stub it writes, and the report lines
4
+ ---
5
+
6
+ # Diagram staleness sweep
7
+
8
+ Mechanics for Step 5 of `claude-docs`. The body owns the skip conditions, the frontmatter-only constraint, and the standard citation, and this file owns what the sweep does once the diff carries a delete or a new source signal.
9
+
10
+ ## Contradicted entries
11
+
12
+ For each entry, collect the backticked code paths its explanation cites. When a cited path is in the diff as a delete or a rename and no longer exists in the tree, append a `stale` key to that entry's frontmatter naming the path:
13
+
14
+ ```yaml
15
+ stale: 'src/gov/install.ts no longer exists'
16
+ ```
17
+
18
+ Append that key alone. Never edit `verified`, `title`, `description`, or `category`, and never touch the body. When the entry already carries `stale`, extend the existing line rather than adding a second key.
19
+
20
+ ## Uncovered kinds
21
+
22
+ The standard fixes one source signal per kind. Stub a kind when the diff adds its signal file and no entry covers that kind. The trigger is the signal appearing, never a file under it changing, so a branch editing a component folder that `components.md` already covers produces nothing here.
23
+
24
+ | Signal added by the diff | Kind stubbed when absent |
25
+ | ------------------------------------------------------------------------------------------------------------------ | ------------------------ |
26
+ | `.claude/REQUIREMENTS.md` | `system-context.md` |
27
+ | `.claude/ARCHITECTURE.md` | `components.md` |
28
+ | A deploy or infrastructure config (`Dockerfile`, `.github/workflows/*`, `vercel.json`, `fly.toml`, `compose.yaml`) | `deployment.md` |
29
+
30
+ Leave `request-flow.md` and `data-pipeline.md` out. Neither has a source signal a diff can point at, so a rule covering them would guess at when they went stale.
31
+
32
+ Write the stub at `.claude/diagrams/<kind>.md`:
33
+
34
+ ```markdown
35
+ ---
36
+ title: <Kind as title case>
37
+ description: 'TODO: name the question this entry settles.'
38
+ category: <the category the standard fixes for this kind>
39
+ verified: 'TODO: never verified'
40
+ ---
41
+
42
+ # <Kind as title case>
43
+
44
+ TODO: draw this. `<signal path>` entered the tree with no entry covering this kind.
45
+
46
+ Run `/claude-diagram <kind>` to replace the stub.
47
+ ```
48
+
49
+ No mermaid fence. An empty stub is visible debt that reaches review through the branch diff, while a generated diagram nobody rendered is invisible debt that reads as verified. A fence here invites the next session to fill it in without a render.
50
+
51
+ ## Output
52
+
53
+ Output one line per finding:
54
+
55
+ - `⚠ Diagram stale: .claude/diagrams/<kind>.md cites <path>, which left the tree`
56
+ - `📝 Stubbed: .claude/diagrams/<kind>.md`
57
+
58
+ If the sweep finds nothing, skip silently. An ordinary change that adds no signal and deletes no cited path produces no output at all.
@@ -0,0 +1,45 @@
1
+ ---
2
+ title: Wireframe coverage sweep
3
+ description: Slug derivation from a UI-affecting path, the contradicted and uncovered findings, the surface stub, and the report lines
4
+ ---
5
+
6
+ # Wireframe coverage sweep
7
+
8
+ Mechanics for Step 4 of `claude-docs`. The body owns the skip conditions and the UI-path filter, and this file owns what the sweep does once a UI-affecting path survives that filter.
9
+
10
+ ## Deriving a candidate slug
11
+
12
+ For each UI-affecting path, derive a candidate surface slug from the file's basename and parent folder (e.g. `web/src/features/mock/MockDemoStrip.tsx` → `mock-demo-strip` or `mock`). Cross-reference against the surface files in `.claude/wireframes/`.
13
+
14
+ ## Findings
15
+
16
+ **Contradicted sections.** When a surface file exists for a path in the diff and the diff renames or removes a literal string that appears in the wireframe prose (e.g. provider name, button label, copy string), output a one-line report entry and stop. Do not auto-rewrite prose. Operator resolves.
17
+
18
+ **Uncovered surfaces.** When a UI-affecting path has no matching surface file by slug, write `.claude/wireframes/<slug>.md` with this stub:
19
+
20
+ ```markdown
21
+ ---
22
+ title: <Slug as title case>
23
+ description: TODO: describe the surface.
24
+ ---
25
+
26
+ # <Slug as title case>
27
+
28
+ TODO: describe when and where this surface appears.
29
+
30
+ ## Behavior
31
+
32
+ - TODO
33
+ ```
34
+
35
+ Skip the write when the slug would collide with an existing file (different surface, same slug). Surface the collision in the report instead.
36
+
37
+ ## Output
38
+
39
+ Output one line per finding:
40
+
41
+ - `⚠ Wireframe drift in .claude/wireframes/<surface>.md: <contradicted string>`
42
+ - `📝 Stubbed: .claude/wireframes/<surface>.md`
43
+ - `⚠ Slug collision: <slug> matches existing <existing-surface>.md, review and rename`
44
+
45
+ If the sweep finds nothing, skip silently.
@@ -88,41 +88,7 @@ Rules that resist crisp one-line phrasing default to **Retire** over promote. Ne
88
88
 
89
89
  Derive `<slug>` per `.claude/standards/slug.md`, or `${CLAUDE_SKILL_DIR}/../../standards/slug.md` when the project does not have it. Fall back to `latest` on an empty result.
90
90
 
91
- Write the full proposal to `.claude/review/memory-review-<slug>.md` at the main worktree root. Do not print it inline.
92
-
93
- Structure: a summary block at the top, a legend, then one H2 per numbered item. Number items across all actions so the user can reference them by number. Fuse the status, action, and target into each H2. Put the memory filename on its own line, a one-line Why, the rewritten rule inline in a fenced `diff` block prefixed with `+` so reviewers see the additions in green, and a `Decision:` slot for the user. Do not include a `Take:` slot in the template. Discuss inserts one directly under `Decision:` only when responding to a question item. Status starts as 📝 pending for every item at proposal time.
94
-
95
- ````plaintext
96
- # Memory review: <slug>
97
-
98
- **Pending:** <all numbers>
99
-
100
- Legend: ✅ applied · ⏭ skipped · 📦 retired · 🤝 handed off · 📝 pending
101
-
102
- How to respond: fill in `Decision:` per item (`apply`, `skip`, `defer`, or a question with `?`), then re-ping the skill. Say "discuss" for question rounds, "apply" to commit. Chat shortcut: `all`, `none`, or a list of numbers.
103
-
104
- ## 1. 📝 Promote → `<target>`
105
-
106
- `<memory-file>`
107
-
108
- Why: <one-line pulled from the memory's Why>
109
-
110
- ```diff
111
- + <rewritten rule text>
112
- ```
113
-
114
- Decision:
115
-
116
- ## 2. 📝 Retire
117
-
118
- `<memory-file>`
119
-
120
- Reason: <one-line reason>
121
-
122
- Decision:
123
- ````
124
-
125
- For Hand off items, the body is a pointer to the governance target instead of a rewritten rule: `aitk-governance` and `.claude/standards/rule.md` in the toolkit repo, or the `create-rule` skill in a target project. For Retire items, skip the rewrite block. Every item gets a `Decision:` slot regardless of action. `Take:` is added only when a question response is needed.
91
+ Write the full proposal to `.claude/review/memory-review-<slug>.md` at the main worktree root. Do not print it inline. Read `${CLAUDE_SKILL_DIR}/references/receipt-format.md` for the file structure, the item template, and how each action type varies the body. The four phases below rewrite items inside an existing receipt rather than authoring one, so none of them opens it.
126
92
 
127
93
  Tell the user `✅ Wrote proposal to .claude/review/memory-review-<slug>.md`. Ask them to fill in `Decision:` per item, then re-ping with "discuss" for question rounds or "apply" to commit.
128
94
 
@@ -0,0 +1,46 @@
1
+ ---
2
+ title: Memory review receipt format
3
+ description: The proposal file structure, its item template, and how each action type varies the body
4
+ ---
5
+
6
+ # Memory review receipt format
7
+
8
+ The shape Step 4 of the Propose phase writes to `.claude/review/memory-review-<slug>.md`. Only Propose writes this file. Challenge, Discuss, and Apply rewrite items inside a receipt that already exists, and Cleanup deletes one, so none of the four needs this file.
9
+
10
+ ## Structure
11
+
12
+ A summary block at the top, a legend, then one H2 per numbered item. Number items across all actions so the user can reference them by number. Fuse the status, action, and target into each H2. Put the memory filename on its own line, a one-line Why, the rewritten rule inline in a fenced `diff` block prefixed with `+` so reviewers see the additions in green, and a `Decision:` slot for the user. Do not include a `Take:` slot in the template. Discuss inserts one directly under `Decision:` only when responding to a question item. Status starts as 📝 pending for every item at proposal time.
13
+
14
+ ````plaintext
15
+ # Memory review: <slug>
16
+
17
+ **Pending:** <all numbers>
18
+
19
+ Legend: ✅ applied · ⏭ skipped · 📦 retired · 🤝 handed off · 📝 pending
20
+
21
+ How to respond: fill in `Decision:` per item (`apply`, `skip`, `defer`, or a question with `?`), then re-ping the skill. Say "discuss" for question rounds, "apply" to commit. Chat shortcut: `all`, `none`, or a list of numbers.
22
+
23
+ ## 1. 📝 Promote → `<target>`
24
+
25
+ `<memory-file>`
26
+
27
+ Why: <one-line pulled from the memory's Why>
28
+
29
+ ```diff
30
+ + <rewritten rule text>
31
+ ```
32
+
33
+ Decision:
34
+
35
+ ## 2. 📝 Retire
36
+
37
+ `<memory-file>`
38
+
39
+ Reason: <one-line reason>
40
+
41
+ Decision:
42
+ ````
43
+
44
+ ## Variation by action
45
+
46
+ For Hand off items, the body is a pointer to the governance target instead of a rewritten rule: `aitk-governance` and `.claude/standards/rule.md` in the toolkit repo, or the `create-rule` skill in a target project. For Retire items, skip the rewrite block. Every item gets a `Decision:` slot regardless of action. `Take:` is added only when a question response is needed.
@@ -13,9 +13,11 @@ The queue fails in both directions. It empties and a free worker waits, or it fi
13
13
 
14
14
  The session also writes surfaces it is told only how to read. Refilling the queue promotes and demotes rows in the priority file with no stated method, so a session invents one, and an inline rewrite exits clean when it matches nothing and leaves the board wrong with nothing reporting it. A row carrying prose where a plan pointer belongs costs a worker dispatch, because the ship chain refuses at its guard after the worktree is already open. A plan archived from a worker's own branch strands the pointer the board still carries, and the row reads as correct until someone follows it.
15
15
 
16
+ The ban on writing at all fails on a different axis, which is that nothing enforces it and a session weighs proportionality against it. A one-line prose correction found while orchestrating satisfies the root instruction to handle a small edit immediately and violates this rule, and a session given no statement of which one wins takes the smaller apparent cost and authors the change. That removes the independent pass the repository built to catch what a self-review misses, and the vantage does not come back, since no later session can review the change without re-deriving the context that produced it. A correction no open task owns has nowhere to go either, so the route matters as much as the ban.
17
+
16
18
  Output drifts everywhere the contract stops. The specified shape covers invocation alone, so a sweep report, a board report, and an analysis each end in a decision the human owns and each buries it under the evidence they would have skipped. A compaction is the same failure one step earlier, since the file that survives it has a stated reader and no stated writer, and the session improvises what to save and loses the reasoning the board never held.
17
19
 
18
- The runbooks the session cannot run from memory fail on a third axis, which is where they are kept. A runbook reached by an installed path is a dependency on a channel this skill does not travel on, so a project holding the plugin and running no install follows the citation to nothing, and nothing reports the break because a missing file produces no error until someone opens the path. The three that cover the moments the loop cannot detect therefore have to ship inside the skill.
20
+ The runbooks the session cannot run from memory fail on a third axis, which is where they are kept. A runbook reached by an installed path is a dependency on a channel this skill does not travel on, so a project holding the plugin and running no install follows the citation to nothing, and nothing reports the break because a missing file produces no error until someone opens the path. Every one of them therefore has to ship inside the skill, the three covering the moments the loop cannot detect and the fourth holding the review trigger. That fourth one fails on an axis of its own, since it names one client's command as the way to start the loop, so a session holding a different recurring-prompt scheduler reaches no path and a client without that command reaches none either, and the file ships to every target holding the plugin.
19
21
 
20
22
  ## Must
21
23
 
@@ -31,12 +33,14 @@ The runbooks the session cannot run from memory fail on a third axis, which is w
31
33
  - Re-resolve the board's plan pointers after any archive, since the archiving skill rewrites the task file and knows nothing about the board
32
34
  - Lead a sweep report, a board report, and an analysis with the state, the open decisions, and the next action, keeping the evidence below them
33
35
  - Write the pre-compact handoff with what no other file carries, and name the runbook that reads it back
34
- - Carry the handoff, resume, and sweep runbooks inside the skill, so every citation resolves for a project holding the plugin and nothing else
36
+ - Carry every runbook the session cannot run from memory inside the skill, so each citation resolves for a project holding the plugin and nothing else
37
+ - State which rule wins where the tracked-file ban collides with the root instruction on small edits, and where a correction no open task owns goes
38
+ - State the review trigger as a recurring prompt rather than as one client's command, since the runbook ships to targets running whatever client they run
35
39
  - Read the handoff or the resume runbook when the human asks for that side of a compaction, since the request is the only signal available for a moment the loop cannot detect
36
40
 
37
41
  ## Must not
38
42
 
39
- - Implement a feature or edit any tracked file from this session
43
+ - Implement a feature or edit any tracked file from this session, at any size, since the ban offers no proportionality exception
40
44
  - Merge. Recommend merge or changes and leave the gate to the human.
41
45
  - Spawn worker sessions with agents, since every build is meant to be an independent steerable stream
42
46
  - Hand a worker anything but a plan, because scope lives there
@@ -37,7 +37,7 @@ The roadmap is optional and this skill does not require it. It carries why a seq
37
37
 
38
38
  A compaction is a moment this skill cannot detect, so the human asks for each side of it and this skill reads the matching runbook when they do. On a request to write the handoff or save the session, read `${CLAUDE_SKILL_DIR}/references/orchestrator-handoff.md` and follow it. It writes `.claude/tasks/session.md` with the state of play, the decisions taken under delegated authority, the mistakes worth not repeating, and the standing cautions. On a request to resume after a compaction, read `${CLAUDE_SKILL_DIR}/references/orchestrator-resume.md`, which reads that file back with the board and the groundwork behind the live work. Write nothing to the handoff that the board, a task file, or a groundwork folder already carries.
39
39
 
40
- The review trigger takes the same shape. `references/orchestrator-poll.md` holds the loop prompt and the condition under which the poll runs, and `scripts/poll.sh` is what the prompt invokes. Nothing starts or stops that loop on its own, so the condition holds only while a session applies it.
40
+ The review trigger takes the same shape. `references/orchestrator-poll.md` holds the loop prompt and the condition under which the poll runs, and `scripts/poll.sh` is what the prompt invokes. A session holding a recurring-prompt scheduler starts and cancels that loop itself, and no hook or check does, so the condition holds only while whoever holds the loop applies it.
41
41
 
42
42
  That routing lives in this body and this skill is user-invoked, so a session that has dropped the body routes nothing and the request lands as ordinary conversation. Approaching a compaction is when a long session is likeliest to have dropped it, which is the same moment the handoff exists for. Re-invoke `/aitk:claude-orchestrate` first whenever the session has run long or the ask goes unanswered. The two runbooks sit at `references/orchestrator-handoff.md` and `references/orchestrator-resume.md` inside this skill's own folder, so a person who knows their plugin root opens either one directly and follows it without this skill loaded at all.
43
43
 
@@ -107,9 +107,11 @@ Write no shape for a correction. A correction is a sentence, and a format for ad
107
107
  - Do not implement features in this session. Hand the plan to a worker.
108
108
  - Do not merge. Recommend merge or changes. The human merges.
109
109
  - Do not spawn worker sessions with agents. The human launches each worktree so every build is an independent, steerable stream with its own PR.
110
- - Do not edit tracked files from this session. Record a change identified while orchestrating against the task that owns it, so it ships from that task's branch and lands in a pull request.
110
+ - Do not edit tracked files from this session, at any size. The boundary offers no proportionality exception and nothing enforces it.
111
111
  - Do not hand a worker anything but a plan, since scope lives there. A plan carries exact diffs only when they are already known, otherwise it states the scope and the open questions and lets the worker write the diff.
112
112
 
113
+ The tracked-file boundary collides with `CLAUDE.md`, which says to handle a small edit immediately without a task entry, and this rule wins wherever the two meet. A session that writes a change cannot review it independently afterwards and no later session recovers that vantage, which is the separation `claude-pr-review` exists to supply. Record a change identified while orchestrating against the task that owns it, fold one no task owns into the next task touching the same surface, and file a task only when no such task exists or is expected. Run `claude-review` when the boundary is crossed anyway, since a branch-diff pass is not independent and is the only check a self-authored change can get.
114
+
113
115
  ## Refilling the ready queue
114
116
 
115
117
  Keep enough planned, non-conflicting tasks available that a free worker never waits, and place the findings the last merge produced before promoting anything new. Run this after every merge and whenever the ready list thins. `${CLAUDE_SKILL_DIR}/references/orchestrator-sweep.md` wraps this procedure for a batch of merges and adds the plan re-verification that a merge invalidates.
@@ -11,16 +11,22 @@ Run the orchestrator's review trigger. The poll reports pull request movement an
11
11
 
12
12
  Start the poll on a dispatch and stop it when the last pull request merges with nothing else out. An open pull request or a dispatched worker is the condition, and both resolve from the board plus `gh pr list` without asking the operator. A release pull request alone does not qualify, since its sweep carries no findings.
13
13
 
14
- Nothing enforces this. No hook starts the poll and no check stops it, so the condition holds only while a session applies it. Left always-on it fires into an empty board through every gap between a dispatch and its push, which leaves stopping it to the operator.
14
+ A session holding a recurring-prompt scheduler starts the loop itself on that condition and cancels it on the same test, without waiting for the operator. Both halves belong to whoever holds the loop, since a session that can start one can stop one, and a runbook stating only the start leaves the always-on failure unaddressed on the side that causes it.
15
+
16
+ Nothing enforces this. No hook starts the poll and no check stops it, so the condition holds only while whoever holds the loop applies it. Left always-on it fires into an empty board through every gap between a dispatch and its push.
15
17
 
16
18
  The poll is session-scoped and dies with the session that started it. Restart it after a compaction, and take the prompt from this file rather than from a transcript, since a running loop holds whatever wording it was started with and a correction here does not reach it.
17
19
 
18
20
  ## The prompt
19
21
 
20
- Resolve `${CLAUDE_SKILL_DIR}/scripts/poll.sh` to an absolute path and paste that in place of `<POLL_SCRIPT>` below. The variable expands while this runbook renders and not in a `/loop` turn, which arrives as a standalone prompt, so a block carrying the variable reaches the session as a literal string and the run improvises a substitute.
22
+ The requirement is a recurring prompt at roughly three minutes carrying the block below. `/loop 3m <the block>` is the mechanism this repository uses and one example among the schedulers a client may hold, so a client without that command reaches the same requirement through whatever recurring prompt it can schedule. Naming one vendor's command as the only path dates a file that ships to every target holding the plugin.
23
+
24
+ The interval belongs to the schedule rather than to the script. One run is a single snapshot returning in about six seconds, so a session that reads `3m` as the script's runtime and relaunches on completion fires every few seconds and never settles, which happened once for 35 minutes.
25
+
26
+ Resolve `${CLAUDE_SKILL_DIR}/scripts/poll.sh` to an absolute path and paste that in place of `<POLL_SCRIPT>` below. The variable expands while this runbook renders and not in a standalone loop turn, so a block carrying the variable reaches the session as a literal string and the run improvises a substitute.
21
27
 
22
28
  ```plaintext
23
- /loop 3m Poll GitHub for pull request movement by running <POLL_SCRIPT>, then act on what it reports.
29
+ Poll GitHub for pull request movement by running <POLL_SCRIPT>, then act on what it reports.
24
30
 
25
31
  - MOVED or RESPONSE on a pull request I have already reviewed: run the aitk:claude-pr-review skill on it immediately, narrow pass. Re-reviews read prior..head and gain nothing from waiting.
26
32
  - OPENED, or a pull request with no prior review pass: report it and stop. First passes wait for the operator, because reading several together is what surfaces cross-PR findings.
@@ -40,7 +40,7 @@ A body whose frontmatter does not parse reports as declaring neither field rathe
40
40
 
41
41
  ## What it leaves alone
42
42
 
43
- The report names its own blind spots on every run, including the run where everything passed. Whether each `Must` traces to a stated gap is the rule in that standard worth the most and no parser reads it. Whether a gap states an observed failure rather than an intent, and whether a description routes, are the same kind of judgment. The 5,000-word body ceiling is mechanical and still absent here.
43
+ The report names its own blind spots on every run, including the run where everything passed. Whether each `Must` traces to a stated gap is the rule in that standard worth the most and no parser reads it. Whether a gap states an observed failure rather than an intent, and whether a description routes, are the same kind of judgment. The 150-line body checkpoint is the one mechanical rule still absent here, and adding it would print a count rather than a defect, since the standard makes it a prompt to look with nothing enforcing it.
44
44
 
45
45
  A check with no rule behind it prints an opinion as a defect, which is where the list stops.
46
46
 
@@ -16,15 +16,21 @@ order, port collisions), see [Claude Code and git worktrees](../wiki/claude/clau
16
16
 
17
17
  The split is by vantage, not by capability. Both are Claude Code sessions.
18
18
 
19
- | Role | Session | Owns | Does not |
20
- | ------------ | ------------------------------------- | ---------------------------------------------- | ------------------------- |
21
- | Orchestrator | One warm, long-lived session | Roadmap, planning, deep PR review, merge order | Build features, merge PRs |
22
- | Worker | One cold worktree session per feature | Implement, self-check, open PR | Question the plan, merge |
19
+ | Role | Session | Owns | Does not |
20
+ | ------------ | ------------------------------------- | ---------------------------------------------- | ----------------------------- |
21
+ | Orchestrator | One warm, long-lived session | Roadmap, planning, deep PR review, merge order | Edit tracked files, merge PRs |
22
+ | Worker | One cold worktree session per feature | Implement, self-check, open PR | Question the plan, merge |
23
23
 
24
24
  The orchestrator is worth asserting explicitly at the start of a session with
25
25
  `claude-orchestrate`, which loads the loop and its boundaries. It is framing and
26
26
  dispatch, not logic.
27
27
 
28
+ The orchestrator's cell reads every tracked file rather than every feature, and
29
+ it offers no exception for a small one. A correction found while orchestrating
30
+ goes to the task that owns the surface, or folds into the next task touching it,
31
+ because a session that writes a change cannot review it independently afterwards
32
+ and no later session recovers that vantage.
33
+
28
34
  ## The loop
29
35
 
30
36
  One feature travels this path end to end.
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@erclx/aitk",
3
3
  "type": "module",
4
- "version": "0.61.0",
4
+ "version": "0.62.1",
5
5
  "description": "Infrastructure and quality tooling for developer workflows",
6
6
  "license": "MIT",
7
7
  "bin": {
@@ -689,5 +689,7 @@ function reportUnmeasured(): void {
689
689
  logInfo(
690
690
  'Whether each Must traces to a stated gap, whether a gap reads as an observed failure rather than an intent, and whether a description routes.',
691
691
  )
692
- logInfo('The 5,000-word body ceiling is mechanical and still absent here.')
692
+ logInfo(
693
+ 'The 150-line body checkpoint is mechanical and still absent here, and it would print a count rather than a defect.',
694
+ )
693
695
  }
@@ -184,7 +184,11 @@ Without this skill, a session <observed failure>, <observed failure>.
184
184
 
185
185
  ### Progressive disclosure
186
186
 
187
- - Keep `SKILL.md` under 5,000 words. Move detailed docs to `references/`.
187
+ - Look at a body once it passes 150 lines. The number prompts a look rather than gating a build, so nothing enforces it and a body carrying nothing but procedure stays whole at any length.
188
+ - Move a catalog, a table of cases, or a format spec running past roughly 15 lines to `references/`. Procedure prose stays, since a session sent to a reference for its own steps pays two reads for one job.
189
+ - Name the branch that skips a block before moving it. Body lines are paid on every invocation and a reference only when the body sends the session to it, so a block every run dereferences costs a read and saves nothing.
190
+ - Keep the trigger, the skip condition, and the guard in the body. A run that never reaches the block has to decide that without opening the reference.
191
+ - Never point one skill at a sibling skill's folder for a reference both read. Each skill carries its own copy under `references/`, generated rather than hand-copied by the rule in `## Path resolution`.
188
192
  - Use progressive disclosure: `SKILL.md` for core instructions, `references/` for detail, `scripts/` for deterministic operations
189
193
  - Link to `references/` files explicitly so Claude knows to load them
190
194