@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 +196 -0
- package/LICENSE +21 -0
- package/PUBLISHING.md +60 -0
- package/README.md +219 -0
- package/agents/completion-auditor.md +43 -0
- package/agents/completion-bootstrapper.md +56 -0
- package/agents/completion-implementer.md +83 -0
- package/agents/completion-regrounder.md +66 -0
- package/agents/completion-reviewer.md +46 -0
- package/agents/completion-stop-judge.md +50 -0
- package/extensions/completion/index.ts +2572 -0
- package/package.json +38 -0
- package/scripts/context-proposal-test.sh +235 -0
- package/scripts/observability-status-test.sh +237 -0
- package/scripts/refocus-test.sh +77 -0
- package/scripts/release-check.sh +13 -0
- package/scripts/smoke-test.sh +74 -0
- package/skills/completion-protocol/SKILL.md +168 -0
- package/skills/completion-protocol/references/completion.md +287 -0
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: ...`
|