maxsimcli 4.11.0 → 4.12.0
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/dist/assets/CHANGELOG.md +7 -0
- package/dist/assets/templates/workflows/plan-create.md +142 -54
- package/dist/assets/templates/workflows/plan-discuss.md +33 -35
- package/dist/assets/templates/workflows/plan-phase.md +18 -1
- package/dist/assets/templates/workflows/plan-research.md +36 -36
- package/dist/assets/templates/workflows/plan.md +67 -53
- package/package.json +1 -1
package/dist/assets/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
# [4.11.0](https://github.com/maystudios/maxsimcli/compare/v4.10.0...v4.11.0) (2026-03-11)
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
### Features
|
|
5
|
+
|
|
6
|
+
* **workflows:** wire mcp_github_setup and phase issue creation into init workflows ([fe30a97](https://github.com/maystudios/maxsimcli/commit/fe30a979957e9a480fc6e98bc9e60d51d2f428e2))
|
|
7
|
+
|
|
1
8
|
# [4.10.0](https://github.com/maystudios/maxsimcli/compare/v4.9.0...v4.10.0) (2026-03-11)
|
|
2
9
|
|
|
3
10
|
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
<purpose>
|
|
2
|
-
Planning stage sub-workflow for /maxsim:plan. Spawns the planner agent to create
|
|
2
|
+
Planning stage sub-workflow for /maxsim:plan. Spawns the planner agent to create plan content, posts plans to GitHub as comments on the phase issue, creates task sub-issues, and moves the phase board card to "In Progress". Optionally spawns the planner (in plan-checking mode) for verification with a revision loop.
|
|
3
3
|
|
|
4
|
-
This file is loaded by the plan.md orchestrator. It does NOT handle gate confirmations or stage routing -- the orchestrator handles that. This sub-workflow focuses ONLY on creating and
|
|
4
|
+
This file is loaded by the plan.md orchestrator. It does NOT handle gate confirmations or stage routing -- the orchestrator handles that. This sub-workflow focuses ONLY on creating, verifying, and publishing plans to GitHub.
|
|
5
5
|
</purpose>
|
|
6
6
|
|
|
7
7
|
<process>
|
|
@@ -15,6 +15,7 @@ The orchestrator provides phase context. Verify we have what we need:
|
|
|
15
15
|
- `commit_docs`
|
|
16
16
|
- `state_path`, `roadmap_path`, `requirements_path`, `context_path`, `research_path`
|
|
17
17
|
- `phase_req_ids` (requirement IDs that this phase must address)
|
|
18
|
+
- `phase_issue_number` (GitHub Issue number for the phase)
|
|
18
19
|
- `--skip-verify` flag presence
|
|
19
20
|
|
|
20
21
|
## Step 2: Resolve Models
|
|
@@ -26,38 +27,40 @@ CHECKER_MODEL=$(node .claude/maxsim/bin/maxsim-tools.cjs resolve-model planner -
|
|
|
26
27
|
|
|
27
28
|
## Step 3: Check Existing Plans
|
|
28
29
|
|
|
29
|
-
|
|
30
|
-
|
|
30
|
+
Query the phase GitHub Issue for existing plan comments:
|
|
31
|
+
```
|
|
32
|
+
mcp_get_issue_detail(issue_number={phase_issue_number})
|
|
31
33
|
```
|
|
32
34
|
|
|
33
|
-
|
|
35
|
+
Look for comments that contain `<!-- maxsim:type=plan -->`.
|
|
36
|
+
|
|
37
|
+
**If plan comment(s) exist:** Offer options via natural conversation:
|
|
34
38
|
```
|
|
35
|
-
Phase {phase_number} already has plan(s)
|
|
36
|
-
{list of existing plan files}
|
|
39
|
+
Phase {phase_number} already has plan(s) on GitHub Issue #{phase_issue_number}.
|
|
37
40
|
|
|
38
41
|
1. Add more plans (keep existing)
|
|
39
42
|
2. View existing plans
|
|
40
|
-
3. Re-plan from scratch (deletes existing
|
|
43
|
+
3. Re-plan from scratch (deletes existing plan comments)
|
|
41
44
|
```
|
|
42
45
|
|
|
43
46
|
- If "Add more": Continue to Step 4 with existing plans preserved.
|
|
44
|
-
- If "View": Display plan
|
|
45
|
-
- If "Re-plan": Delete existing
|
|
47
|
+
- If "View": Display plan comment contents, then re-offer options.
|
|
48
|
+
- If "Re-plan": Delete existing plan comments from the issue, continue to Step 4.
|
|
46
49
|
|
|
47
|
-
**If no
|
|
50
|
+
**If no plan comments exist:** Continue to Step 4.
|
|
48
51
|
|
|
49
52
|
## Step 4: Gather Context Paths
|
|
50
53
|
|
|
51
|
-
Extract file paths from the orchestrator context (provided via init JSON):
|
|
54
|
+
Extract file paths and GitHub context from the orchestrator context (provided via init JSON):
|
|
52
55
|
|
|
53
56
|
```bash
|
|
54
57
|
STATE_PATH=$(echo "$INIT" | jq -r '.state_path // empty')
|
|
55
58
|
ROADMAP_PATH=$(echo "$INIT" | jq -r '.roadmap_path // empty')
|
|
56
59
|
REQUIREMENTS_PATH=$(echo "$INIT" | jq -r '.requirements_path // empty')
|
|
57
|
-
RESEARCH_PATH=$(echo "$INIT" | jq -r '.research_path // empty')
|
|
58
|
-
CONTEXT_PATH=$(echo "$INIT" | jq -r '.context_path // empty')
|
|
59
60
|
```
|
|
60
61
|
|
|
62
|
+
Context and research content will be read from GitHub Issue #{phase_issue_number} comments (identified by `<!-- maxsim:type=context -->` and `<!-- maxsim:type=research -->` markers) rather than from local files.
|
|
63
|
+
|
|
61
64
|
## Step 5: Spawn Planner
|
|
62
65
|
|
|
63
66
|
Display:
|
|
@@ -65,20 +68,20 @@ Display:
|
|
|
65
68
|
Planning Phase {phase_number}: {phase_name}...
|
|
66
69
|
```
|
|
67
70
|
|
|
68
|
-
Construct the planner prompt:
|
|
71
|
+
Construct the planner prompt. The planner must return plan content as structured markdown in its response (not write local files):
|
|
69
72
|
|
|
70
73
|
```markdown
|
|
71
74
|
<planning_context>
|
|
72
75
|
**Phase:** {phase_number}
|
|
73
76
|
**Mode:** standard
|
|
74
77
|
|
|
75
|
-
<
|
|
78
|
+
<context_sources>
|
|
79
|
+
- GitHub Issue #{phase_issue_number} context comment (USER DECISIONS -- locked choices from discussion stage)
|
|
80
|
+
- GitHub Issue #{phase_issue_number} research comment (Technical Research findings)
|
|
76
81
|
- {state_path} (Project State)
|
|
77
82
|
- {roadmap_path} (Roadmap)
|
|
78
83
|
- {requirements_path} (Requirements)
|
|
79
|
-
|
|
80
|
-
- {research_path} (Technical Research)
|
|
81
|
-
</files_to_read>
|
|
84
|
+
</context_sources>
|
|
82
85
|
|
|
83
86
|
**Phase requirement IDs (every ID MUST appear in a plan's `requirements` field):** {phase_req_ids}
|
|
84
87
|
|
|
@@ -87,16 +90,31 @@ Construct the planner prompt:
|
|
|
87
90
|
</planning_context>
|
|
88
91
|
|
|
89
92
|
<downstream_consumer>
|
|
90
|
-
Output consumed by /maxsim:execute. Plans need:
|
|
93
|
+
Output consumed by /maxsim:execute via GitHub Issue comments. Plans need:
|
|
91
94
|
- Frontmatter (wave, depends_on, files_modified, autonomous)
|
|
92
95
|
- Tasks in XML format
|
|
93
96
|
- Verification criteria
|
|
94
97
|
- must_haves for goal-backward verification
|
|
95
98
|
</downstream_consumer>
|
|
96
99
|
|
|
100
|
+
<output_format>
|
|
101
|
+
Return each plan as a separate fenced code block with a plan number header.
|
|
102
|
+
Do NOT write local PLAN.md files -- plans will be posted to GitHub by the orchestrator.
|
|
103
|
+
|
|
104
|
+
Example structure:
|
|
105
|
+
## Plan 01
|
|
106
|
+
|
|
107
|
+
```yaml
|
|
108
|
+
# frontmatter here
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
<tasks>
|
|
112
|
+
...
|
|
113
|
+
</tasks>
|
|
114
|
+
</output_format>
|
|
115
|
+
|
|
97
116
|
<quality_gate>
|
|
98
|
-
- [ ]
|
|
99
|
-
- [ ] Each plan has valid frontmatter
|
|
117
|
+
- [ ] Each plan returned in response with valid frontmatter
|
|
100
118
|
- [ ] Tasks are specific and actionable
|
|
101
119
|
- [ ] Dependencies correctly identified
|
|
102
120
|
- [ ] Waves assigned for parallel execution
|
|
@@ -120,18 +138,16 @@ Task(
|
|
|
120
138
|
Parse the planner's return message:
|
|
121
139
|
|
|
122
140
|
- **`## PLANNING COMPLETE`:**
|
|
123
|
-
|
|
124
|
-
```bash
|
|
125
|
-
ls "${phase_dir}"/*-PLAN.md 2>/dev/null | wc -l
|
|
126
|
-
```
|
|
141
|
+
Extract the plan content from the planner's response. Parse out individual plans (each is a separate fenced block with a plan number header).
|
|
127
142
|
|
|
128
|
-
If plans found:
|
|
129
|
-
- Display plan count
|
|
143
|
+
If plans found in response:
|
|
144
|
+
- Display plan count.
|
|
145
|
+
- Store plans in memory as `plans_content` array.
|
|
130
146
|
- If `--skip-verify` flag is set OR `plan_checker_enabled` is false: skip to Step 9.
|
|
131
147
|
- Otherwise: continue to Step 7 (verification).
|
|
132
148
|
|
|
133
|
-
If no plans
|
|
134
|
-
- Error: "Planner reported complete but no
|
|
149
|
+
If no plans in response:
|
|
150
|
+
- Error: "Planner reported complete but returned no plan content."
|
|
135
151
|
- Offer: retry or abort.
|
|
136
152
|
|
|
137
153
|
- **`## CHECKPOINT REACHED`:**
|
|
@@ -157,20 +173,23 @@ Display:
|
|
|
157
173
|
Verifying plans...
|
|
158
174
|
```
|
|
159
175
|
|
|
160
|
-
Construct the checker prompt:
|
|
176
|
+
Construct the checker prompt. Pass the in-memory `plans_content` directly:
|
|
161
177
|
|
|
162
178
|
```markdown
|
|
163
179
|
<verification_context>
|
|
164
180
|
**Phase:** {phase_number}
|
|
165
181
|
**Phase Goal:** {goal from ROADMAP}
|
|
166
182
|
|
|
167
|
-
<
|
|
168
|
-
|
|
183
|
+
<plans_to_verify>
|
|
184
|
+
{plans_content -- the plan(s) returned by the planner in step 5}
|
|
185
|
+
</plans_to_verify>
|
|
186
|
+
|
|
187
|
+
<context_sources>
|
|
188
|
+
- GitHub Issue #{phase_issue_number} context comment (USER DECISIONS)
|
|
189
|
+
- GitHub Issue #{phase_issue_number} research comment (Technical Research)
|
|
169
190
|
- {roadmap_path} (Roadmap)
|
|
170
191
|
- {requirements_path} (Requirements)
|
|
171
|
-
|
|
172
|
-
- {research_path} (Technical Research)
|
|
173
|
-
</files_to_read>
|
|
192
|
+
</context_sources>
|
|
174
193
|
|
|
175
194
|
**Phase requirement IDs (MUST ALL be covered):** {phase_req_ids}
|
|
176
195
|
|
|
@@ -214,17 +233,20 @@ Task(
|
|
|
214
233
|
Sending plans back for revision... (iteration {iteration_count}/3)
|
|
215
234
|
```
|
|
216
235
|
|
|
217
|
-
Construct revision prompt:
|
|
236
|
+
Construct revision prompt. Pass the current in-memory `plans_content` directly:
|
|
218
237
|
|
|
219
238
|
```markdown
|
|
220
239
|
<revision_context>
|
|
221
240
|
**Phase:** {phase_number}
|
|
222
241
|
**Mode:** revision
|
|
223
242
|
|
|
224
|
-
<
|
|
225
|
-
-
|
|
226
|
-
|
|
227
|
-
|
|
243
|
+
<existing_plans>
|
|
244
|
+
{plans_content -- current in-memory plan content}
|
|
245
|
+
</existing_plans>
|
|
246
|
+
|
|
247
|
+
<context_sources>
|
|
248
|
+
- GitHub Issue #{phase_issue_number} context comment (USER DECISIONS)
|
|
249
|
+
</context_sources>
|
|
228
250
|
|
|
229
251
|
**Checker issues:** {structured_issues_from_checker}
|
|
230
252
|
</revision_context>
|
|
@@ -232,7 +254,7 @@ Task(
|
|
|
232
254
|
<instructions>
|
|
233
255
|
Make targeted updates to address checker issues.
|
|
234
256
|
Do NOT replan from scratch unless issues are fundamental.
|
|
235
|
-
Return
|
|
257
|
+
Return the full revised plan content (same format as original -- one fenced block per plan).
|
|
236
258
|
</instructions>
|
|
237
259
|
```
|
|
238
260
|
|
|
@@ -267,32 +289,98 @@ Task(
|
|
|
267
289
|
- If "Provide guidance": Get user input, re-spawn planner with user guidance, reset iteration_count, go to Step 7.
|
|
268
290
|
- If "Abort": Exit workflow.
|
|
269
291
|
|
|
270
|
-
## Step 9:
|
|
292
|
+
## Step 9: Post Plans to GitHub
|
|
271
293
|
|
|
272
|
-
|
|
294
|
+
After verification passes (or is skipped), post each plan as a separate comment on the phase GitHub Issue.
|
|
273
295
|
|
|
274
|
-
|
|
275
|
-
|
|
296
|
+
For each plan in `plans_content`:
|
|
297
|
+
|
|
298
|
+
```
|
|
299
|
+
mcp_post_plan_comment(
|
|
300
|
+
phase_issue_number={phase_issue_number},
|
|
301
|
+
plan_number={plan_number}, // e.g. "01", "02"
|
|
302
|
+
plan_content="<!-- maxsim:type=plan -->\n" + {plan_content}
|
|
303
|
+
)
|
|
304
|
+
```
|
|
305
|
+
|
|
306
|
+
If posting any plan comment fails:
|
|
307
|
+
- Report which plans failed to post.
|
|
308
|
+
- Offer retry for failed plans.
|
|
309
|
+
- Do not proceed to task creation until all plans are successfully posted.
|
|
310
|
+
|
|
311
|
+
Display:
|
|
312
|
+
```
|
|
313
|
+
Plans posted to GitHub Issue #{phase_issue_number}: {plan_count} plan(s).
|
|
314
|
+
```
|
|
315
|
+
|
|
316
|
+
## Step 10: Create Task Sub-Issues
|
|
317
|
+
|
|
318
|
+
Parse tasks from the posted plans. For each `<task>` element in the plan XML, extract:
|
|
319
|
+
- `id` (e.g. "1.1", "1.2")
|
|
320
|
+
- `title`
|
|
321
|
+
- `description` / body content
|
|
322
|
+
|
|
323
|
+
Call `mcp_batch_create_tasks` with the full tasks array and the phase issue number:
|
|
324
|
+
|
|
325
|
+
```
|
|
326
|
+
mcp_batch_create_tasks(
|
|
327
|
+
phase_issue_number={phase_issue_number},
|
|
328
|
+
tasks=[
|
|
329
|
+
{ id: "1.1", title: "Task title", description: "Task body" },
|
|
330
|
+
...
|
|
331
|
+
]
|
|
332
|
+
)
|
|
333
|
+
```
|
|
334
|
+
|
|
335
|
+
Each task becomes a GitHub sub-issue linked to the phase issue.
|
|
336
|
+
|
|
337
|
+
**If batch creation fails (partial or total):**
|
|
338
|
+
- Report which task IDs failed to create.
|
|
339
|
+
- Offer: retry failed tasks, skip and continue, or abort.
|
|
340
|
+
- Do not proceed to board transition until task creation succeeds or user accepts partial failure.
|
|
341
|
+
|
|
342
|
+
Display:
|
|
343
|
+
```
|
|
344
|
+
Task sub-issues created: {task_count} tasks linked to Issue #{phase_issue_number}.
|
|
345
|
+
```
|
|
346
|
+
|
|
347
|
+
## Step 11: Move Phase to In Progress
|
|
348
|
+
|
|
349
|
+
After all plans are posted and task sub-issues are created, move the phase issue to "In Progress" on the project board:
|
|
350
|
+
|
|
351
|
+
```
|
|
352
|
+
mcp_move_issue(
|
|
353
|
+
issue_number={phase_issue_number},
|
|
354
|
+
status="In Progress"
|
|
355
|
+
)
|
|
356
|
+
```
|
|
357
|
+
|
|
358
|
+
Display:
|
|
359
|
+
```
|
|
360
|
+
Phase #{phase_issue_number} moved to "In Progress" on the board.
|
|
276
361
|
```
|
|
277
362
|
|
|
278
|
-
## Step
|
|
363
|
+
## Step 12: Return to Orchestrator
|
|
279
364
|
|
|
280
|
-
After plans are created and
|
|
365
|
+
After plans are posted, task sub-issues created, and the phase moved to "In Progress", return control to the plan.md orchestrator. Do NOT show gate confirmation or next steps -- the orchestrator handles the final gate.
|
|
281
366
|
|
|
282
367
|
Display a brief completion message:
|
|
283
368
|
```
|
|
284
|
-
Planning complete. {plan_count} plan(s)
|
|
369
|
+
Planning complete. {plan_count} plan(s) posted to GitHub Issue #{phase_issue_number}. {task_count} task sub-issues created.
|
|
285
370
|
```
|
|
286
371
|
|
|
287
372
|
</process>
|
|
288
373
|
|
|
289
374
|
<success_criteria>
|
|
290
375
|
- Planner and checker models resolved from config
|
|
291
|
-
- Existing plans detected and handled (add/view/replan options)
|
|
292
|
-
- Planner agent spawned with
|
|
293
|
-
- PLAN.md files
|
|
376
|
+
- Existing plans detected from GitHub Issue comments and handled (add/view/replan options)
|
|
377
|
+
- Planner agent spawned with context from GitHub Issue comments (context + research) and local files (state, roadmap, requirements)
|
|
378
|
+
- Plan content returned from planner as in-memory document (no local PLAN.md files written)
|
|
294
379
|
- Checker verification loop runs (max 3 iterations) unless --skip-verify
|
|
295
|
-
- Revision loop
|
|
296
|
-
-
|
|
380
|
+
- Revision loop passes in-memory plan content to planner for targeted fixes
|
|
381
|
+
- Plans posted to GitHub Issue #{phase_issue_number} as comments with <!-- maxsim:type=plan --> markers
|
|
382
|
+
- Task sub-issues created via mcp_batch_create_tasks linked to phase issue
|
|
383
|
+
- Phase issue moved to "In Progress" via mcp_move_issue
|
|
384
|
+
- Failed task creation surfaced with retry option (WIRE-07)
|
|
297
385
|
- Control returned to orchestrator without showing gate or next steps
|
|
298
386
|
</success_criteria>
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
<purpose>
|
|
2
2
|
Discussion stage sub-workflow for /maxsim:plan. Extracts implementation decisions that downstream agents (researcher, planner) need. Analyzes the phase to identify gray areas, lets the user choose what to discuss, then deep-dives each selected area until satisfied.
|
|
3
3
|
|
|
4
|
-
This file is loaded by the plan.md orchestrator. It does NOT handle gate confirmations or stage routing -- the orchestrator handles that. This sub-workflow focuses ONLY on running the discussion and
|
|
4
|
+
This file is loaded by the plan.md orchestrator. It does NOT handle gate confirmations or stage routing -- the orchestrator handles that. This sub-workflow focuses ONLY on running the discussion and posting the context decisions to GitHub.
|
|
5
5
|
|
|
6
6
|
You are a thinking partner, not an interviewer. The user is the visionary -- you are the builder. Your job is to capture decisions that will guide research and planning, not to figure out implementation yourself.
|
|
7
7
|
</purpose>
|
|
@@ -11,13 +11,13 @@ You are a thinking partner, not an interviewer. The user is the visionary -- you
|
|
|
11
11
|
</required_reading>
|
|
12
12
|
|
|
13
13
|
<downstream_awareness>
|
|
14
|
-
**
|
|
14
|
+
**Context decisions (posted to GitHub) feed into:**
|
|
15
15
|
|
|
16
|
-
1. **researcher** -- Reads
|
|
16
|
+
1. **researcher** -- Reads context comment to know WHAT to research
|
|
17
17
|
- "User wants card-based layout" -> researcher investigates card component patterns
|
|
18
18
|
- "Infinite scroll decided" -> researcher looks into virtualization libraries
|
|
19
19
|
|
|
20
|
-
2. **planner** -- Reads
|
|
20
|
+
2. **planner** -- Reads context comment to know WHAT decisions are locked
|
|
21
21
|
- "Pull-to-refresh on mobile" -> planner includes that in task specs
|
|
22
22
|
- "Claude's Discretion: loading skeleton" -> planner can decide approach
|
|
23
23
|
|
|
@@ -125,7 +125,7 @@ Phase: "API documentation"
|
|
|
125
125
|
|
|
126
126
|
## Step 1: Initialize
|
|
127
127
|
|
|
128
|
-
Phase number, name, and
|
|
128
|
+
Phase number, name, directory, and GitHub issue number come from the orchestrator context.
|
|
129
129
|
|
|
130
130
|
```bash
|
|
131
131
|
INIT=$(node .claude/maxsim/bin/maxsim-tools.cjs init phase-op "${PHASE}")
|
|
@@ -133,31 +133,34 @@ INIT=$(node .claude/maxsim/bin/maxsim-tools.cjs init phase-op "${PHASE}")
|
|
|
133
133
|
|
|
134
134
|
Parse JSON for: `commit_docs`, `phase_found`, `phase_dir`, `phase_number`, `phase_name`, `phase_slug`, `padded_phase`, `has_research`, `has_context`, `has_plans`, `plan_count`, `roadmap_exists`, `planning_exists`.
|
|
135
135
|
|
|
136
|
+
Also extract `phase_issue_number` passed from the orchestrator.
|
|
137
|
+
|
|
136
138
|
**If `phase_found` is false:** Error -- the orchestrator should have caught this, but fail safe.
|
|
137
139
|
|
|
138
140
|
## Step 2: Check Existing Context
|
|
139
141
|
|
|
140
|
-
Check if
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
ls ${phase_dir}/*-CONTEXT.md 2>/dev/null
|
|
142
|
+
Check if a context comment already exists on the phase GitHub Issue by calling:
|
|
143
|
+
```
|
|
144
|
+
mcp_get_issue_detail(issue_number={phase_issue_number})
|
|
144
145
|
```
|
|
145
146
|
|
|
146
|
-
|
|
147
|
+
Look for a comment that contains `<!-- maxsim:type=context -->`.
|
|
148
|
+
|
|
149
|
+
**If a context comment exists:**
|
|
147
150
|
|
|
148
151
|
Ask the user (via natural conversation):
|
|
149
152
|
```
|
|
150
|
-
Phase {phase_number} already has context. What would you like to do?
|
|
153
|
+
Phase {phase_number} already has context on GitHub Issue #{phase_issue_number}. What would you like to do?
|
|
151
154
|
1. Update it -- review and revise existing context
|
|
152
155
|
2. View it -- show me what's there
|
|
153
156
|
3. Use as-is -- keep existing context and return to orchestrator
|
|
154
157
|
```
|
|
155
158
|
|
|
156
|
-
- If "Update": Load existing
|
|
157
|
-
- If "View": Display
|
|
159
|
+
- If "Update": Load existing context comment content, continue to Step 3.
|
|
160
|
+
- If "View": Display context comment contents, then offer update/use-as-is.
|
|
158
161
|
- If "Use as-is": Return control to orchestrator.
|
|
159
162
|
|
|
160
|
-
**If
|
|
163
|
+
**If no context comment exists:** Continue to Step 3.
|
|
161
164
|
|
|
162
165
|
## Step 3: Analyze Phase
|
|
163
166
|
|
|
@@ -264,24 +267,14 @@ Back to [current area]: [return to current question]"
|
|
|
264
267
|
Track deferred ideas internally.
|
|
265
268
|
</process>
|
|
266
269
|
|
|
267
|
-
## Step 6:
|
|
268
|
-
|
|
269
|
-
Create CONTEXT.md capturing decisions made.
|
|
270
|
+
## Step 6: Post Context to GitHub
|
|
270
271
|
|
|
271
|
-
|
|
272
|
-
|
|
273
|
-
Use values from init: `phase_dir`, `phase_slug`, `padded_phase`.
|
|
274
|
-
|
|
275
|
-
If `phase_dir` is null (phase exists in roadmap but no directory):
|
|
276
|
-
```bash
|
|
277
|
-
mkdir -p ".planning/phases/${padded_phase}-${phase_slug}"
|
|
278
|
-
```
|
|
279
|
-
|
|
280
|
-
**File location:** `${phase_dir}/${padded_phase}-CONTEXT.md`
|
|
272
|
+
Build the context content in memory, then post it as a comment on the phase GitHub Issue.
|
|
281
273
|
|
|
282
274
|
**Structure the content by what was discussed:**
|
|
283
275
|
|
|
284
276
|
```markdown
|
|
277
|
+
<!-- maxsim:type=context -->
|
|
285
278
|
# Phase {X} Context: {Name}
|
|
286
279
|
|
|
287
280
|
**Phase Goal:** {goal from ROADMAP.md}
|
|
@@ -319,20 +312,24 @@ mkdir -p ".planning/phases/${padded_phase}-${phase_slug}"
|
|
|
319
312
|
*Decisions: {N} across {M} areas*
|
|
320
313
|
```
|
|
321
314
|
|
|
322
|
-
|
|
323
|
-
|
|
324
|
-
|
|
325
|
-
|
|
326
|
-
|
|
315
|
+
Post the comment to GitHub:
|
|
316
|
+
```
|
|
317
|
+
mcp_post_comment(
|
|
318
|
+
issue_number={phase_issue_number},
|
|
319
|
+
type="context",
|
|
320
|
+
content={context_content_above}
|
|
321
|
+
)
|
|
327
322
|
```
|
|
328
323
|
|
|
324
|
+
Context decisions are posted as a GitHub comment on phase issue #{phase_issue_number}. No local CONTEXT.md file is written.
|
|
325
|
+
|
|
329
326
|
## Step 7: Return to Orchestrator
|
|
330
327
|
|
|
331
|
-
After
|
|
328
|
+
After posting the context comment to GitHub, return control to the plan.md orchestrator. Do NOT show gate confirmation or next steps -- the orchestrator handles the gate between Discussion and Research.
|
|
332
329
|
|
|
333
330
|
Display a brief completion message:
|
|
334
331
|
```
|
|
335
|
-
Discussion complete.
|
|
332
|
+
Discussion complete. Context decisions posted to GitHub Issue #{phase_issue_number}.
|
|
336
333
|
```
|
|
337
334
|
|
|
338
335
|
<success_criteria>
|
|
@@ -341,7 +338,8 @@ Discussion complete. CONTEXT.md written to {path}.
|
|
|
341
338
|
- User selected which areas to discuss
|
|
342
339
|
- Each selected area explored until user satisfied
|
|
343
340
|
- Scope creep redirected to deferred ideas
|
|
344
|
-
-
|
|
341
|
+
- Context comment captures actual decisions (not vague vision) with <!-- maxsim:type=context --> marker
|
|
342
|
+
- Context posted to GitHub Issue #{phase_issue_number} as a comment (no local CONTEXT.md written)
|
|
345
343
|
- Deferred ideas preserved for future phases
|
|
346
344
|
- Control returned to orchestrator without showing gate or next steps
|
|
347
345
|
</success_criteria>
|
|
@@ -4,8 +4,25 @@ Before executing any step in this workflow, verify:
|
|
|
4
4
|
2. `.planning/ROADMAP.md` exists — if not, stop and tell the user to initialize the project.
|
|
5
5
|
</sanity_check>
|
|
6
6
|
|
|
7
|
+
<deprecation_notice>
|
|
8
|
+
**DEPRECATED — Use plan.md + sub-workflows instead.**
|
|
9
|
+
|
|
10
|
+
This file (plan-phase.md) is a legacy monolithic workflow that writes artifacts to local `.planning/phases/` directories. It has been superseded by the GitHub-first planning workflow:
|
|
11
|
+
|
|
12
|
+
- **Canonical orchestrator:** `@./workflows/plan.md`
|
|
13
|
+
- **Discussion stage:** `@./workflows/plan-discuss.md`
|
|
14
|
+
- **Research stage:** `@./workflows/plan-research.md`
|
|
15
|
+
- **Planning stage:** `@./workflows/plan-create.md`
|
|
16
|
+
|
|
17
|
+
The canonical workflow stores all artifacts (context decisions, research findings, plans) as GitHub Issue comments instead of local files, and uses GitHub Issue state for stage detection and re-entry.
|
|
18
|
+
|
|
19
|
+
**This file is retained for reference only.** Do not use it for new work. Any fixes or improvements should be made to the canonical sub-workflows above.
|
|
20
|
+
</deprecation_notice>
|
|
21
|
+
|
|
7
22
|
<purpose>
|
|
8
|
-
Create executable phase prompts (PLAN.md files) for a roadmap phase with integrated research and verification. Default flow: Research (if needed) -> Plan -> Verify -> Done. Orchestrates researcher, planner, and planner (plan-checking mode) agents with a revision loop (max 3 iterations).
|
|
23
|
+
[LEGACY] Create executable phase prompts (PLAN.md files) for a roadmap phase with integrated research and verification. Default flow: Research (if needed) -> Plan -> Verify -> Done. Orchestrates researcher, planner, and planner (plan-checking mode) agents with a revision loop (max 3 iterations).
|
|
24
|
+
|
|
25
|
+
NOTE: This workflow writes artifacts to local `.planning/phases/` directories. The current canonical workflow (plan.md + sub-workflows) stores artifacts on GitHub Issues instead.
|
|
9
26
|
</purpose>
|
|
10
27
|
|
|
11
28
|
<required_reading>
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
<purpose>
|
|
2
|
-
Research stage sub-workflow for /maxsim:plan. Spawns the researcher agent with phase context to produce
|
|
2
|
+
Research stage sub-workflow for /maxsim:plan. Spawns the researcher agent with phase context to produce research findings, then posts them to GitHub as a comment on the phase issue.
|
|
3
3
|
|
|
4
|
-
This file is loaded by the plan.md orchestrator. It does NOT handle gate confirmations or stage routing -- the orchestrator handles that. This sub-workflow focuses ONLY on running research and
|
|
4
|
+
This file is loaded by the plan.md orchestrator. It does NOT handle gate confirmations or stage routing -- the orchestrator handles that. This sub-workflow focuses ONLY on running research and posting the output to GitHub.
|
|
5
5
|
</purpose>
|
|
6
6
|
|
|
7
7
|
<process>
|
|
@@ -12,9 +12,10 @@ The orchestrator provides phase context. Verify we have what we need:
|
|
|
12
12
|
|
|
13
13
|
- `phase_number`, `phase_name`, `phase_dir`, `padded_phase`, `phase_slug`
|
|
14
14
|
- `researcher_model`, `research_enabled`
|
|
15
|
-
- `has_research` (whether
|
|
15
|
+
- `has_research` (whether a research comment already exists on the phase issue)
|
|
16
16
|
- `state_path`, `roadmap_path`, `requirements_path`, `context_path`
|
|
17
17
|
- `phase_req_ids` (requirement IDs that this phase must address)
|
|
18
|
+
- `phase_issue_number` (GitHub Issue number for the phase)
|
|
18
19
|
- `--force-research` flag presence
|
|
19
20
|
|
|
20
21
|
## Step 2: Resolve Researcher Model
|
|
@@ -25,18 +26,20 @@ RESEARCHER_MODEL=$(node .claude/maxsim/bin/maxsim-tools.cjs resolve-model resear
|
|
|
25
26
|
|
|
26
27
|
## Step 3: Check Existing Research
|
|
27
28
|
|
|
29
|
+
Determine whether a research comment already exists on the phase GitHub Issue by checking for a comment containing `<!-- maxsim:type=research -->`. This is reflected in the `has_research` flag passed from the orchestrator (which performs the GitHub query).
|
|
30
|
+
|
|
28
31
|
**If `has_research` is true AND `--force-research` is NOT set:**
|
|
29
32
|
|
|
30
|
-
Research already exists. Display:
|
|
33
|
+
Research already exists as a GitHub comment on Issue #{phase_issue_number}. Display:
|
|
31
34
|
```
|
|
32
|
-
Using existing research from
|
|
35
|
+
Using existing research from GitHub Issue #{phase_issue_number}.
|
|
33
36
|
```
|
|
34
37
|
|
|
35
38
|
Return control to orchestrator -- no need to re-research.
|
|
36
39
|
|
|
37
40
|
**If `has_research` is true AND `--force-research` IS set:**
|
|
38
41
|
|
|
39
|
-
Continue to Step 4 (re-research will
|
|
42
|
+
Continue to Step 4 (re-research will post a new research comment, replacing the old one).
|
|
40
43
|
|
|
41
44
|
**If `has_research` is false:**
|
|
42
45
|
|
|
@@ -67,7 +70,7 @@ Display:
|
|
|
67
70
|
Researching Phase {phase_number}: {phase_name}...
|
|
68
71
|
```
|
|
69
72
|
|
|
70
|
-
Construct the research prompt:
|
|
73
|
+
Construct the research prompt. The researcher must return its findings as a structured markdown document (not write to a local file -- the orchestrator will post findings to GitHub):
|
|
71
74
|
|
|
72
75
|
```markdown
|
|
73
76
|
<objective>
|
|
@@ -76,7 +79,7 @@ Answer: "What do I need to know to PLAN this phase well?"
|
|
|
76
79
|
</objective>
|
|
77
80
|
|
|
78
81
|
<files_to_read>
|
|
79
|
-
- {
|
|
82
|
+
- GitHub Issue #{phase_issue_number} context comment (USER DECISIONS -- locked choices that constrain research)
|
|
80
83
|
- {requirements_path} (Project requirements)
|
|
81
84
|
- {state_path} (Project decisions and history)
|
|
82
85
|
</files_to_read>
|
|
@@ -90,7 +93,8 @@ Answer: "What do I need to know to PLAN this phase well?"
|
|
|
90
93
|
</additional_context>
|
|
91
94
|
|
|
92
95
|
<output>
|
|
93
|
-
|
|
96
|
+
Return findings as a structured markdown document in your response.
|
|
97
|
+
Do NOT write to a local file -- findings will be posted to GitHub by the orchestrator.
|
|
94
98
|
</output>
|
|
95
99
|
```
|
|
96
100
|
|
|
@@ -110,30 +114,25 @@ Task(
|
|
|
110
114
|
Parse the researcher's return message:
|
|
111
115
|
|
|
112
116
|
- **`## RESEARCH COMPLETE`:**
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
117
|
+
Extract the research findings document from the researcher's response.
|
|
118
|
+
|
|
119
|
+
Post research findings to GitHub:
|
|
120
|
+
```
|
|
121
|
+
mcp_post_comment(
|
|
122
|
+
issue_number={phase_issue_number},
|
|
123
|
+
type="research",
|
|
124
|
+
content="<!-- maxsim:type=research -->\n" + {research_findings_document}
|
|
125
|
+
)
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
Research findings are posted as a GitHub comment on phase issue #{phase_issue_number}. No local RESEARCH.md file is written.
|
|
129
|
+
|
|
130
|
+
Display confirmation:
|
|
131
|
+
```
|
|
132
|
+
Research complete. Findings posted to GitHub Issue #{phase_issue_number}.
|
|
116
133
|
```
|
|
117
134
|
|
|
118
|
-
|
|
119
|
-
- If `commit_docs` is true:
|
|
120
|
-
```bash
|
|
121
|
-
node .claude/maxsim/bin/maxsim-tools.cjs commit "docs(${padded_phase}): research phase domain" --files "${phase_dir}/${padded_phase}-RESEARCH.md"
|
|
122
|
-
```
|
|
123
|
-
- Display confirmation:
|
|
124
|
-
```
|
|
125
|
-
Research complete. RESEARCH.md written to {path}.
|
|
126
|
-
```
|
|
127
|
-
- Return control to orchestrator.
|
|
128
|
-
|
|
129
|
-
If MISSING:
|
|
130
|
-
- Error: "Researcher reported complete but RESEARCH.md not found at expected path."
|
|
131
|
-
- Check for alternative paths:
|
|
132
|
-
```bash
|
|
133
|
-
ls "${phase_dir}"/*RESEARCH* 2>/dev/null
|
|
134
|
-
```
|
|
135
|
-
- If found elsewhere, note the actual path and continue.
|
|
136
|
-
- If truly missing, offer: retry or skip research.
|
|
135
|
+
Return control to orchestrator.
|
|
137
136
|
|
|
138
137
|
- **`## RESEARCH BLOCKED`:**
|
|
139
138
|
Display the blocker reason. Offer options:
|
|
@@ -147,7 +146,7 @@ Parse the researcher's return message:
|
|
|
147
146
|
Wait for user choice.
|
|
148
147
|
|
|
149
148
|
- If "Provide context": Get additional info, re-spawn researcher with augmented prompt.
|
|
150
|
-
- If "Skip": Return to orchestrator without
|
|
149
|
+
- If "Skip": Return to orchestrator without posting research comment.
|
|
151
150
|
- If "Abort": Exit workflow.
|
|
152
151
|
|
|
153
152
|
- **`## RESEARCH INCONCLUSIVE`:**
|
|
@@ -163,15 +162,16 @@ Parse the researcher's return message:
|
|
|
163
162
|
|
|
164
163
|
## Step 7: Return to Orchestrator
|
|
165
164
|
|
|
166
|
-
After
|
|
165
|
+
After research is posted to GitHub (or research is skipped), return control to the plan.md orchestrator. Do NOT show gate confirmation or next steps -- the orchestrator handles the gate between Research and Planning.
|
|
167
166
|
|
|
168
167
|
</process>
|
|
169
168
|
|
|
170
169
|
<success_criteria>
|
|
171
170
|
- Researcher model resolved from config
|
|
172
|
-
- Existing research detected and reused
|
|
173
|
-
- researcher agent spawned with full context (
|
|
174
|
-
-
|
|
171
|
+
- Existing research detected from GitHub Issue comment (<!-- maxsim:type=research --> marker) and reused unless --force-research
|
|
172
|
+
- researcher agent spawned with full context (GitHub context comment, requirements, state)
|
|
173
|
+
- Research findings returned from researcher as document, then posted as GitHub comment on Issue #{phase_issue_number}
|
|
174
|
+
- No local RESEARCH.md file written
|
|
175
175
|
- Blocked/inconclusive scenarios handled with user options
|
|
176
176
|
- Control returned to orchestrator without showing gate or next steps
|
|
177
177
|
</success_criteria>
|
|
@@ -23,7 +23,7 @@ Load phase state in one call:
|
|
|
23
23
|
INIT=$(node .claude/maxsim/bin/maxsim-tools.cjs init plan-phase "$PHASE")
|
|
24
24
|
```
|
|
25
25
|
|
|
26
|
-
Parse JSON for: `phase_found`, `phase_dir`, `phase_number`, `phase_name`, `phase_slug`, `padded_phase`, `has_context`, `has_research`, `has_plans`, `plan_count`, `plans`, `commit_docs`, `researcher_model`, `planner_model`, `checker_model`, `research_enabled`, `plan_checker_enabled`, `state_path`, `roadmap_path`, `requirements_path`, `context_path`, `research_path`, `phase_req_ids`.
|
|
26
|
+
Parse JSON for: `phase_found`, `phase_dir`, `phase_number`, `phase_name`, `phase_slug`, `padded_phase`, `has_context`, `has_research`, `has_plans`, `plan_count`, `plans`, `commit_docs`, `researcher_model`, `planner_model`, `checker_model`, `research_enabled`, `plan_checker_enabled`, `state_path`, `roadmap_path`, `requirements_path`, `context_path`, `research_path`, `phase_req_ids`, `phase_issue_number`.
|
|
27
27
|
|
|
28
28
|
**If `phase_found` is false:**
|
|
29
29
|
```
|
|
@@ -39,46 +39,57 @@ Extract from $ARGUMENTS: phase number (integer or decimal like `2.1`), flags (`-
|
|
|
39
39
|
|
|
40
40
|
**If no phase number:** Detect next unplanned phase from roadmap using the `plans` and `has_context`/`has_research` fields.
|
|
41
41
|
|
|
42
|
-
## 3.
|
|
42
|
+
## 3. Stage Detection (GitHub-First)
|
|
43
43
|
|
|
44
|
-
|
|
44
|
+
Detect planning stage by querying the phase GitHub Issue:
|
|
45
45
|
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
46
|
+
1. Get `phase_issue_number` from the init context parsed above.
|
|
47
|
+
2. **If no `phase_issue_number` exists:** The phase has not been set up on GitHub yet.
|
|
48
|
+
- Call `mcp_create_phase_issue` to create the issue (uses roadmap data).
|
|
49
|
+
- Store the returned issue number as `phase_issue_number`.
|
|
50
|
+
3. Call `mcp_get_issue_detail` with `phase_issue_number` to read the phase issue body and comments.
|
|
51
|
+
4. Check issue comments for existing artifacts using HTML marker comments:
|
|
52
|
+
- Has a comment containing `<!-- maxsim:type=context -->`? → Discussion stage complete
|
|
53
|
+
- Has a comment containing `<!-- maxsim:type=research -->`? → Research stage complete
|
|
54
|
+
- Has a comment containing `<!-- maxsim:type=plan -->`? → Planning stage complete
|
|
55
|
+
5. Determine next stage from the GitHub state:
|
|
56
|
+
|
|
57
|
+
| GitHub Issue State | Stage | Action |
|
|
58
|
+
|--------------------|-------|--------|
|
|
59
|
+
| Has `type=plan` comment | Already planned | Go to **Re-entry flow** (step 4) |
|
|
60
|
+
| Has `type=research`, no `type=plan` | Planning | Start at **Planning stage** (step 7) |
|
|
61
|
+
| Has `type=context`, no `type=research` | Research | Start at **Research stage** (step 6) |
|
|
62
|
+
| No marker comments | Discussion | Start at **Discussion stage** (step 5) |
|
|
52
63
|
|
|
53
64
|
Display detected stage:
|
|
54
65
|
```
|
|
55
66
|
Phase {phase_number}: {phase_name}
|
|
67
|
+
GitHub Issue: #{phase_issue_number}
|
|
56
68
|
Current stage: {Discussion | Research | Planning | Already planned}
|
|
57
69
|
```
|
|
58
70
|
|
|
59
71
|
## 4. Re-entry Flow (Already Planned)
|
|
60
72
|
|
|
61
|
-
When `
|
|
73
|
+
When a `type=plan` comment exists on the phase issue, the phase has been planned. Show status and offer options.
|
|
62
74
|
|
|
63
75
|
Display:
|
|
64
76
|
```
|
|
65
77
|
## Phase {phase_number} Already Planned
|
|
66
78
|
|
|
67
|
-
**Plans:**
|
|
68
|
-
**
|
|
69
|
-
**Phase directory:** {phase_dir}
|
|
79
|
+
**Plans:** posted as comment(s) on GitHub Issue #{phase_issue_number}
|
|
80
|
+
**Phase Issue:** https://github.com/{owner}/{repo}/issues/{phase_issue_number}
|
|
70
81
|
|
|
71
82
|
**Options:**
|
|
72
83
|
1. View existing plans
|
|
73
|
-
2. Re-plan from scratch (deletes
|
|
84
|
+
2. Re-plan from scratch (deletes plan comments, restarts from Discussion)
|
|
74
85
|
3. Execute phase -- run /maxsim:execute {phase_number}
|
|
75
86
|
4. Done (exit)
|
|
76
87
|
```
|
|
77
88
|
|
|
78
89
|
Wait for user choice via natural conversation.
|
|
79
90
|
|
|
80
|
-
- **View:** Display contents of each
|
|
81
|
-
- **Re-plan:** Delete existing
|
|
91
|
+
- **View:** Display contents of each `type=plan` comment from the issue, then re-show options.
|
|
92
|
+
- **Re-plan:** Delete existing plan/context/research comments from the phase issue, reset to Discussion stage (step 5).
|
|
82
93
|
- **Execute:** Display `/maxsim:execute {phase_number}` and exit.
|
|
83
94
|
- **Done:** Exit workflow.
|
|
84
95
|
|
|
@@ -88,13 +99,13 @@ Delegate to the discussion sub-workflow for full discussion logic:
|
|
|
88
99
|
|
|
89
100
|
@./workflows/plan-discuss.md
|
|
90
101
|
|
|
91
|
-
Pass context: `phase_number`, `phase_name`, `phase_dir`, `padded_phase`, `phase_slug`, `commit_docs`, `roadmap_path`, `state_path`.
|
|
102
|
+
Pass context: `phase_number`, `phase_name`, `phase_dir`, `padded_phase`, `phase_slug`, `commit_docs`, `roadmap_path`, `state_path`, `phase_issue_number`.
|
|
92
103
|
|
|
93
|
-
**After discussion completes (
|
|
104
|
+
**After discussion completes (context posted as GitHub comment):**
|
|
94
105
|
|
|
95
|
-
|
|
96
|
-
```
|
|
97
|
-
|
|
106
|
+
Re-query the phase issue to verify the `type=context` comment now exists:
|
|
107
|
+
```
|
|
108
|
+
mcp_get_issue_detail(issue_number={phase_issue_number})
|
|
98
109
|
```
|
|
99
110
|
|
|
100
111
|
Show gate:
|
|
@@ -103,10 +114,10 @@ Show gate:
|
|
|
103
114
|
|
|
104
115
|
**Captured:** {N} decisions across {M} areas
|
|
105
116
|
**Locked decisions:**
|
|
106
|
-
{bullet list of key decisions from
|
|
117
|
+
{bullet list of key decisions from context comment}
|
|
107
118
|
|
|
108
119
|
**Claude's discretion:** {list of areas where Claude decides}
|
|
109
|
-
**
|
|
120
|
+
**GitHub Issue:** #{phase_issue_number} (context posted as comment)
|
|
110
121
|
|
|
111
122
|
Continue to research? [Yes / Review context / Re-discuss area]
|
|
112
123
|
```
|
|
@@ -114,7 +125,7 @@ Continue to research? [Yes / Review context / Re-discuss area]
|
|
|
114
125
|
Wait for user response via natural conversation (not AskUserQuestion).
|
|
115
126
|
|
|
116
127
|
- **Yes:** Advance to Research stage (step 6).
|
|
117
|
-
- **Review context:** Display
|
|
128
|
+
- **Review context:** Display context comment contents, then re-show gate.
|
|
118
129
|
- **Re-discuss area:** Loop back to discussion sub-workflow with the area to re-discuss.
|
|
119
130
|
|
|
120
131
|
## 6. Research Stage
|
|
@@ -123,22 +134,22 @@ Delegate to the research sub-workflow:
|
|
|
123
134
|
|
|
124
135
|
@./workflows/plan-research.md
|
|
125
136
|
|
|
126
|
-
Pass context: `phase_number`, `phase_name`, `phase_dir`, `padded_phase`, `phase_slug`, `commit_docs`, `researcher_model`, `research_enabled`, `has_research`, `state_path`, `roadmap_path`, `requirements_path`, `context_path`, `phase_req_ids`. Also pass the `--force-research` flag if present in $ARGUMENTS.
|
|
137
|
+
Pass context: `phase_number`, `phase_name`, `phase_dir`, `padded_phase`, `phase_slug`, `commit_docs`, `researcher_model`, `research_enabled`, `has_research`, `state_path`, `roadmap_path`, `requirements_path`, `context_path`, `phase_req_ids`, `phase_issue_number`. Also pass the `--force-research` flag if present in $ARGUMENTS.
|
|
127
138
|
|
|
128
|
-
**After research completes (
|
|
139
|
+
**After research completes (research posted as GitHub comment or already exists):**
|
|
129
140
|
|
|
130
|
-
|
|
131
|
-
```
|
|
132
|
-
|
|
141
|
+
Re-query the phase issue to verify the `type=research` comment now exists:
|
|
142
|
+
```
|
|
143
|
+
mcp_get_issue_detail(issue_number={phase_issue_number})
|
|
133
144
|
```
|
|
134
145
|
|
|
135
146
|
Show gate:
|
|
136
147
|
```
|
|
137
148
|
## Gate: Research Complete
|
|
138
149
|
|
|
139
|
-
**Key findings:** {3-5 bullet summary from
|
|
140
|
-
**Confidence:** {HIGH/MEDIUM/LOW from
|
|
141
|
-
**
|
|
150
|
+
**Key findings:** {3-5 bullet summary from research comment}
|
|
151
|
+
**Confidence:** {HIGH/MEDIUM/LOW from research content}
|
|
152
|
+
**GitHub Issue:** #{phase_issue_number} (research posted as comment)
|
|
142
153
|
|
|
143
154
|
Continue to planning? [Yes / Review research / Re-research]
|
|
144
155
|
```
|
|
@@ -146,7 +157,7 @@ Continue to planning? [Yes / Review research / Re-research]
|
|
|
146
157
|
Wait for user response via natural conversation.
|
|
147
158
|
|
|
148
159
|
- **Yes:** Advance to Planning stage (step 7).
|
|
149
|
-
- **Review research:** Display
|
|
160
|
+
- **Review research:** Display research comment contents, then re-show gate.
|
|
150
161
|
- **Re-research:** Loop back to research sub-workflow with `--force-research`.
|
|
151
162
|
|
|
152
163
|
## 7. Planning Stage
|
|
@@ -155,13 +166,13 @@ Delegate to the planning sub-workflow:
|
|
|
155
166
|
|
|
156
167
|
@./workflows/plan-create.md
|
|
157
168
|
|
|
158
|
-
Pass context: `phase_number`, `phase_name`, `phase_dir`, `padded_phase`, `phase_slug`, `commit_docs`, `planner_model`, `checker_model`, `plan_checker_enabled`, `state_path`, `roadmap_path`, `requirements_path`, `context_path`, `research_path`, `phase_req_ids`. Also pass the `--skip-verify` flag if present in $ARGUMENTS.
|
|
169
|
+
Pass context: `phase_number`, `phase_name`, `phase_dir`, `padded_phase`, `phase_slug`, `commit_docs`, `planner_model`, `checker_model`, `plan_checker_enabled`, `state_path`, `roadmap_path`, `requirements_path`, `context_path`, `research_path`, `phase_req_ids`, `phase_issue_number`. Also pass the `--skip-verify` flag if present in $ARGUMENTS.
|
|
159
170
|
|
|
160
|
-
**After planning completes (
|
|
171
|
+
**After planning completes (plans posted as GitHub comments and task sub-issues created):**
|
|
161
172
|
|
|
162
|
-
|
|
163
|
-
```
|
|
164
|
-
|
|
173
|
+
Re-query the phase issue to verify `type=plan` comments exist:
|
|
174
|
+
```
|
|
175
|
+
mcp_get_issue_detail(issue_number={phase_issue_number})
|
|
165
176
|
```
|
|
166
177
|
|
|
167
178
|
Show final gate:
|
|
@@ -172,9 +183,11 @@ Show final gate:
|
|
|
172
183
|
**Wave structure:**
|
|
173
184
|
| Wave | Plans | What it builds |
|
|
174
185
|
|------|-------|----------------|
|
|
175
|
-
{wave summary from plan frontmatter}
|
|
186
|
+
{wave summary from plan comment frontmatter}
|
|
176
187
|
|
|
177
|
-
**
|
|
188
|
+
**GitHub Issue:** #{phase_issue_number} (plans posted as comments)
|
|
189
|
+
**Task sub-issues:** {task_count} tasks created as linked sub-issues
|
|
190
|
+
**Board status:** Phase moved to "In Progress"
|
|
178
191
|
|
|
179
192
|
Ready to execute? Run `/maxsim:execute {phase_number}`
|
|
180
193
|
```
|
|
@@ -186,13 +199,12 @@ This is the final gate -- no confirmation needed. The user's next action is to r
|
|
|
186
199
|
At any point during the workflow, if context is getting full (conversation is long, many tool calls made), recommend checkpointing before `/clear`.
|
|
187
200
|
|
|
188
201
|
**Checkpoint protocol:**
|
|
189
|
-
1. Post a checkpoint comment to the phase's GitHub Issue
|
|
190
|
-
```
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
plan_content="## MAXSIM Checkpoint\n\n**Command:** /maxsim:plan\n**Stage:** {current_stage} ({stage_num}/3)\n**Completed:**\n{list of completed stages with summaries}\n**Resume from:** {next_stage}\n**Timestamp:** {ISO timestamp}"
|
|
202
|
+
1. Post a checkpoint comment to the phase's GitHub Issue:
|
|
203
|
+
```
|
|
204
|
+
mcp_post_comment(
|
|
205
|
+
issue_number={phase_issue_number},
|
|
206
|
+
type="checkpoint",
|
|
207
|
+
content="## MAXSIM Checkpoint\n\n**Command:** /maxsim:plan\n**Stage:** {current_stage} ({stage_num}/3)\n**Completed:**\n{list of completed stages with summaries}\n**Resume from:** {next_stage}\n**Timestamp:** {ISO timestamp}"
|
|
196
208
|
)
|
|
197
209
|
```
|
|
198
210
|
|
|
@@ -200,10 +212,10 @@ mcp_post_plan_comment(
|
|
|
200
212
|
```
|
|
201
213
|
Context is filling up. Recommended: save progress and /clear.
|
|
202
214
|
|
|
203
|
-
Your progress has been checkpointed. Re-run `/maxsim:plan {phase_number}` after /clear -- it will detect completed stages and resume from {next_stage}.
|
|
215
|
+
Your progress has been checkpointed on GitHub Issue #{phase_issue_number}. Re-run `/maxsim:plan {phase_number}` after /clear -- it will detect completed stages from GitHub and resume from {next_stage}.
|
|
204
216
|
```
|
|
205
217
|
|
|
206
|
-
The stage detection in step 3 handles resume automatically -- completed stages produce
|
|
218
|
+
The stage detection in step 3 handles resume automatically -- completed stages produce marker comments (`<!-- maxsim:type=context -->`, `<!-- maxsim:type=research -->`, `<!-- maxsim:type=plan -->`) that are detected on re-entry.
|
|
207
219
|
|
|
208
220
|
## 9. Update State
|
|
209
221
|
|
|
@@ -212,20 +224,22 @@ After all stages complete, update STATE.md:
|
|
|
212
224
|
```bash
|
|
213
225
|
node .claude/maxsim/bin/maxsim-tools.cjs state record-session \
|
|
214
226
|
--stopped-at "Phase ${PHASE} planned" \
|
|
215
|
-
--resume-file "
|
|
227
|
+
--resume-file "GitHub Issue #${phase_issue_number}"
|
|
216
228
|
```
|
|
217
229
|
|
|
218
230
|
</process>
|
|
219
231
|
|
|
220
232
|
<success_criteria>
|
|
221
233
|
- [ ] Phase validated against roadmap
|
|
222
|
-
- [ ]
|
|
223
|
-
- [ ]
|
|
234
|
+
- [ ] Phase GitHub Issue created if it does not exist
|
|
235
|
+
- [ ] Current stage correctly detected from GitHub Issue comments (not local files)
|
|
236
|
+
- [ ] Re-entry flow works for already-planned phases (reads plan comments from GitHub)
|
|
224
237
|
- [ ] Discussion stage delegates to plan-discuss.md sub-workflow
|
|
225
238
|
- [ ] Research stage delegates to plan-research.md sub-workflow
|
|
226
239
|
- [ ] Planning stage delegates to plan-create.md sub-workflow
|
|
227
240
|
- [ ] Gate confirmation shown after each stage transition
|
|
228
241
|
- [ ] User confirms before advancing to next stage
|
|
229
|
-
- [ ] Checkpoint-before-clear
|
|
242
|
+
- [ ] Checkpoint-before-clear posts to GitHub Issue and resumes via GitHub detection
|
|
230
243
|
- [ ] No stage-specific logic inline -- all delegated to sub-workflows
|
|
231
244
|
</success_criteria>
|
|
245
|
+
</output>
|
package/package.json
CHANGED