@linimin/pi-letscook 0.1.26

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.
package/CHANGELOG.md ADDED
@@ -0,0 +1,196 @@
1
+ # Changelog
2
+
3
+ ## 0.1.26
4
+
5
+ ### Changed
6
+
7
+ - clarified the README install guidance and `/cook` behavior matrix, including tracked-vs-ignored `.agent` file explanations, active-workflow replacement examples, and safer `/reload` guidance for completion work
8
+
9
+ ## 0.1.25
10
+
11
+ ### Changed
12
+
13
+ - `/cook` with no goal can now propose a context-derived startup plan for confirmation when no active workflow exists, including starting a fresh next round after the previous workflow already reached `done`
14
+ - `/cook <goal>` now builds a goal-anchored, context-enriched startup proposal before writing canonical state, uses more explicit active-workflow replacement wording, and starts the next round directly from the explicit goal after a completed workflow instead of reopening continue/refocus choices
15
+
16
+ ## 0.1.24
17
+
18
+ ### Changed
19
+
20
+ - removed the completion status line entirely; the remaining completion widget appears only when no role is actively running
21
+
22
+ ## 0.1.23
23
+
24
+ ### Changed
25
+
26
+ - renamed the public workflow command from `/complete` to `/cook`
27
+ - aligned the published package/install identity around `@linimin/pi-letscook` and `pi-letscook`
28
+ - removed the completion status line entirely; the remaining completion widget now appears only when no role is actively running
29
+ - kept the richer live role observability lanes and waiting/stalled signaling without reintroducing a status-line surface
30
+ - added this current release entry so the shipped `/cook`, package rename, and current completion UI behavior are documented without rewriting older `/complete` history
31
+
32
+ ## 0.1.22
33
+
34
+ ### Changed
35
+
36
+ - clarified the existing-workflow continue/refocus selection UI with a clearer prompt, current-vs-proposed mission summary, and shorter option descriptions
37
+
38
+ ## 0.1.21
39
+
40
+ ### Changed
41
+
42
+ - kept the persistent completion status line from canonical `.agent/**` state and live role activity, while suppressing the widget whenever a role is actively running
43
+ - separated live running-role observability into distinct tool activity, role judgment, verification, and state-delta lanes with waiting/stalled signaling
44
+ - added deterministic observability status regression coverage to the release-check path
45
+ - refreshed README and release-verifier guidance so the shipped observability surfaces and verification flow are documented truthfully
46
+
47
+ ## 0.1.18
48
+
49
+ ### Changed
50
+
51
+ - reduced the public slash-command surface to a single `/complete` entrypoint
52
+ - `/complete` with no goal now resumes from canonical `.agent/**` state when present
53
+ - `/complete <new goal>` now asks whether to continue the current mission or refocus canonical mission state before continuing
54
+ - removed dedicated resume, reground, panel, history, verify, and pause slash commands in favor of the always-visible workflow status
55
+ - pruned helper code that only supported the removed slash commands
56
+ - added a regression test for existing-workflow refocus handling and included it in release checks
57
+
58
+ ## 0.1.16
59
+
60
+ ### Improved
61
+
62
+ - richer operator-facing live role execution display with progress, rationale, next-step, verification, and state-delta parsing
63
+ - elapsed-time tracking for running completion roles
64
+ - no emoji in workflow-specific status, widget, panel, or role execution displays
65
+ - role prompts now emit structured `PROGRESS`, `RATIONALE`, `NEXT`, `VERIFYING`, and `STATE-DELTA` lines for observability
66
+
67
+ ## 0.1.15
68
+
69
+ ### Changed
70
+
71
+ - removed `/completion-status`; rely on the persistent widget/footer and `/completion-panel` for state inspection
72
+
73
+ ## 0.1.14
74
+
75
+ ### Changed
76
+
77
+ - removed `/completion-init` and made `/complete <goal>` the single bootstrap-and-run entrypoint
78
+ - smoke test now validates bootstrap through `/complete`
79
+ - docs updated to treat `/complete` as the canonical initialization path
80
+
81
+ ## 0.1.13
82
+
83
+ ### Improved
84
+
85
+ - persistent footer/widget status is now more compact and useful for day-to-day workflow use
86
+ - always-visible status now surfaces live role/action summaries without requiring the panel to be open
87
+ - widget lines now favor concise mission, goal, reason, and live activity previews over verbose raw fields
88
+
89
+ ## 0.1.12
90
+
91
+ ### Improved
92
+
93
+ - `/completion-panel` now live-follows current running role activity
94
+ - side panel and print-mode panel output now include current role, current action, recent activity, and assistant-progress previews while a completion role is running
95
+
96
+ ## 0.1.11
97
+
98
+ ### Added
99
+
100
+ - `/completion-panel` command for an on-demand right-side completion workflow panel
101
+ - live panel view for canonical mission, current phase, active slice, remaining work, and recent history
102
+ - print-mode fallback that renders panel contents as plain text when interactive UI is unavailable
103
+
104
+ ## 0.1.10
105
+
106
+ ### Improved
107
+
108
+ - ambiguous bootstrap goals can now trigger developer confirmation or editing of the proposed `MISSION ANCHOR`
109
+ - `/complete` and `/completion-init` keep auto-bootstrap for clear goals but ask before writing weak or underspecified anchors into canonical state
110
+ - mission-anchor confirmation uses extension UI instead of relying on model-side clarification later in the workflow
111
+
112
+ ## 0.1.9
113
+
114
+ ### Improved
115
+
116
+ - bootstrap now derives a cleaner `MISSION ANCHOR` from vague `/complete` and `/completion-init` goals
117
+ - weak or underspecified goals now fall back to a stable repo-based mission anchor instead of using raw ambiguous text
118
+ - common phrasing noise like `/complete`, `please`, and `end-to-end` is normalized before seeding canonical mission state
119
+
120
+ ## 0.1.8
121
+
122
+ ### Fixed
123
+
124
+ - removed duplicate prompt-template aliases for `/complete`, `/complete-resume`, and `/completion-status`
125
+ - package now exposes those names only as extension commands, avoiding duplicate command entries in pi
126
+
127
+ ## 0.1.7
128
+
129
+ ### Fixed
130
+
131
+ - generated `verify_completion_control_plane.sh` now validates canonical `plan.json` and `active-slice.json` structure instead of only checking JSON parseability
132
+ - exact implementer handoff states now require `priority` and `why_now`, matching the completion protocol docs and role expectations
133
+ - scaffolded `active-slice.json` now includes `priority` and `why_now` placeholders to avoid schema drift during later role updates
134
+ - `ensureGitignore` now repairs duplicated or drifted completion-protocol ignore blocks instead of bailing out on the first marker match
135
+ - smoke test now covers the selected active-slice handoff schema regression and fails closed when `priority`/`why_now` are missing
136
+
137
+ ## 0.1.6
138
+
139
+ ### Fixed
140
+
141
+ - additional stale-context guards for command handlers and completion role execution
142
+ - avoid stale ctx access through cwd, hasUI, ui, and system-prompt lookups after session replacement or reload
143
+
144
+ ## 0.1.5
145
+
146
+ ### Fixed
147
+
148
+ - stale extension context handling after session replacement or reload
149
+ - guarded UI status, widget, theme, and notify calls to avoid stale-ctx runtime errors
150
+
151
+ ## 0.1.4
152
+
153
+ ### Improved
154
+
155
+ - stronger implementer instructions for roadmap-level drift discovered during implementation
156
+ - explicit requirement to hand plan repair back to `completion-regrounder` instead of silently redesigning slices
157
+ - implementer report now includes `Plan adjustment required: yes/no - ...`
158
+
159
+ ## 0.1.3
160
+
161
+ ### Improved
162
+
163
+ - richer live progress visibility for `completion_role`
164
+ - current action, recent activity, and assistant-progress previews while roles are running
165
+ - less opaque role execution UX during long-running workflow steps
166
+
167
+ ## 0.1.2
168
+
169
+ ### Improved
170
+
171
+ - stronger post-compaction driver recovery instructions
172
+ - transient post-compaction recovery marker with automatic cleanup after recovery turn
173
+ - stricter canonical-file-first continuation guidance after compaction
174
+
175
+ ## 0.1.1
176
+
177
+ ### Improved
178
+
179
+ - print-mode output for `/completion-status`, `/completion-history`, `/completion-verify`, and `/completion-pause`
180
+ - package-local runtime polish for release workflow
181
+
182
+ ## 0.1.0
183
+
184
+ Initial packaged release of `pi-completion-workflow`.
185
+
186
+ ### Added
187
+
188
+ - pi package manifest with extension, skills, prompts, and role agents
189
+ - canonical `.agent/**` scaffolding via `/completion-init`
190
+ - workflow entrypoints: `/complete` and `/complete-resume`
191
+ - workflow inspection commands: `/completion-status`, `/completion-history`, `/completion-verify`
192
+ - pause and re-ground commands
193
+ - isolated `completion_role` execution for role-based subagents
194
+ - canonical transcription of reviewer, auditor, regrounder, and stop-judge outputs
195
+ - custom compaction continuity support
196
+ - release smoke test script
package/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 linimin
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
package/PUBLISHING.md ADDED
@@ -0,0 +1,60 @@
1
+ # Publishing Guide
2
+
3
+ ## Before publishing
4
+
5
+ Run from the package root:
6
+
7
+ ```bash
8
+ npm run smoke-test
9
+ npm run release-check
10
+ ```
11
+
12
+ ## GitHub release flow
13
+
14
+ ```bash
15
+ git init
16
+ git add .
17
+ git commit -m "Initial release"
18
+ git branch -M main
19
+ git remote add origin git@github.com:<YOUR-USER>/pi-letscook.git
20
+ git push -u origin main
21
+ git tag v0.1.0
22
+ git push origin v0.1.0
23
+ ```
24
+
25
+ Users can then install with:
26
+
27
+ ```bash
28
+ pi install git:github.com/<YOUR-USER>/pi-letscook@v0.1.0
29
+ ```
30
+
31
+ ## npm release flow
32
+
33
+ For the scoped public package name `@linimin/pi-letscook`, publish with:
34
+
35
+ ```bash
36
+ npm login
37
+ npm publish --access public
38
+ ```
39
+
40
+ Users can then install with:
41
+
42
+ ```bash
43
+ pi install npm:@linimin/pi-letscook
44
+ ```
45
+
46
+ ## Recommended metadata before public release
47
+
48
+ Consider updating these fields in `package.json` before publishing publicly:
49
+
50
+ - `name`
51
+ - `repository`
52
+ - `homepage`
53
+ - `bugs`
54
+ - `author`
55
+
56
+ ## Versioning
57
+
58
+ - bump `version` in `package.json`
59
+ - add a new entry to `CHANGELOG.md`
60
+ - create a matching git tag like `v0.1.1`
package/README.md ADDED
@@ -0,0 +1,219 @@
1
+ # @linimin/pi-letscook
2
+
3
+ Pi package for long-running coding workflows with canonical repo-local `.agent/**` state.
4
+
5
+ ## What it gives you
6
+
7
+ - `/cook` as the single workflow command
8
+ - `/cook <goal>` to bootstrap or continue with an explicit goal, enriched by recent discussion before canonical state is written
9
+ - `/cook` with no goal to resume an active canonical `.agent/**` workflow, or propose a new round from recent discussion when no active workflow is running
10
+ - `/cook <new goal>` on an active workflow asks whether to continue the current mission or abandon it for a replacement workflow; on a completed workflow it starts the next round from the new goal instead of reopening continue/refocus choices
11
+ - no duplicate prompt-template aliases for core workflow commands
12
+ - role-based isolated subprocess execution via `completion_role`
13
+ - completion widget sourced from canonical `.agent/**` state when no role is actively running, with no completion status line
14
+ - richer live role observability that keeps tool activity separate from role progress, rationale, next-step, verification, and state-delta output
15
+ - deterministic waiting/stalled signaling for running completion roles
16
+ - custom compaction continuity capsule
17
+ - canonical transcription of reviewer, auditor, regrounder, and stop-judge outputs
18
+ - repo-local verifier scripts and `.gitignore` wiring
19
+
20
+ ## Quick start
21
+
22
+ In a git repo, after installing the package:
23
+
24
+ ```text
25
+ /cook build feature X end-to-end with tests and docs
26
+ ```
27
+
28
+ If you stop and come back later while that workflow is still active:
29
+
30
+ ```text
31
+ /cook
32
+ ```
33
+
34
+ If you want to replace the active workflow with a new goal:
35
+
36
+ ```text
37
+ /cook fix onboarding crash first, with regression tests
38
+ ```
39
+
40
+ If the previous workflow is already done and you want to start the next round from an explicit goal:
41
+
42
+ ```text
43
+ /cook ship the next workflow round for richer /cook startup proposals
44
+ ```
45
+
46
+ ## Install
47
+
48
+ ### Try temporarily from a local checkout
49
+
50
+ ```bash
51
+ pi -e /absolute/path/to/pi-letscook
52
+ ```
53
+
54
+ ### Install globally from a local checkout
55
+
56
+ ```bash
57
+ pi install /absolute/path/to/pi-letscook
58
+ ```
59
+
60
+ ### Install into a project from a local checkout
61
+
62
+ ```bash
63
+ pi install -l /absolute/path/to/pi-letscook
64
+ ```
65
+
66
+ ### Install from npm after publishing
67
+
68
+ ```bash
69
+ pi install npm:@linimin/pi-letscook
70
+ ```
71
+
72
+ ### Install from git after publishing
73
+
74
+ For normal installs, prefer the npm package above. Use the git source if you want to install directly from GitHub.
75
+
76
+ ```bash
77
+ pi install git:github.com/linimin/pi-letscook
78
+ ```
79
+
80
+ You can also pin a specific tag or commit if you want a fixed version, for example `git:github.com/linimin/pi-letscook@vX.Y.Z`.
81
+
82
+ After install, run `/reload` in pi. For this package, it is safest to reload when pi is idle and no `completion_role` is currently running.
83
+
84
+ ## Usage patterns
85
+
86
+ ### Mental model
87
+
88
+ `/cook` is the single entrypoint for this package, but its behavior depends on the current canonical workflow state.
89
+
90
+ | Repo state | `/cook` | `/cook <goal>` |
91
+ |---|---|---|
92
+ | No canonical workflow yet | Proposes a startup plan from recent discussion, then asks for confirmation | Builds a startup proposal anchored on the explicit goal, enriches it from recent discussion, then asks for confirmation |
93
+ | Active workflow exists | Resumes the active workflow from canonical `.agent/**` state | Asks whether to continue the current workflow or replace it with a new one |
94
+ | Previous workflow is already `done` | Proposes the next workflow round from recent discussion, then asks for confirmation | Starts the next workflow round from the explicit goal, using recent discussion only as supplemental proposal context |
95
+
96
+ ### One-step start
97
+
98
+ ```text
99
+ /cook Build feature X with tests and docs
100
+ ```
101
+
102
+ This bootstraps `.agent/**` if missing, derives a clean initial `MISSION ANCHOR`, builds a startup proposal, lets you confirm or edit it, re-grounds canonical state, creates a slice plan, and drives the workflow.
103
+
104
+ When you pass an explicit goal, that goal stays the mission anchor. Recent discussion is only used to fill in extra scope, constraints, and acceptance details before canonical state is written.
105
+
106
+ ### Resume later
107
+
108
+ ```text
109
+ /cook
110
+ ```
111
+
112
+ If canonical `.agent/**` state already exists and is still active, `/cook` with no goal resumes from that state.
113
+
114
+ ### Replace the active workflow
115
+
116
+ ```text
117
+ /cook fix onboarding crash first, with regression tests
118
+ ```
119
+
120
+ If a workflow is still active, `/cook <goal>` asks whether to:
121
+
122
+ - continue the current workflow, or
123
+ - abandon the current workflow and start this new one
124
+
125
+ If you replace the active workflow, `/cook` rebuilds canonical state from the new goal and restarts from `reground`.
126
+
127
+ ### Start the next round after completion
128
+
129
+ ```text
130
+ /cook ship the next workflow round for richer /cook startup proposals
131
+ ```
132
+
133
+ If the previous workflow is already `done`, `/cook <goal>` starts the next workflow round directly from that explicit goal. It does not reopen the old continue/refocus choice. Recent discussion is only used as supplemental proposal context.
134
+
135
+ ### Start the next round from discussion only
136
+
137
+ ```text
138
+ /cook
139
+ ```
140
+
141
+ If the previous workflow is already `done`, `/cook` with no goal tries to infer the next plan from recent discussion, asks you to confirm it, and then starts the next workflow round from refreshed canonical state.
142
+
143
+ ## Canonical repo files
144
+
145
+ This package manages repo-local canonical workflow state under:
146
+
147
+ ```text
148
+ .agent/
149
+ README.md
150
+ mission.md
151
+ profile.json
152
+ verify_completion_stop.sh
153
+ verify_completion_control_plane.sh
154
+ state.json
155
+ plan.json
156
+ active-slice.json
157
+ slice-history.jsonl
158
+ stop-check-history.jsonl
159
+ tmp/
160
+ ```
161
+
162
+ Canonical truth lives in these files plus current repo truth.
163
+
164
+ ### Tracked vs ignored `.agent` files
165
+
166
+ The `.agent` directory mixes two different kinds of workflow data:
167
+
168
+ - **Tracked repo-contract files** define the repo-level workflow contract and should stay in git:
169
+ - `.agent/README.md`
170
+ - `.agent/mission.md`
171
+ - `.agent/profile.json`
172
+ - `.agent/verify_completion_stop.sh`
173
+ - `.agent/verify_completion_control_plane.sh`
174
+ - **Ignored execution-state files** are local high-churn workflow state used for resume and recovery and should stay out of git:
175
+ - `.agent/state.json`
176
+ - `.agent/plan.json`
177
+ - `.agent/active-slice.json`
178
+ - `.agent/slice-history.jsonl`
179
+ - `.agent/stop-check-history.jsonl`
180
+ - `.agent/*.log`
181
+ - `.agent/tmp/`
182
+
183
+ In other words: tracked `.agent` files describe the workflow contract for the repo, while ignored `.agent` files are the local control-plane state for the current run.
184
+
185
+ ## Live observability surfaces
186
+
187
+ When canonical `.agent/**` state exists and no role is actively running, the extension shows a completion widget sourced from that state. The non-running widget summarizes the current phase, selected slice, next mandatory role, and remaining work counts; there is no completion status line.
188
+
189
+ While a `completion_role` subprocess is running, the widget is intentionally suppressed. Tool execution is rendered separately from assistant-provided `PROGRESS`, `RATIONALE`, `NEXT`, `VERIFYING`, and `STATE-DELTA` lines so operators can tell the difference between tool work, role judgment, and verification. The running-role display still emits deterministic active/waiting/stalled signaling from the role timestamps instead of silently looking idle.
190
+
191
+ ## Package layout
192
+
193
+ - `extensions/completion/index.ts` — workflow extension
194
+ - `skills/completion-protocol/` — shared protocol docs
195
+ - `agents/completion-*.md` — package-local completion roles used by the extension
196
+ - `scripts/` — smoke and release checks
197
+
198
+ ## Development and release
199
+
200
+ Run validation from the package root:
201
+
202
+ ```bash
203
+ npm run smoke-test
204
+ npm run refocus-test
205
+ npm run context-proposal-test
206
+ npm run observability-status-test
207
+ npm run release-check
208
+ ```
209
+
210
+ `npm run release-check` is the broader packaged-release verifier. It reruns the smoke, refocus, and context-proposal checks, includes the deterministic observability regression coverage, and finishes with `npm pack --dry-run`.
211
+
212
+ See [PUBLISHING.md](./PUBLISHING.md) for GitHub and npm release steps.
213
+
214
+ ## Notes
215
+
216
+ - Canonical truth lives in repo-local `.agent/**` files.
217
+ - The main pi session is the workflow driver.
218
+ - Package-local role prompts are loaded directly by the extension; they do not rely on `~/.pi/agent/agents`.
219
+ - Reviewer, auditor, and stop-judge are enforced as read-only roles.
@@ -0,0 +1,43 @@
1
+ ---
2
+ name: completion-auditor
3
+ description: Read-only completion auditor; state why the project is not yet done and whether canonical state and backlog remain truthful.
4
+ tools: read,grep,find,ls,bash
5
+ ---
6
+
7
+ You are the read-only `completion` auditor.
8
+
9
+ Load `completion-protocol` before acting.
10
+
11
+ You must not:
12
+
13
+ - edit tracked repo files
14
+ - write canonical `.agent` state
15
+ - append slice-history or stop-check records yourself
16
+ - create commits
17
+
18
+ Audit current HEAD truth after a committed slice. Focus on remaining work, tracked and unignored worktree cleanliness, and canonical truthfulness.
19
+
20
+ During long work, emit short operator-facing progress lines when useful using these exact prefixes:
21
+ - `PROGRESS: ...`
22
+ - `RATIONALE: ...`
23
+ - `NEXT: ...`
24
+
25
+ These lines are for workflow observability, not hidden reasoning. Keep them brief and truthful.
26
+
27
+ Answer only:
28
+
29
+ - `MISSION ANCHOR: ...`
30
+ - `Remaining contract IDs: ...`
31
+ - `Why the project is still not done: ...`
32
+ - `Open top-level contract IDs: ...`
33
+ - `Blocker count: ...`
34
+ - `High-value gap count: ...`
35
+ - `Tracked and unignored worktree is clean: yes/no`
36
+ - `Worktree blockers: ...`
37
+ - `Next mandatory slice: ...`
38
+ - `Stale or conflicting canonical state: ...`
39
+ - `Plan truthfully captures remaining slice backlog: yes/no - ...`
40
+
41
+ If the tracked and unignored worktree is dirty after the latest committed slice, report that as a blocker to next-slice progression, do not recommend a new next slice, and point the workflow back to reconciliation of the latest slice.
42
+
43
+ If no remaining gap is evident, say so plainly instead of inventing one.
@@ -0,0 +1,56 @@
1
+ ---
2
+ name: completion-bootstrapper
3
+ description: Bootstrap or repair tracked completion control-plane files, then hand off to completion-regrounder.
4
+ tools: read,grep,find,ls,bash,write,edit
5
+ ---
6
+
7
+ You are the `completion` bootstrapper.
8
+
9
+ Load `completion-protocol` before acting. Use it as the shared protocol source of truth.
10
+
11
+ You are an onboarding-only control-plane role. You may:
12
+
13
+ - read current repo truth and canonical `.agent` state
14
+ - create or repair tracked completion contract files under `.agent/**`
15
+ - update `.gitignore` so tracked contract files remain tracked while execution artifacts remain ignored
16
+ - initialize missing or invalid canonical execution-state files only when repair is required for a truthful handoff
17
+ - return the exact handoff payload for `completion-regrounder`
18
+
19
+ You must not:
20
+
21
+ - invoke any completion role
22
+ - edit tracked product, docs, config, or test files outside `.agent/**` and `.gitignore`
23
+ - overwrite existing truthful `.agent/state.json`, `.agent/plan.json`, or `.agent/active-slice.json`
24
+ - create commits
25
+ - append slice-history or stop-check records
26
+ - continue into implementation, review, audit, or stop judgment yourself
27
+
28
+ On onboarding or repair:
29
+
30
+ During long work, emit short operator-facing progress lines when useful using these exact prefixes:
31
+ - `PROGRESS: ...`
32
+ - `RATIONALE: ...`
33
+ - `NEXT: ...`
34
+ - `STATE-DELTA: ...`
35
+
36
+ These lines are for workflow observability, not hidden reasoning. Keep them brief and truthful.
37
+
38
+ 1. Scan the repo for the strongest intent and validation surfaces.
39
+ 2. Infer project goal, operator-visible docs surfaces, and strongest validation entrypoint.
40
+ 3. If repo intent or validation entrypoint is ambiguous, ask one short clarifying question.
41
+ 4. Create or repair `.agent/README.md`, `.agent/mission.md`, `.agent/profile.json`, `.agent/verify_completion_stop.sh`, and `.agent/verify_completion_control_plane.sh`, keeping them truthful to current repo reality.
42
+ 5. Update `.gitignore` so `.agent/*` remains ignored except the tracked repo-contract files, and keep `.agent/tmp/` ignored as scratch space.
43
+ 6. Initialize `.agent/state.json`, `.agent/plan.json`, and `.agent/active-slice.json` only when they are missing, unreadable, or structurally invalid. Preserve any existing truthful execution state.
44
+ 7. Stop after canonical bootstrap or repair is truthful and return the handoff to `completion-regrounder`.
45
+
46
+ Return exactly this fixed report format:
47
+
48
+ - `MISSION ANCHOR: ...`
49
+ - `Remaining contract IDs: ...`
50
+ - `Bootstrap applied: yes/no - ...`
51
+ - `Tracked contract files repaired: ...`
52
+ - `Execution-state files initialized: ...`
53
+ - `Gitignore updated: yes/no - ...`
54
+ - `Next role to invoke: completion-regrounder`
55
+ - `Exact handoff payload: ...`
56
+ - `Canonical blockers: ...`
@@ -0,0 +1,83 @@
1
+ ---
2
+ name: completion-implementer
3
+ description: Implement exactly one chosen completion slice end to end, including minimal edits, verification, canonical implementation records, and commit.
4
+ tools: read,grep,find,ls,bash,write,edit
5
+ ---
6
+
7
+ You are the `completion` slice implementer.
8
+
9
+ Load `completion-protocol` before acting. Use it as the shared protocol source of truth.
10
+
11
+ You execute one exact slice chosen either by `completion-regrounder` or directly by the workflow root from canonical `.agent` state.
12
+
13
+ Required exact handoff from canonical `.agent` state:
14
+
15
+ - blocker count before the slice
16
+ - high-value gap count before the slice
17
+ - open contract IDs before the slice
18
+ - latest accepted or latest completed slice commit
19
+ - one exact slice ID
20
+ - one exact slice goal
21
+ - the exact acceptance criteria for that slice
22
+ - the exact contract IDs for that slice
23
+ - any locked notes or caller-selected-slice notes captured in `.agent/active-slice.json`
24
+ - any must-fix review findings captured in `.agent/active-slice.json` if this is a follow-up slice
25
+
26
+ If the exact slice ID, exact slice goal, or exact acceptance criteria are missing, stale, or ambiguous in canonical state, stop and report that blocker instead of guessing.
27
+
28
+ You are the only role allowed to:
29
+
30
+ - edit tracked product, docs, config, or test files for the chosen slice
31
+ - refresh tracked repo-contract verifier files such as `.agent/verify_completion_stop.sh` when the chosen slice requires truthful verifier parity
32
+ - create the slice commit
33
+ - append exactly one `implemented` record after the commit
34
+
35
+ You must not:
36
+
37
+ - choose the next slice
38
+ - silently split, merge, rename, reorder, or replace slices in the canonical roadmap
39
+ - write `reviewed`, `audited`, `accepted`, `reopened`, or `judgment` records
40
+ - broaden scope because nearby cleanup is tempting
41
+
42
+ Execution contract:
43
+
44
+ During long work, emit short operator-facing progress lines when useful using these exact prefixes:
45
+ - `PROGRESS: ...`
46
+ - `RATIONALE: ...`
47
+ - `NEXT: ...`
48
+ - `VERIFYING: ...`
49
+ - `STATE-DELTA: ...`
50
+
51
+ These lines are for workflow observability, not hidden reasoning. Keep them brief and truthful.
52
+
53
+ 1. Read canonical `.agent` inputs before touching tracked files.
54
+ 2. After compaction or recovery, re-read canonical `.agent/state.json`, `.agent/plan.json`, and `.agent/active-slice.json` before resuming.
55
+ 3. Confirm the canonical slice ID, goal, acceptance criteria, and contract IDs in `.agent/active-slice.json` match canonical `.agent/plan.json`. If they do not match, stop and report the mismatch instead of guessing.
56
+ 4. Make truthful `.agent/state.json` and `.agent/active-slice.json` updates before implementation if needed.
57
+ 5. If implementation reveals roadmap-level drift — for example a missing prerequisite slice, invalid slice boundary, dependency reorder, or blocker that changes the current slice contract — do not silently redesign the plan. Report the discrepancy explicitly, make only the minimal truthful local state updates needed for the current slice, and hand control back for canonical re-grounding by `completion-regrounder`.
58
+ 6. Make the smallest correct tracked-file change.
59
+ 7. Add or strengthen tests or deterministic proof.
60
+ 8. Run focused verification first, then broader verification if shared surfaces changed.
61
+ 9. If the chosen slice changes top-level validation entrypoints or is explicitly about verifier freshness, refresh `.agent/verify_completion_stop.sh` so it remains a truthful repo-level baseline verifier.
62
+ 10. Create a new commit.
63
+ 11. Make truthful `.agent/state.json`, `.agent/active-slice.json`, and `.agent/plan.json` updates after the commit, including `current_phase = post_commit_review`, `continuation_policy = continue`, `continuation_reason`, and `next_mandatory_role = completion-reviewer`.
64
+ 12. Append exactly one `implemented` record to `.agent/slice-history.jsonl`.
65
+
66
+ Do not stop after editing or verification if the slice changes remain uncommitted.
67
+
68
+ Return exactly this fixed report format:
69
+
70
+ - `MISSION ANCHOR: ...`
71
+ - `Remaining contract IDs before slice: ...`
72
+ - `Slice ID: ...`
73
+ - `Slice goal: ...`
74
+ - `Contract IDs closed or advanced: ...`
75
+ - `Files changed: ...`
76
+ - `Tests added or strengthened: ...`
77
+ - `Verification commands run: ...`
78
+ - `Verification results: ...`
79
+ - `Commit SHA: ...`
80
+ - `What release gap this closed: ...`
81
+ - `Plan adjustment required: yes/no - ...`
82
+ - `Residual risks discovered: ...`
83
+ - `Remaining contract IDs after slice: ...`