maxsimcli 5.0.7 → 5.1.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/README.md +101 -99
- package/dist/assets/CHANGELOG.md +7 -0
- package/dist/assets/hooks/maxsim-capture-learnings.cjs +128 -0
- package/dist/assets/hooks/maxsim-capture-learnings.cjs.map +1 -0
- package/dist/assets/hooks/maxsim-check-update.cjs +126 -88
- package/dist/assets/hooks/maxsim-check-update.cjs.map +1 -1
- package/dist/assets/hooks/maxsim-notification-sound.cjs +87 -43
- package/dist/assets/hooks/maxsim-notification-sound.cjs.map +1 -1
- package/dist/assets/hooks/maxsim-statusline.cjs +45 -171
- package/dist/assets/hooks/maxsim-statusline.cjs.map +1 -1
- package/dist/assets/hooks/maxsim-stop-sound.cjs +86 -43
- package/dist/assets/hooks/maxsim-stop-sound.cjs.map +1 -1
- package/dist/assets/hooks/maxsim-sync-reminder.cjs +72 -21
- package/dist/assets/hooks/maxsim-sync-reminder.cjs.map +1 -1
- package/dist/assets/templates/agents/AGENTS.md +62 -51
- package/dist/assets/templates/agents/executor.md +44 -59
- package/dist/assets/templates/agents/planner.md +36 -31
- package/dist/assets/templates/agents/researcher.md +35 -43
- package/dist/assets/templates/agents/verifier.md +29 -31
- package/dist/assets/templates/commands/maxsim/debug.md +20 -154
- package/dist/assets/templates/commands/maxsim/execute.md +19 -33
- package/dist/assets/templates/commands/maxsim/go.md +21 -20
- package/dist/assets/templates/commands/maxsim/help.md +5 -14
- package/dist/assets/templates/commands/maxsim/init.md +18 -40
- package/dist/assets/templates/commands/maxsim/plan.md +22 -37
- package/dist/assets/templates/commands/maxsim/progress.md +15 -16
- package/dist/assets/templates/commands/maxsim/quick.md +18 -29
- package/dist/assets/templates/commands/maxsim/settings.md +18 -26
- package/dist/assets/templates/references/continuation-format.md +2 -4
- package/dist/assets/templates/references/model-profiles.md +2 -2
- package/dist/assets/templates/references/planning-config.md +10 -11
- package/dist/assets/templates/references/self-improvement.md +120 -0
- package/dist/assets/templates/rules/conventions.md +1 -1
- package/dist/assets/templates/rules/verification-protocol.md +1 -1
- package/dist/assets/templates/skills/brainstorming/SKILL.md +35 -26
- package/dist/assets/templates/skills/code-review/SKILL.md +78 -55
- package/dist/assets/templates/skills/commit-conventions/SKILL.md +70 -36
- package/dist/assets/templates/skills/github-operations/SKILL.md +142 -0
- package/dist/assets/templates/skills/handoff-contract/SKILL.md +62 -28
- package/dist/assets/templates/skills/maxsim-batch/SKILL.md +68 -42
- package/dist/assets/templates/skills/maxsim-simplify/SKILL.md +65 -40
- package/dist/assets/templates/skills/project-memory/SKILL.md +121 -0
- package/dist/assets/templates/skills/research/SKILL.md +126 -0
- package/dist/assets/templates/skills/roadmap-writing/SKILL.md +71 -68
- package/dist/assets/templates/skills/systematic-debugging/SKILL.md +37 -25
- package/dist/assets/templates/skills/tdd/SKILL.md +36 -39
- package/dist/assets/templates/skills/using-maxsim/SKILL.md +69 -55
- package/dist/assets/templates/skills/verification/SKILL.md +167 -0
- package/dist/assets/templates/workflows/batch.md +249 -268
- package/dist/assets/templates/workflows/diagnose-issues.md +225 -151
- package/dist/assets/templates/workflows/execute-plan.md +191 -981
- package/dist/assets/templates/workflows/execute.md +350 -309
- package/dist/assets/templates/workflows/go.md +119 -138
- package/dist/assets/templates/workflows/health.md +71 -114
- package/dist/assets/templates/workflows/help.md +85 -147
- package/dist/assets/templates/workflows/init-existing.md +180 -1373
- package/dist/assets/templates/workflows/init.md +53 -165
- package/dist/assets/templates/workflows/new-milestone.md +91 -334
- package/dist/assets/templates/workflows/new-project.md +165 -1384
- package/dist/assets/templates/workflows/plan-create.md +182 -73
- package/dist/assets/templates/workflows/plan-discuss.md +89 -82
- package/dist/assets/templates/workflows/plan-research.md +191 -85
- package/dist/assets/templates/workflows/plan.md +122 -58
- package/dist/assets/templates/workflows/progress.md +76 -310
- package/dist/assets/templates/workflows/quick.md +70 -495
- package/dist/assets/templates/workflows/sdd.md +231 -221
- package/dist/assets/templates/workflows/settings.md +90 -120
- package/dist/assets/templates/workflows/verify-phase.md +296 -258
- package/dist/cli.cjs +17 -23465
- package/dist/cli.cjs.map +1 -1
- package/dist/install.cjs +356 -8358
- package/dist/install.cjs.map +1 -1
- package/package.json +16 -22
- package/dist/assets/templates/skills/agent-system-map/SKILL.md +0 -92
- package/dist/assets/templates/skills/evidence-collection/SKILL.md +0 -87
- package/dist/assets/templates/skills/github-artifact-protocol/SKILL.md +0 -67
- package/dist/assets/templates/skills/github-tools-guide/SKILL.md +0 -89
- package/dist/assets/templates/skills/input-validation/SKILL.md +0 -51
- package/dist/assets/templates/skills/memory-management/SKILL.md +0 -75
- package/dist/assets/templates/skills/research-methodology/SKILL.md +0 -137
- package/dist/assets/templates/skills/sdd/SKILL.md +0 -91
- package/dist/assets/templates/skills/tool-priority-guide/SKILL.md +0 -80
- package/dist/assets/templates/skills/verification-before-completion/SKILL.md +0 -71
- package/dist/assets/templates/skills/verification-gates/SKILL.md +0 -169
- package/dist/assets/templates/workflows/discuss-phase.md +0 -683
- package/dist/assets/templates/workflows/research-phase.md +0 -73
- package/dist/assets/templates/workflows/verify-work.md +0 -572
- package/dist/core-D5zUr9cb.cjs +0 -4305
- package/dist/core-D5zUr9cb.cjs.map +0 -1
- package/dist/skills-CjFWZIGM.cjs +0 -6824
- package/dist/skills-CjFWZIGM.cjs.map +0 -1
|
@@ -1,683 +0,0 @@
|
|
|
1
|
-
<sanity_check>
|
|
2
|
-
Before executing any step in this workflow, verify:
|
|
3
|
-
1. The current directory contains a `.planning/` folder — if not, stop and tell the user to run `/maxsim:init` first.
|
|
4
|
-
2. `.planning/ROADMAP.md` exists — if not, stop and tell the user to initialize the project.
|
|
5
|
-
</sanity_check>
|
|
6
|
-
|
|
7
|
-
<purpose>
|
|
8
|
-
Extract implementation decisions that downstream agents need. Analyze the phase to identify gray areas, let the user choose what to discuss, then deep-dive each selected area until satisfied.
|
|
9
|
-
|
|
10
|
-
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.
|
|
11
|
-
</purpose>
|
|
12
|
-
|
|
13
|
-
<required_reading>
|
|
14
|
-
@~/.claude/maxsim/references/thinking-partner.md
|
|
15
|
-
</required_reading>
|
|
16
|
-
|
|
17
|
-
<tool_mandate>
|
|
18
|
-
**CRITICAL — Structured user interaction is MANDATORY.**
|
|
19
|
-
|
|
20
|
-
Every question directed at the user MUST use a structured tool. NEVER write a question as plain text and wait for the user to respond. This applies to:
|
|
21
|
-
|
|
22
|
-
- Gray area selection (multiSelect)
|
|
23
|
-
- Every deep-dive question within an area
|
|
24
|
-
- "More questions or next area?" continuation prompts
|
|
25
|
-
- "Ready to create context?" final prompts
|
|
26
|
-
- Any clarification or follow-up question
|
|
27
|
-
- Existing context handling (update/view/skip)
|
|
28
|
-
|
|
29
|
-
**Tool selection:** Use `AskUserQuestion` (questions appear in terminal).
|
|
30
|
-
|
|
31
|
-
**Why:** Plain-text questions create a worse UX — the user has to type free-form answers instead of selecting from well-designed options. Structured choices are the entire point of the discuss workflow.
|
|
32
|
-
|
|
33
|
-
**The rule is simple:** If you need input from the user → use `AskUserQuestion`. Zero exceptions.
|
|
34
|
-
</tool_mandate>
|
|
35
|
-
|
|
36
|
-
<downstream_awareness>
|
|
37
|
-
**CONTEXT.md feeds into:**
|
|
38
|
-
|
|
39
|
-
1. **researcher** — Reads CONTEXT.md to know WHAT to research
|
|
40
|
-
- "User wants card-based layout" → researcher investigates card component patterns
|
|
41
|
-
- "Infinite scroll decided" → researcher looks into virtualization libraries
|
|
42
|
-
|
|
43
|
-
2. **planner** — Reads CONTEXT.md to know WHAT decisions are locked
|
|
44
|
-
- "Pull-to-refresh on mobile" → planner includes that in task specs
|
|
45
|
-
- "Claude's Discretion: loading skeleton" → planner can decide approach
|
|
46
|
-
|
|
47
|
-
**Your job:** Capture decisions clearly enough that downstream agents can act on them without asking the user again.
|
|
48
|
-
|
|
49
|
-
**Not your job:** Figure out HOW to implement. That's what research and planning do with the decisions you capture.
|
|
50
|
-
|
|
51
|
-
**Phase-scoped artefakte:** In addition to project-level artefakte (DECISIONS.md, ACCEPTANCE-CRITERIA.md, NO-GOS.md), this workflow creates phase-scoped copies in the phase directory. These contain ONLY the entries from this phase's discussion, giving downstream agents focused context without needing to parse the full project-level files.
|
|
52
|
-
</downstream_awareness>
|
|
53
|
-
|
|
54
|
-
<philosophy>
|
|
55
|
-
**User = founder/visionary. Claude = thinking partner and builder.**
|
|
56
|
-
|
|
57
|
-
The user knows:
|
|
58
|
-
- How they imagine it working
|
|
59
|
-
- What it should look/feel like
|
|
60
|
-
- What's essential vs nice-to-have
|
|
61
|
-
- Specific behaviors or references they have in mind
|
|
62
|
-
|
|
63
|
-
The user doesn't know (and shouldn't be asked):
|
|
64
|
-
- Codebase patterns (researcher reads the code)
|
|
65
|
-
- Technical risks (researcher identifies these)
|
|
66
|
-
- Implementation approach (planner figures this out)
|
|
67
|
-
- Success metrics (inferred from the work)
|
|
68
|
-
|
|
69
|
-
Ask about vision and implementation choices. Capture decisions for downstream agents.
|
|
70
|
-
|
|
71
|
-
**Thinking-partner behaviors (from thinking-partner.md):**
|
|
72
|
-
- **Challenge vague answers** — "Cards" could mean many things. Push for specifics.
|
|
73
|
-
- **Surface unstated assumptions** — "You're assuming mobile-first — is that intentional?"
|
|
74
|
-
- **Propose alternatives with trade-offs** — Don't just accept first choice. Offer 2-3 options.
|
|
75
|
-
- **Make consequences visible** — "Infinite scroll means no shareable page positions."
|
|
76
|
-
- **Disagree constructively** — If an approach has risks, name them.
|
|
77
|
-
- **Follow the thread** — Build on what they just said. Don't jump topics.
|
|
78
|
-
|
|
79
|
-
Apply these behaviors within each discussion area. The user should feel like they're thinking through decisions with a collaborator, not answering a survey.
|
|
80
|
-
</philosophy>
|
|
81
|
-
|
|
82
|
-
<scope_guardrail>
|
|
83
|
-
**CRITICAL: No scope creep.**
|
|
84
|
-
|
|
85
|
-
The phase boundary comes from ROADMAP.md and is FIXED. Discussion clarifies HOW to implement what's scoped, never WHETHER to add new capabilities.
|
|
86
|
-
|
|
87
|
-
**Allowed (clarifying ambiguity):**
|
|
88
|
-
- "How should posts be displayed?" (layout, density, info shown)
|
|
89
|
-
- "What happens on empty state?" (within the feature)
|
|
90
|
-
- "Pull to refresh or manual?" (behavior choice)
|
|
91
|
-
|
|
92
|
-
**Not allowed (scope creep):**
|
|
93
|
-
- "Should we also add comments?" (new capability)
|
|
94
|
-
- "What about search/filtering?" (new capability)
|
|
95
|
-
- "Maybe include bookmarking?" (new capability)
|
|
96
|
-
|
|
97
|
-
**The heuristic:** Does this clarify how we implement what's already in the phase, or does it add a new capability that could be its own phase?
|
|
98
|
-
|
|
99
|
-
**When user suggests scope creep:**
|
|
100
|
-
```
|
|
101
|
-
"[Feature X] would be a new capability — that's its own phase.
|
|
102
|
-
Want me to note it for the roadmap backlog?
|
|
103
|
-
|
|
104
|
-
For now, let's focus on [phase domain]."
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
Capture the idea in a "Deferred Ideas" section. Don't lose it, don't act on it.
|
|
108
|
-
</scope_guardrail>
|
|
109
|
-
|
|
110
|
-
<gray_area_identification>
|
|
111
|
-
Gray areas are **implementation decisions the user cares about** — things that could go multiple ways and would change the result.
|
|
112
|
-
|
|
113
|
-
**How to identify gray areas:**
|
|
114
|
-
|
|
115
|
-
1. **Read the phase goal** from ROADMAP.md
|
|
116
|
-
2. **Understand the domain** — What kind of thing is being built?
|
|
117
|
-
- Something users SEE → visual presentation, interactions, states matter
|
|
118
|
-
- Something users CALL → interface contracts, responses, errors matter
|
|
119
|
-
- Something users RUN → invocation, output, behavior modes matter
|
|
120
|
-
- Something users READ → structure, tone, depth, flow matter
|
|
121
|
-
- Something being ORGANIZED → criteria, grouping, handling exceptions matter
|
|
122
|
-
3. **Generate phase-specific gray areas** — Not generic categories, but concrete decisions for THIS phase
|
|
123
|
-
|
|
124
|
-
**Don't use generic category labels** (UI, UX, Behavior). Generate specific gray areas:
|
|
125
|
-
|
|
126
|
-
```
|
|
127
|
-
Phase: "User authentication"
|
|
128
|
-
→ Session handling, Error responses, Multi-device policy, Recovery flow
|
|
129
|
-
|
|
130
|
-
Phase: "Organize photo library"
|
|
131
|
-
→ Grouping criteria, Duplicate handling, Naming convention, Folder structure
|
|
132
|
-
|
|
133
|
-
Phase: "CLI for database backups"
|
|
134
|
-
→ Output format, Flag design, Progress reporting, Error recovery
|
|
135
|
-
|
|
136
|
-
Phase: "API documentation"
|
|
137
|
-
→ Structure/navigation, Code examples depth, Versioning approach, Interactive elements
|
|
138
|
-
```
|
|
139
|
-
|
|
140
|
-
**The key question:** What decisions would change the outcome that the user should weigh in on?
|
|
141
|
-
|
|
142
|
-
**Claude handles these (don't ask):**
|
|
143
|
-
- Technical implementation details
|
|
144
|
-
- Architecture patterns
|
|
145
|
-
- Performance optimization
|
|
146
|
-
- Scope (roadmap defines this)
|
|
147
|
-
</gray_area_identification>
|
|
148
|
-
|
|
149
|
-
<process>
|
|
150
|
-
|
|
151
|
-
<step name="initialize" priority="first">
|
|
152
|
-
Phase number from argument (required).
|
|
153
|
-
|
|
154
|
-
```bash
|
|
155
|
-
INIT=$(node ~/.claude/maxsim/bin/maxsim-tools.cjs init phase-op "${PHASE}")
|
|
156
|
-
```
|
|
157
|
-
|
|
158
|
-
Parse JSON for: `commit_docs`, `phase_found`, `phase_dir`, `phase_number`, `phase_name`, `phase_slug`, `padded_phase`, `has_research`, `has_context`, `has_plans`, `has_verification`, `plan_count`, `roadmap_exists`, `planning_exists`.
|
|
159
|
-
|
|
160
|
-
**If `phase_found` is false:**
|
|
161
|
-
```
|
|
162
|
-
Phase [X] not found in roadmap.
|
|
163
|
-
|
|
164
|
-
Use /maxsim:progress to see available phases.
|
|
165
|
-
```
|
|
166
|
-
Exit workflow.
|
|
167
|
-
|
|
168
|
-
**If `phase_found` is true:** Continue to check_existing.
|
|
169
|
-
</step>
|
|
170
|
-
|
|
171
|
-
<step name="check_existing">
|
|
172
|
-
Check if CONTEXT.md already exists using `has_context` from init.
|
|
173
|
-
|
|
174
|
-
```bash
|
|
175
|
-
ls ${phase_dir}/*-CONTEXT.md 2>/dev/null
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
**If exists:**
|
|
179
|
-
Use AskUserQuestion:
|
|
180
|
-
- header: "Context"
|
|
181
|
-
- question: "Phase [X] already has context. What do you want to do?"
|
|
182
|
-
- options:
|
|
183
|
-
- "Update it" — Review and revise existing context
|
|
184
|
-
- "View it" — Show me what's there
|
|
185
|
-
- "Skip" — Use existing context as-is
|
|
186
|
-
|
|
187
|
-
If "Update": Load existing, continue to analyze_phase
|
|
188
|
-
If "View": Display CONTEXT.md, then offer update/skip
|
|
189
|
-
If "Skip": Exit workflow
|
|
190
|
-
|
|
191
|
-
**If doesn't exist:**
|
|
192
|
-
|
|
193
|
-
Check `has_plans` and `plan_count` from init. **If `has_plans` is true:**
|
|
194
|
-
|
|
195
|
-
Use AskUserQuestion:
|
|
196
|
-
- header: "Plans exist"
|
|
197
|
-
- question: "Phase [X] already has {plan_count} plan(s) created without user context. Your decisions here won't affect existing plans unless you replan."
|
|
198
|
-
- options:
|
|
199
|
-
- "Continue and replan after" — Capture context, then run /maxsim:plan {X} to replan
|
|
200
|
-
- "View existing plans" — Show plans before deciding
|
|
201
|
-
- "Cancel" — Skip discuss-phase
|
|
202
|
-
|
|
203
|
-
If "Continue and replan after": Continue to analyze_phase.
|
|
204
|
-
If "View existing plans": Display plan files, then offer "Continue" / "Cancel".
|
|
205
|
-
If "Cancel": Exit workflow.
|
|
206
|
-
|
|
207
|
-
**If `has_plans` is false:** Continue to analyze_phase.
|
|
208
|
-
</step>
|
|
209
|
-
|
|
210
|
-
<step name="analyze_phase">
|
|
211
|
-
Analyze the phase to identify gray areas worth discussing.
|
|
212
|
-
|
|
213
|
-
**Read the phase description from ROADMAP.md and determine:**
|
|
214
|
-
|
|
215
|
-
1. **Domain boundary** — What capability is this phase delivering? State it clearly.
|
|
216
|
-
|
|
217
|
-
2. **Gray areas by category** — For each relevant category (UI, UX, Behavior, Empty States, Content), identify 1-2 specific ambiguities that would change implementation.
|
|
218
|
-
|
|
219
|
-
3. **Skip assessment** — If no meaningful gray areas exist (pure infrastructure, clear-cut implementation), the phase may not need discussion.
|
|
220
|
-
|
|
221
|
-
**Output your analysis internally, then present to user.**
|
|
222
|
-
|
|
223
|
-
Example analysis for "Post Feed" phase:
|
|
224
|
-
```
|
|
225
|
-
Domain: Displaying posts from followed users
|
|
226
|
-
Gray areas:
|
|
227
|
-
- UI: Layout style (cards vs timeline vs grid)
|
|
228
|
-
- UI: Information density (full posts vs previews)
|
|
229
|
-
- Behavior: Loading pattern (infinite scroll vs pagination)
|
|
230
|
-
- Empty State: What shows when no posts exist
|
|
231
|
-
- Content: What metadata displays (time, author, reactions count)
|
|
232
|
-
```
|
|
233
|
-
</step>
|
|
234
|
-
|
|
235
|
-
<step name="present_gray_areas">
|
|
236
|
-
Present the domain boundary and gray areas to user.
|
|
237
|
-
|
|
238
|
-
**First, state the boundary:**
|
|
239
|
-
```
|
|
240
|
-
Phase [X]: [Name]
|
|
241
|
-
Domain: [What this phase delivers — from your analysis]
|
|
242
|
-
|
|
243
|
-
We'll clarify HOW to implement this.
|
|
244
|
-
(New capabilities belong in other phases.)
|
|
245
|
-
```
|
|
246
|
-
|
|
247
|
-
**Then use AskUserQuestion (multiSelect: true):**
|
|
248
|
-
- header: "Discuss"
|
|
249
|
-
- question: "Which areas do you want to discuss for [phase name]?"
|
|
250
|
-
- options: Generate 3-4 phase-specific gray areas, each with:
|
|
251
|
-
- "[Specific area]" (label) — concrete, not generic
|
|
252
|
-
- [1-2 questions this covers] (description)
|
|
253
|
-
- **Highlight the recommended choice with brief explanation why**
|
|
254
|
-
|
|
255
|
-
**Do NOT include a "skip" or "you decide" option.** User ran this command to discuss — give them real choices.
|
|
256
|
-
|
|
257
|
-
**Examples by domain:**
|
|
258
|
-
|
|
259
|
-
For "Post Feed" (visual feature):
|
|
260
|
-
```
|
|
261
|
-
☐ Layout style — Cards vs list vs timeline? Information density?
|
|
262
|
-
☐ Loading behavior — Infinite scroll or pagination? Pull to refresh?
|
|
263
|
-
☐ Content ordering — Chronological, algorithmic, or user choice?
|
|
264
|
-
☐ Post metadata — What info per post? Timestamps, reactions, author?
|
|
265
|
-
```
|
|
266
|
-
|
|
267
|
-
For "Database backup CLI" (command-line tool):
|
|
268
|
-
```
|
|
269
|
-
☐ Output format — JSON, table, or plain text? Verbosity levels?
|
|
270
|
-
☐ Flag design — Short flags, long flags, or both? Required vs optional?
|
|
271
|
-
☐ Progress reporting — Silent, progress bar, or verbose logging?
|
|
272
|
-
☐ Error recovery — Fail fast, retry, or prompt for action?
|
|
273
|
-
```
|
|
274
|
-
|
|
275
|
-
For "Organize photo library" (organization task):
|
|
276
|
-
```
|
|
277
|
-
☐ Grouping criteria — By date, location, faces, or events?
|
|
278
|
-
☐ Duplicate handling — Keep best, keep all, or prompt each time?
|
|
279
|
-
☐ Naming convention — Original names, dates, or descriptive?
|
|
280
|
-
☐ Folder structure — Flat, nested by year, or by category?
|
|
281
|
-
```
|
|
282
|
-
|
|
283
|
-
Continue to discuss_areas with selected areas.
|
|
284
|
-
</step>
|
|
285
|
-
|
|
286
|
-
<step name="discuss_areas">
|
|
287
|
-
For each selected area, conduct a focused discussion loop.
|
|
288
|
-
|
|
289
|
-
**Philosophy: 4 questions, then check.**
|
|
290
|
-
|
|
291
|
-
Ask 4 questions per area before offering to continue or move on. Each answer often reveals the next question.
|
|
292
|
-
|
|
293
|
-
**For each area:**
|
|
294
|
-
|
|
295
|
-
1. **Announce the area:**
|
|
296
|
-
```
|
|
297
|
-
Let's talk about [Area].
|
|
298
|
-
```
|
|
299
|
-
|
|
300
|
-
2. **Ask 4 questions using AskUserQuestion:**
|
|
301
|
-
- header: "[Area]" (max 12 chars — abbreviate if needed)
|
|
302
|
-
- question: Specific decision for this area
|
|
303
|
-
- options: 2-3 concrete choices (AskUserQuestion adds "Other" automatically), with the recommended choice highlighted and brief explanation why
|
|
304
|
-
- Include "You decide" as an option when reasonable — captures Claude discretion
|
|
305
|
-
|
|
306
|
-
3. **After 4 questions, check:**
|
|
307
|
-
- header: "[Area]" (max 12 chars)
|
|
308
|
-
- question: "More questions about [area], or move to next?"
|
|
309
|
-
- options: "More questions" / "Next area"
|
|
310
|
-
|
|
311
|
-
If "More questions" → ask 4 more, then check again
|
|
312
|
-
If "Next area" → proceed to next selected area
|
|
313
|
-
If "Other" (free text) → interpret intent: continuation phrases ("chat more", "keep going", "yes", "more") map to "More questions"; advancement phrases ("done", "move on", "next", "skip") map to "Next area". If ambiguous, ask: "Continue with more questions about [area], or move to the next area?"
|
|
314
|
-
|
|
315
|
-
4. **After all initially-selected areas complete:**
|
|
316
|
-
- Summarize what was captured from the discussion so far
|
|
317
|
-
- AskUserQuestion:
|
|
318
|
-
- header: "Done"
|
|
319
|
-
- question: "We've discussed [list areas]. Which gray areas remain unclear?"
|
|
320
|
-
- options: "Explore more gray areas" / "I'm ready for context"
|
|
321
|
-
- If "Explore more gray areas":
|
|
322
|
-
- Identify 2-4 additional gray areas based on what was learned
|
|
323
|
-
- Return to present_gray_areas logic with these new areas
|
|
324
|
-
- Loop: discuss new areas, then prompt again
|
|
325
|
-
- If "I'm ready for context": Proceed to write_context
|
|
326
|
-
|
|
327
|
-
**Adaptive probing (thinking-partner mode):**
|
|
328
|
-
|
|
329
|
-
Within each area, adapt your questioning based on the user's certainty level:
|
|
330
|
-
- **User is confident** (picks options quickly) — probe deeper: "You chose X — have you considered how that interacts with Y?"
|
|
331
|
-
- **User is uncertain** (picks "Other", hedges) — propose alternatives: "Here are 3 approaches with trade-offs..."
|
|
332
|
-
- **User defers** (picks "You decide") — accept but name consequences: "I'll go with X because [reason]. That means Y."
|
|
333
|
-
|
|
334
|
-
Challenge decisions that may have hidden costs. If the user picks something that conflicts with an earlier decision, surface it: "Earlier you said A, but this implies B. Which takes priority?"
|
|
335
|
-
|
|
336
|
-
**Question design:**
|
|
337
|
-
- Options should be concrete, not abstract ("Cards" not "Option A")
|
|
338
|
-
- Each answer should inform the next question
|
|
339
|
-
- If user picks "Other", receive their input, reflect it back, confirm
|
|
340
|
-
|
|
341
|
-
**Scope creep handling:**
|
|
342
|
-
If user mentions something outside the phase domain:
|
|
343
|
-
```
|
|
344
|
-
"[Feature] sounds like a new capability — that belongs in its own phase.
|
|
345
|
-
I'll note it as a deferred idea.
|
|
346
|
-
|
|
347
|
-
Back to [current area]: [return to current question]"
|
|
348
|
-
```
|
|
349
|
-
|
|
350
|
-
Track deferred ideas internally.
|
|
351
|
-
</step>
|
|
352
|
-
|
|
353
|
-
<step name="write_context">
|
|
354
|
-
Create CONTEXT.md capturing decisions made.
|
|
355
|
-
|
|
356
|
-
**Find or create phase directory:**
|
|
357
|
-
|
|
358
|
-
Use values from init: `phase_dir`, `phase_slug`, `padded_phase`.
|
|
359
|
-
|
|
360
|
-
If `phase_dir` is null (phase exists in roadmap but no directory):
|
|
361
|
-
```bash
|
|
362
|
-
mkdir -p ".planning/phases/${padded_phase}-${phase_slug}"
|
|
363
|
-
```
|
|
364
|
-
|
|
365
|
-
**File location:** `${phase_dir}/${padded_phase}-CONTEXT.md`
|
|
366
|
-
|
|
367
|
-
**Structure the content by what was discussed:**
|
|
368
|
-
|
|
369
|
-
```markdown
|
|
370
|
-
# Phase [X]: [Name] - Context
|
|
371
|
-
|
|
372
|
-
**Gathered:** [date]
|
|
373
|
-
**Status:** Ready for planning
|
|
374
|
-
|
|
375
|
-
<domain>
|
|
376
|
-
## Phase Boundary
|
|
377
|
-
|
|
378
|
-
[Clear statement of what this phase delivers — the scope anchor]
|
|
379
|
-
|
|
380
|
-
</domain>
|
|
381
|
-
|
|
382
|
-
<decisions>
|
|
383
|
-
## Implementation Decisions
|
|
384
|
-
|
|
385
|
-
### [Category 1 that was discussed]
|
|
386
|
-
- [Decision or preference captured]
|
|
387
|
-
- [Another decision if applicable]
|
|
388
|
-
|
|
389
|
-
### [Category 2 that was discussed]
|
|
390
|
-
- [Decision or preference captured]
|
|
391
|
-
|
|
392
|
-
### Claude's Discretion
|
|
393
|
-
[Areas where user said "you decide" — note that Claude has flexibility here]
|
|
394
|
-
|
|
395
|
-
</decisions>
|
|
396
|
-
|
|
397
|
-
<specifics>
|
|
398
|
-
## Specific Ideas
|
|
399
|
-
|
|
400
|
-
[Any particular references, examples, or "I want it like X" moments from discussion]
|
|
401
|
-
|
|
402
|
-
[If none: "No specific requirements — open to standard approaches"]
|
|
403
|
-
|
|
404
|
-
</specifics>
|
|
405
|
-
|
|
406
|
-
<deferred>
|
|
407
|
-
## Deferred Ideas
|
|
408
|
-
|
|
409
|
-
[Ideas that came up but belong in other phases. Don't lose them.]
|
|
410
|
-
|
|
411
|
-
[If none: "None — discussion stayed within phase scope"]
|
|
412
|
-
|
|
413
|
-
</deferred>
|
|
414
|
-
|
|
415
|
-
---
|
|
416
|
-
|
|
417
|
-
*Phase: XX-name*
|
|
418
|
-
*Context gathered: [date]*
|
|
419
|
-
```
|
|
420
|
-
|
|
421
|
-
Write file.
|
|
422
|
-
|
|
423
|
-
**Generate phase-specific artefakte:**
|
|
424
|
-
|
|
425
|
-
After writing CONTEXT.md, append phase-specific entries to the project-level artefakte files.
|
|
426
|
-
|
|
427
|
-
**Append to DECISIONS.md:**
|
|
428
|
-
|
|
429
|
-
```bash
|
|
430
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs artefakte-append decisions --entry "..."
|
|
431
|
-
```
|
|
432
|
-
|
|
433
|
-
Append content:
|
|
434
|
-
|
|
435
|
-
```markdown
|
|
436
|
-
|
|
437
|
-
## Phase [X]: [Name]
|
|
438
|
-
|
|
439
|
-
| # | Decision | Rationale | Alternatives Considered | Status |
|
|
440
|
-
|---|----------|-----------|------------------------|--------|
|
|
441
|
-
| [next #] | [Decision from discussion] | [Why chosen] | [What else was offered] | Locked |
|
|
442
|
-
```
|
|
443
|
-
|
|
444
|
-
**Append to ACCEPTANCE-CRITERIA.md:**
|
|
445
|
-
|
|
446
|
-
```bash
|
|
447
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs artefakte-append acceptance-criteria --entry "..."
|
|
448
|
-
```
|
|
449
|
-
|
|
450
|
-
Append content under "Phase-Level Criteria":
|
|
451
|
-
|
|
452
|
-
```markdown
|
|
453
|
-
|
|
454
|
-
### Phase [X]: [Name]
|
|
455
|
-
|
|
456
|
-
- [ ] [Observable outcome from decisions — e.g., "User sees card-based layout on feed page"]
|
|
457
|
-
- [ ] [Observable outcome from decisions — e.g., "Infinite scroll loads next batch on scroll"]
|
|
458
|
-
- [ ] [Observable outcome from decisions — e.g., "Empty state shows onboarding prompt"]
|
|
459
|
-
```
|
|
460
|
-
|
|
461
|
-
**Append to NO-GOS.md (if applicable):**
|
|
462
|
-
|
|
463
|
-
If any "don't do this" or "avoid this approach" decisions were made during discussion:
|
|
464
|
-
|
|
465
|
-
```bash
|
|
466
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs artefakte-append no-gos --entry "..."
|
|
467
|
-
```
|
|
468
|
-
|
|
469
|
-
Append content:
|
|
470
|
-
|
|
471
|
-
```markdown
|
|
472
|
-
|
|
473
|
-
## Phase [X]: [Name]
|
|
474
|
-
|
|
475
|
-
- [Approach to avoid] -- [why, from discussion]
|
|
476
|
-
```
|
|
477
|
-
|
|
478
|
-
If no no-gos emerged from discussion, skip this append.
|
|
479
|
-
|
|
480
|
-
**Commit artefakte updates:**
|
|
481
|
-
|
|
482
|
-
```bash
|
|
483
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs commit "docs(${padded_phase}): update artefakte from phase discussion" --files .planning/DECISIONS.md .planning/ACCEPTANCE-CRITERIA.md .planning/NO-GOS.md
|
|
484
|
-
```
|
|
485
|
-
|
|
486
|
-
**Create phase-scoped artefakte:**
|
|
487
|
-
|
|
488
|
-
After appending to project-level artefakte, create phase-scoped copies containing ONLY the entries from this phase's discussion. These give downstream agents (researcher, planner, executor) focused phase-specific context without parsing the full project-level files.
|
|
489
|
-
|
|
490
|
-
For each artefakte type that had entries appended in the previous step:
|
|
491
|
-
|
|
492
|
-
**Decisions (if phase decisions were captured):**
|
|
493
|
-
```bash
|
|
494
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs artefakte-write decisions --phase ${phase_num} --content "# Phase ${phase_num}: ${phase_name} — Decisions\n\n| # | Decision | Rationale | Alternatives Considered | Status |\n|---|----------|-----------|------------------------|--------|\n[phase-specific decision entries from the discussion above]"
|
|
495
|
-
```
|
|
496
|
-
|
|
497
|
-
**Acceptance Criteria (if phase criteria were defined):**
|
|
498
|
-
```bash
|
|
499
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs artefakte-write acceptance-criteria --phase ${phase_num} --content "# Phase ${phase_num}: ${phase_name} — Acceptance Criteria\n\n[phase-specific criteria entries from the discussion above, each as a - [ ] checkbox line]"
|
|
500
|
-
```
|
|
501
|
-
|
|
502
|
-
**No-Gos (if phase no-gos emerged):**
|
|
503
|
-
```bash
|
|
504
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs artefakte-write no-gos --phase ${phase_num} --content "# Phase ${phase_num}: ${phase_name} — No-Gos\n\n[phase-specific no-go entries from the discussion above, each as a - bullet]"
|
|
505
|
-
```
|
|
506
|
-
|
|
507
|
-
Only create artefakte files for types that actually had entries — skip any type where no relevant decisions/criteria/no-gos emerged.
|
|
508
|
-
|
|
509
|
-
Include the phase-scoped artefakte files in the same git commit as the project-level artefakte:
|
|
510
|
-
|
|
511
|
-
```bash
|
|
512
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs commit "docs(${padded_phase}): create phase-scoped artefakte from discussion" --files "${phase_dir}/"
|
|
513
|
-
```
|
|
514
|
-
|
|
515
|
-
</step>
|
|
516
|
-
|
|
517
|
-
<step name="confirm_creation">
|
|
518
|
-
Present summary and next steps:
|
|
519
|
-
|
|
520
|
-
```
|
|
521
|
-
Created: .planning/phases/${PADDED_PHASE}-${SLUG}/${PADDED_PHASE}-CONTEXT.md
|
|
522
|
-
|
|
523
|
-
## Decisions Captured
|
|
524
|
-
|
|
525
|
-
### [Category]
|
|
526
|
-
- [Key decision]
|
|
527
|
-
|
|
528
|
-
### [Category]
|
|
529
|
-
- [Key decision]
|
|
530
|
-
|
|
531
|
-
[If deferred ideas exist:]
|
|
532
|
-
## Noted for Later
|
|
533
|
-
- [Deferred idea] — future phase
|
|
534
|
-
|
|
535
|
-
---
|
|
536
|
-
|
|
537
|
-
## ▶ Next Up
|
|
538
|
-
|
|
539
|
-
**Phase ${PHASE}: [Name]** — [Goal from ROADMAP.md]
|
|
540
|
-
|
|
541
|
-
`/maxsim:plan ${PHASE}`
|
|
542
|
-
|
|
543
|
-
<sub>`/clear` first → fresh context window</sub>
|
|
544
|
-
|
|
545
|
-
---
|
|
546
|
-
|
|
547
|
-
**Also available:**
|
|
548
|
-
- `/maxsim:plan ${PHASE} --skip-research` — plan without research
|
|
549
|
-
- Review/edit CONTEXT.md before continuing
|
|
550
|
-
|
|
551
|
-
---
|
|
552
|
-
```
|
|
553
|
-
</step>
|
|
554
|
-
|
|
555
|
-
<step name="git_commit">
|
|
556
|
-
Commit phase context (uses `commit_docs` from init internally):
|
|
557
|
-
|
|
558
|
-
```bash
|
|
559
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs commit "docs(${padded_phase}): capture phase context" --files "${phase_dir}/${padded_phase}-CONTEXT.md"
|
|
560
|
-
```
|
|
561
|
-
|
|
562
|
-
Confirm: "Committed: docs(${padded_phase}): capture phase context"
|
|
563
|
-
</step>
|
|
564
|
-
|
|
565
|
-
<step name="update_state">
|
|
566
|
-
Update STATE.md with session info:
|
|
567
|
-
|
|
568
|
-
```bash
|
|
569
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs state record-session \
|
|
570
|
-
--stopped-at "Phase ${PHASE} context gathered" \
|
|
571
|
-
--resume-file "${phase_dir}/${padded_phase}-CONTEXT.md"
|
|
572
|
-
```
|
|
573
|
-
|
|
574
|
-
Commit STATE.md:
|
|
575
|
-
|
|
576
|
-
```bash
|
|
577
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs commit "docs(state): record phase ${PHASE} context session" --files .planning/STATE.md
|
|
578
|
-
```
|
|
579
|
-
</step>
|
|
580
|
-
|
|
581
|
-
<step name="auto_advance">
|
|
582
|
-
Check for auto-advance trigger:
|
|
583
|
-
|
|
584
|
-
1. Parse `--auto` flag from $ARGUMENTS
|
|
585
|
-
2. Read `workflow.auto_advance` from config:
|
|
586
|
-
```bash
|
|
587
|
-
AUTO_CFG=$(node ~/.claude/maxsim/bin/maxsim-tools.cjs config-get workflow.auto_advance 2>/dev/null || echo "false")
|
|
588
|
-
```
|
|
589
|
-
|
|
590
|
-
**If `--auto` flag present AND `AUTO_CFG` is not true:** Persist auto-advance to config (handles direct `--auto` usage without new-project):
|
|
591
|
-
```bash
|
|
592
|
-
node ~/.claude/maxsim/bin/maxsim-tools.cjs config-set workflow.auto_advance true
|
|
593
|
-
```
|
|
594
|
-
|
|
595
|
-
**If `--auto` flag present OR `AUTO_CFG` is true:**
|
|
596
|
-
|
|
597
|
-
Display banner:
|
|
598
|
-
```
|
|
599
|
-
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
600
|
-
MAXSIM ► AUTO-ADVANCING TO PLAN
|
|
601
|
-
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
602
|
-
|
|
603
|
-
Context captured. Spawning plan...
|
|
604
|
-
```
|
|
605
|
-
|
|
606
|
-
Spawn plan as Task with direct workflow file reference (do NOT use Skill tool — Skills don't resolve inside Task subagents):
|
|
607
|
-
```
|
|
608
|
-
Task(
|
|
609
|
-
prompt="
|
|
610
|
-
<objective>
|
|
611
|
-
You are the plan orchestrator. Create executable plans for Phase ${PHASE}: ${PHASE_NAME}, then auto-advance to execution.
|
|
612
|
-
</objective>
|
|
613
|
-
|
|
614
|
-
<execution_context>
|
|
615
|
-
@~/.claude/maxsim/workflows/plan.md
|
|
616
|
-
@~/.claude/maxsim/references/ui-brand.md
|
|
617
|
-
@~/.claude/maxsim/references/model-profile-resolution.md
|
|
618
|
-
</execution_context>
|
|
619
|
-
|
|
620
|
-
<arguments>
|
|
621
|
-
PHASE=${PHASE}
|
|
622
|
-
ARGUMENTS='${PHASE} --auto'
|
|
623
|
-
</arguments>
|
|
624
|
-
|
|
625
|
-
<instructions>
|
|
626
|
-
1. Read plan.md from execution_context for your complete workflow
|
|
627
|
-
2. Follow ALL steps: initialize, validate, load context, research, plan, verify, auto-advance
|
|
628
|
-
3. When spawning agents (researcher, planner), use Task with specified subagent_type and model
|
|
629
|
-
4. For step 14 (auto-advance to execute): spawn execute-phase as a Task with DIRECT file reference — tell it to read execute-phase.md. Include @file refs to execute-phase.md, checkpoints.md, tdd.md, model-profile-resolution.md. Pass --no-transition flag so execute-phase returns results instead of chaining further.
|
|
630
|
-
5. Do NOT use the Skill tool or /maxsim: commands. Read workflow .md files directly.
|
|
631
|
-
6. Return: PHASE COMPLETE (full pipeline success), PLANNING COMPLETE (planning done but execute failed/skipped), PLANNING INCONCLUSIVE, or GAPS FOUND
|
|
632
|
-
</instructions>
|
|
633
|
-
",
|
|
634
|
-
subagent_type="general-purpose",
|
|
635
|
-
description="Plan Phase ${PHASE}"
|
|
636
|
-
)
|
|
637
|
-
```
|
|
638
|
-
|
|
639
|
-
**Handle plan return:**
|
|
640
|
-
- **PHASE COMPLETE** → Full chain succeeded. Display:
|
|
641
|
-
```
|
|
642
|
-
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
643
|
-
MAXSIM ► PHASE ${PHASE} COMPLETE
|
|
644
|
-
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
645
|
-
|
|
646
|
-
Auto-advance pipeline finished: discuss → plan → execute
|
|
647
|
-
|
|
648
|
-
Next: /maxsim:plan ${NEXT_PHASE} --auto
|
|
649
|
-
<sub>/clear first → fresh context window</sub>
|
|
650
|
-
```
|
|
651
|
-
- **PLANNING COMPLETE** → Planning done, execution didn't complete:
|
|
652
|
-
```
|
|
653
|
-
Auto-advance partial: Planning complete, execution did not finish.
|
|
654
|
-
Continue: /maxsim:execute ${PHASE}
|
|
655
|
-
```
|
|
656
|
-
- **PLANNING INCONCLUSIVE / CHECKPOINT** → Stop chain:
|
|
657
|
-
```
|
|
658
|
-
Auto-advance stopped: Planning needs input.
|
|
659
|
-
Continue: /maxsim:plan ${PHASE}
|
|
660
|
-
```
|
|
661
|
-
- **GAPS FOUND** → Stop chain:
|
|
662
|
-
```
|
|
663
|
-
Auto-advance stopped: Gaps found during execution.
|
|
664
|
-
Continue: /maxsim:plan ${PHASE} --gaps
|
|
665
|
-
```
|
|
666
|
-
|
|
667
|
-
**If neither `--auto` nor config enabled:**
|
|
668
|
-
Route to `confirm_creation` step (existing behavior — show manual next steps).
|
|
669
|
-
</step>
|
|
670
|
-
|
|
671
|
-
</process>
|
|
672
|
-
|
|
673
|
-
<success_criteria>
|
|
674
|
-
- Phase validated against roadmap
|
|
675
|
-
- Gray areas identified through intelligent analysis (not generic questions)
|
|
676
|
-
- User selected which areas to discuss
|
|
677
|
-
- Each selected area explored until user satisfied
|
|
678
|
-
- Scope creep redirected to deferred ideas
|
|
679
|
-
- CONTEXT.md captures actual decisions, not vague vision
|
|
680
|
-
- Deferred ideas preserved for future phases
|
|
681
|
-
- STATE.md updated with session info
|
|
682
|
-
- User knows next steps
|
|
683
|
-
</success_criteria>
|