@linimin/pi-letscook 0.1.28 → 0.1.30
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 +12 -0
- package/README.md +114 -119
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,17 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.1.30
|
|
4
|
+
|
|
5
|
+
### Changed
|
|
6
|
+
|
|
7
|
+
- clarified the README next-round example so the goal text no longer repeats `/cook` in a way that looks like part of the command syntax
|
|
8
|
+
|
|
9
|
+
## 0.1.29
|
|
10
|
+
|
|
11
|
+
### Changed
|
|
12
|
+
|
|
13
|
+
- tightened the README opening description so it correctly presents this package as a Pi extension that adds `/cook`, rather than implying `/cook` is built into Pi itself
|
|
14
|
+
|
|
3
15
|
## 0.1.28
|
|
4
16
|
|
|
5
17
|
### Changed
|
package/README.md
CHANGED
|
@@ -1,149 +1,141 @@
|
|
|
1
1
|
# @linimin/pi-letscook
|
|
2
2
|
|
|
3
|
-
Pi
|
|
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 through the proposal analyst when no active workflow is running
|
|
10
|
-
- model-assisted startup proposal analysis for natural recent discussion, with a live `/cook proposal analyst` overlay; if that analysis is unavailable, use `/cook <goal>` instead of a built-in discussion parser fallback
|
|
11
|
-
- `/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
|
|
12
|
-
- no duplicate prompt-template aliases for core workflow commands
|
|
13
|
-
- role-based isolated subprocess execution via `completion_role`
|
|
14
|
-
- completion widget sourced from canonical `.agent/**` state when no role is actively running, with no completion status line
|
|
15
|
-
- richer live role observability that keeps tool activity separate from role progress, rationale, next-step, verification, and state-delta output
|
|
16
|
-
- deterministic waiting/stalled signaling for running completion roles
|
|
17
|
-
- custom compaction continuity capsule
|
|
18
|
-
- canonical transcription of reviewer, auditor, regrounder, and stop-judge outputs
|
|
19
|
-
- repo-local verifier scripts and `.gitignore` wiring
|
|
3
|
+
A Pi extension that adds `/cook` for resumable long-running workflows backed by repo-local canonical state in `.agent/**`.
|
|
20
4
|
|
|
21
|
-
|
|
5
|
+
`@linimin/pi-letscook` is for work that does not fit in a single chat turn:
|
|
22
6
|
|
|
23
|
-
|
|
7
|
+
- start from a goal or from recent discussion
|
|
8
|
+
- resume later from repo-local workflow state
|
|
9
|
+
- refocus an active workflow without losing control of the mission
|
|
10
|
+
- drive implementation through isolated completion roles
|
|
11
|
+
- keep verification, review, audit, and stop checks tied to the repo
|
|
24
12
|
|
|
25
|
-
|
|
26
|
-
/cook build feature X end-to-end with tests and docs
|
|
27
|
-
```
|
|
13
|
+
## Why use it
|
|
28
14
|
|
|
29
|
-
|
|
15
|
+
Use this package when you want `/cook` to behave like a real project workflow command instead of a one-shot prompt.
|
|
30
16
|
|
|
31
|
-
|
|
32
|
-
/cook
|
|
33
|
-
```
|
|
17
|
+
It gives you:
|
|
34
18
|
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
If the previous workflow is already done and you want to start the next round from an explicit goal:
|
|
42
|
-
|
|
43
|
-
```text
|
|
44
|
-
/cook ship the next workflow round for richer /cook startup proposals
|
|
45
|
-
```
|
|
19
|
+
- **one command** for start, resume, and refocus
|
|
20
|
+
- **repo-local canonical state** under `.agent/**`
|
|
21
|
+
- **model-assisted startup proposals** from recent discussion
|
|
22
|
+
- **explicit-goal anchoring** when you want the mission to stay fixed
|
|
23
|
+
- **isolated completion roles** via `completion_role`
|
|
24
|
+
- **deterministic verification** through repo-local scripts and regression checks
|
|
46
25
|
|
|
47
26
|
## Install
|
|
48
27
|
|
|
49
|
-
### Try temporarily from a local checkout
|
|
50
|
-
|
|
51
28
|
```bash
|
|
52
|
-
pi
|
|
29
|
+
pi install npm:@linimin/pi-letscook
|
|
53
30
|
```
|
|
54
31
|
|
|
55
|
-
|
|
32
|
+
Then run `/reload` in Pi.
|
|
56
33
|
|
|
57
|
-
|
|
58
|
-
pi install /absolute/path/to/pi-letscook
|
|
59
|
-
```
|
|
34
|
+
## Quick start
|
|
60
35
|
|
|
61
|
-
|
|
36
|
+
Start from an explicit goal:
|
|
62
37
|
|
|
63
|
-
```
|
|
64
|
-
|
|
38
|
+
```text
|
|
39
|
+
/cook build feature X end-to-end with tests and docs
|
|
65
40
|
```
|
|
66
41
|
|
|
67
|
-
|
|
42
|
+
Resume an active workflow:
|
|
68
43
|
|
|
69
|
-
```
|
|
70
|
-
|
|
44
|
+
```text
|
|
45
|
+
/cook
|
|
71
46
|
```
|
|
72
47
|
|
|
73
|
-
|
|
48
|
+
Replace the active workflow with a different goal:
|
|
74
49
|
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
```bash
|
|
78
|
-
pi install git:github.com/linimin/pi-letscook
|
|
50
|
+
```text
|
|
51
|
+
/cook fix onboarding crash first, with regression tests
|
|
79
52
|
```
|
|
80
53
|
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
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.
|
|
54
|
+
Start the next round after the previous workflow is already done:
|
|
84
55
|
|
|
85
|
-
|
|
56
|
+
```text
|
|
57
|
+
/cook improve startup proposal confirmation UX
|
|
58
|
+
```
|
|
86
59
|
|
|
87
|
-
|
|
60
|
+
## How `/cook` behaves
|
|
88
61
|
|
|
89
|
-
`/cook` is the
|
|
62
|
+
`/cook` is the only public workflow command, but it behaves differently depending on the current canonical workflow state.
|
|
90
63
|
|
|
91
64
|
| Repo state | `/cook` | `/cook <goal>` |
|
|
92
65
|
|---|---|---|
|
|
93
|
-
| No canonical workflow yet |
|
|
94
|
-
| Active workflow exists | Resumes the active workflow from canonical `.agent/**` state | Asks whether to continue the current workflow or replace it
|
|
95
|
-
| Previous workflow is already `done` |
|
|
66
|
+
| No canonical workflow yet | Uses the proposal analyst to summarize recent discussion into a startup proposal, then asks for confirmation | Builds a startup proposal anchored on the explicit goal, optionally enriching it from recent discussion, then asks for confirmation |
|
|
67
|
+
| Active workflow exists | Resumes the active workflow from canonical `.agent/**` state | Asks whether to continue the current workflow or replace it |
|
|
68
|
+
| Previous workflow is already `done` | Uses the proposal analyst to summarize recent discussion into the next workflow round, then asks for confirmation | Starts the next workflow round directly from the explicit goal |
|
|
69
|
+
|
|
70
|
+
## Startup proposal behavior
|
|
71
|
+
|
|
72
|
+
### `/cook <goal>`
|
|
73
|
+
|
|
74
|
+
When you provide an explicit goal:
|
|
75
|
+
|
|
76
|
+
- the explicit goal stays the mission anchor
|
|
77
|
+
- recent discussion is supplemental only
|
|
78
|
+
- recent discussion may enrich scope, constraints, and acceptance details when analyst output is available
|
|
96
79
|
|
|
97
|
-
|
|
80
|
+
Example:
|
|
98
81
|
|
|
99
82
|
```text
|
|
100
83
|
/cook Build feature X with tests and docs
|
|
101
84
|
```
|
|
102
85
|
|
|
103
|
-
|
|
86
|
+
### `/cook` without a goal
|
|
104
87
|
|
|
105
|
-
When
|
|
88
|
+
When you do **not** provide a goal:
|
|
106
89
|
|
|
107
|
-
|
|
90
|
+
- `/cook` uses the proposal analyst to summarize recent discussion into a startup proposal
|
|
91
|
+
- the proposal is shown in a custom confirmation UI before canonical state is written
|
|
92
|
+
- if analyst output is unavailable, provide an explicit goal with `/cook <goal>`
|
|
93
|
+
|
|
94
|
+
Example:
|
|
108
95
|
|
|
109
96
|
```text
|
|
110
97
|
/cook
|
|
111
98
|
```
|
|
112
99
|
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
### Replace the active workflow
|
|
100
|
+
## Confirmation UI
|
|
116
101
|
|
|
117
|
-
|
|
118
|
-
/cook fix onboarding crash first, with regression tests
|
|
119
|
-
```
|
|
102
|
+
Startup confirmation uses a custom UI that:
|
|
120
103
|
|
|
121
|
-
|
|
104
|
+
- renders the proposal body separately from the action list
|
|
105
|
+
- keeps Mission / Scope / Constraints / Acceptance readable as a content area
|
|
106
|
+
- presents explicit actions for:
|
|
107
|
+
- **Start**
|
|
108
|
+
- **Edit**
|
|
109
|
+
- **Cancel**
|
|
122
110
|
|
|
123
|
-
|
|
124
|
-
- abandon the current workflow and start this new one
|
|
111
|
+
The same confirmation flow is reused across:
|
|
125
112
|
|
|
126
|
-
|
|
113
|
+
- discussion-only startup
|
|
114
|
+
- explicit-goal startup
|
|
115
|
+
- next-round startup after completion
|
|
116
|
+
- replacement-workflow startup
|
|
127
117
|
|
|
128
|
-
|
|
118
|
+
## Observability
|
|
129
119
|
|
|
130
|
-
|
|
131
|
-
/cook ship the next workflow round for richer /cook startup proposals
|
|
132
|
-
```
|
|
120
|
+
When canonical `.agent/**` state exists and no role is actively running, the extension shows a completion widget sourced from that state. The widget summarizes:
|
|
133
121
|
|
|
134
|
-
|
|
122
|
+
- current phase
|
|
123
|
+
- selected slice
|
|
124
|
+
- next mandatory role
|
|
125
|
+
- remaining work counts
|
|
135
126
|
|
|
136
|
-
|
|
127
|
+
There is no completion status line.
|
|
137
128
|
|
|
138
|
-
|
|
139
|
-
/cook
|
|
140
|
-
```
|
|
129
|
+
While a `completion_role` subprocess is running:
|
|
141
130
|
|
|
142
|
-
|
|
131
|
+
- the non-running widget is suppressed
|
|
132
|
+
- tool activity is shown separately from assistant-reported progress
|
|
133
|
+
- running-role output distinguishes tool work from `PROGRESS`, `RATIONALE`, `NEXT`, `VERIFYING`, and `STATE-DELTA`
|
|
134
|
+
- waiting and stalled states are surfaced deterministically from timestamps
|
|
143
135
|
|
|
144
|
-
## Canonical
|
|
136
|
+
## Canonical files
|
|
145
137
|
|
|
146
|
-
This package
|
|
138
|
+
This package stores canonical workflow state under:
|
|
147
139
|
|
|
148
140
|
```text
|
|
149
141
|
.agent/
|
|
@@ -160,43 +152,44 @@ This package manages repo-local canonical workflow state under:
|
|
|
160
152
|
tmp/
|
|
161
153
|
```
|
|
162
154
|
|
|
163
|
-
Canonical truth
|
|
155
|
+
Canonical truth is the combination of:
|
|
156
|
+
|
|
157
|
+
- current repo truth, and
|
|
158
|
+
- canonical `.agent/**` state
|
|
164
159
|
|
|
165
|
-
### Tracked vs ignored
|
|
160
|
+
### Tracked vs ignored files
|
|
166
161
|
|
|
167
|
-
|
|
162
|
+
Tracked repo-contract files:
|
|
168
163
|
|
|
169
|
-
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
- `.agent/verify_completion_control_plane.sh`
|
|
175
|
-
- **Ignored execution-state files** are local high-churn workflow state used for resume and recovery and should stay out of git:
|
|
176
|
-
- `.agent/state.json`
|
|
177
|
-
- `.agent/plan.json`
|
|
178
|
-
- `.agent/active-slice.json`
|
|
179
|
-
- `.agent/slice-history.jsonl`
|
|
180
|
-
- `.agent/stop-check-history.jsonl`
|
|
181
|
-
- `.agent/*.log`
|
|
182
|
-
- `.agent/tmp/`
|
|
164
|
+
- `.agent/README.md`
|
|
165
|
+
- `.agent/mission.md`
|
|
166
|
+
- `.agent/profile.json`
|
|
167
|
+
- `.agent/verify_completion_stop.sh`
|
|
168
|
+
- `.agent/verify_completion_control_plane.sh`
|
|
183
169
|
|
|
184
|
-
|
|
170
|
+
Ignored execution-state files:
|
|
185
171
|
|
|
186
|
-
|
|
172
|
+
- `.agent/state.json`
|
|
173
|
+
- `.agent/plan.json`
|
|
174
|
+
- `.agent/active-slice.json`
|
|
175
|
+
- `.agent/slice-history.jsonl`
|
|
176
|
+
- `.agent/stop-check-history.jsonl`
|
|
177
|
+
- `.agent/*.log`
|
|
178
|
+
- `.agent/tmp/`
|
|
187
179
|
|
|
188
|
-
|
|
180
|
+
In short:
|
|
189
181
|
|
|
190
|
-
|
|
182
|
+
- tracked `.agent` files define the repo-level workflow contract
|
|
183
|
+
- ignored `.agent` files are the local control-plane state for the current run
|
|
191
184
|
|
|
192
185
|
## Package layout
|
|
193
186
|
|
|
194
|
-
- `extensions/completion/index.ts` —
|
|
195
|
-
- `skills/completion-protocol/` — shared protocol
|
|
196
|
-
- `agents/completion-*.md` — package-local completion
|
|
197
|
-
- `scripts/` — smoke and release checks
|
|
187
|
+
- `extensions/completion/index.ts` — main extension implementation
|
|
188
|
+
- `skills/completion-protocol/` — shared protocol documentation
|
|
189
|
+
- `agents/completion-*.md` — package-local completion role prompts
|
|
190
|
+
- `scripts/` — smoke, regression, and release checks
|
|
198
191
|
|
|
199
|
-
## Development
|
|
192
|
+
## Development
|
|
200
193
|
|
|
201
194
|
Run validation from the package root:
|
|
202
195
|
|
|
@@ -208,13 +201,15 @@ npm run observability-status-test
|
|
|
208
201
|
npm run release-check
|
|
209
202
|
```
|
|
210
203
|
|
|
211
|
-
`npm run release-check` is the
|
|
204
|
+
`npm run release-check` is the broad packaged-release verifier. It reruns the startup/refocus/context checks, includes deterministic observability coverage, and finishes with `npm pack --dry-run`.
|
|
205
|
+
|
|
206
|
+
## Release
|
|
212
207
|
|
|
213
208
|
See [PUBLISHING.md](https://github.com/linimin/pi-letscook/blob/main/PUBLISHING.md) for GitHub and npm release steps.
|
|
214
209
|
|
|
215
210
|
## Notes
|
|
216
211
|
|
|
217
212
|
- Canonical truth lives in repo-local `.agent/**` files.
|
|
218
|
-
- The main
|
|
219
|
-
- Package-local role prompts are loaded directly by the extension
|
|
213
|
+
- The main Pi session is the workflow driver.
|
|
214
|
+
- Package-local role prompts are loaded directly by the extension and do not depend on `~/.pi/agent/agents`.
|
|
220
215
|
- Reviewer, auditor, and stop-judge are enforced as read-only roles.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@linimin/pi-letscook",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.30",
|
|
4
4
|
"description": "Pi package for long-running completion workflows with canonical .agent state, role-based subagents, continuity, and verification helpers.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"private": false,
|