fix(commands): add explicit EnterPlanMode/ExitPlanMode to execute, quick, settings

[maystudios]

Summary

• Added explicit EnterPlanMode / ExitPlanMode steps to the <process> blocks of execute.md, quick.md, and settings.md command templates
• Each command now enters Plan Mode before doing work and exits it after presenting results for user review/approval
• Follows the same pattern already established in go.md

Test plan

• All 540 unit tests pass
• E2E skipped (template-only markdown changes, no runtime behavior affected)
• Verified step numbering is sequential and correct in all three files

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates Maxsim command templates to more explicitly describe Plan Mode transitions during command execution, aiming to standardize the EnterPlanMode/ExitPlanMode lifecycle across commands (similar to maxsim:go).

Changes:

• Added explicit EnterPlanMode/ExitPlanMode steps to execute.md, quick.md, and settings.md command template <process> blocks.
• Adjusted step ordering/numbering to incorporate Plan Mode review/approval gates.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
templates/commands/maxsim/settings.md	Adds explicit Plan Mode enter/exit steps around settings review and persistence.
templates/commands/maxsim/quick.md	Adds explicit Plan Mode enter/exit steps around the quick-task flow.
templates/commands/maxsim/execute.md	Adds explicit Plan Mode enter/exit steps around execution plan review before spawning executors.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This step says to read config from CLAUDE.md, but the referenced workflow (templates/workflows/settings.md) loads config via maxsim-tools (config-ensure-section/config-get) and does not use CLAUDE.md as a config source. To avoid conflicting instructions, update the command template to match the workflow’s actual config-loading mechanism (and mention CLAUDE.md only if it’s truly required).

Suggested change

	2. Read current config from CLAUDE.md and `.claude/maxsim/config.json`
	2. Use the workflow’s `maxsim-tools` config helpers (e.g. `config-ensure-section`, `config-get`) to load the current config from `.claude/maxsim/config.json`

[Copilot]

Like the workflow, the user should review/confirm proposed settings while still in Plan Mode; ExitPlanMode should happen only after the user confirms and immediately before writing config.json. The current phrasing (“Exit Plan Mode — user reviews and approves”) suggests approval happens after exiting Plan Mode, which is the opposite of templates/workflows/settings.md and can confuse the operator.

Suggested change

	5. Present proposed configuration changes for review
	6. Exit Plan Mode via `ExitPlanMode` — user reviews and approves changes
	7. Merge answers and write updated config
	5. Present proposed configuration changes for review and confirmation (still in Plan Mode)
	6. User reviews and approves or adjusts the proposed changes while remaining in Plan Mode
	7. After user approval, call `ExitPlanMode` and then merge answers and write the updated config

[Copilot]

templates/workflows/execute.md only enters Plan Mode in the “Needs execution” path (after detecting state) and can skip it entirely for the “Already executed and verified” re-entry flow. This template’s step 1 (“EnterPlanMode before any execution”) reads as unconditional; consider making it conditional on actually executing (and keep the re-entry flow outside Plan Mode) so it mirrors the workflow’s control flow.

Suggested change

	1. **Plan Mode:** Call `EnterPlanMode` before any execution
	2. Detect phase state from GitHub Project Board (already done / partially executed / ready)
	3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. Present the execution plan to the user for review.
	4. Exit Plan Mode via `ExitPlanMode` — user reviews and approves the execution plan
	1. **Plan Mode (when execution is required):** If the detected phase state indicates that execution is needed, call `EnterPlanMode` before performing any execution steps.
	2. Detect phase state from GitHub Project Board (already done / partially executed / ready)
	3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. Present the execution plan to the user for review.
	4. If you entered Plan Mode, exit Plan Mode via `ExitPlanMode` — user reviews and approves the execution plan. The "already executed and verified" re-entry flow stays outside Plan Mode.

[Copilot]

The description of ExitPlanMode is misleading here: per templates/workflows/execute.md, you present the execution plan and obtain user confirmation in Plan Mode, then call ExitPlanMode after confirmation before spawning executors. Please reword/add an explicit approval step so the Plan Mode lifecycle matches the workflow and doesn’t imply approval happens after exiting.

Suggested change

	3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. Present the execution plan to the user for review.
	4. Exit Plan Mode via `ExitPlanMode` — user reviews and approves the execution plan
	3. Group task Issues by wave — re-evaluate wave composition before each spawn against current GitHub state. While still in Plan Mode, present the execution plan to the user for review and obtain explicit approval.
	4. After the user approves the plan, exit Plan Mode via `ExitPlanMode` before spawning any Agents

[Copilot]

In this command template, the high-level process list no longer matches the referenced workflow (templates/workflows/quick.md). The workflow does not spawn a planner agent or a fix agent/retry loop; it enters Plan Mode only when presenting the plan (after issue creation/model resolution) and exits after explicit user approval. Please align these steps to the workflow so the command doesn’t instruct a different orchestration than the implementation docs it points at.

Suggested change

	1. **Plan Mode:** Call `EnterPlanMode` before any planning or execution
	2. Get task description from $ARGUMENTS or via AskUserQuestion
	3. Clarify scope if ambiguous (one focused question)
	4. Create a GitHub Issue labeled `type:quick` for the task
	5. Spawn a planner Agent (quick mode) to produce a concise implementation plan
	6. Present the plan to user — Exit Plan Mode via `ExitPlanMode`
	7. Spawn executor Agent(s) to implement the plan
	8. Spawn a verifier Agent to check the result (tests pass, build succeeds, lint clean)
	9. If verification fails, spawn a fix agent (max 2 retries)
	10. Commit with atomic message referencing the GitHub Issue
	11. Close the GitHub Issue with completion summary
	1. Get task description from $ARGUMENTS or via AskUserQuestion
	2. Clarify scope if ambiguous (one focused question)
	3. Create a GitHub Issue labeled `type:quick` for the task
	4. Resolve any required model or tool choices as described in the quick workflow
	5. Produce a concise implementation plan for the task
	6. Enter Plan Mode via `EnterPlanMode` and present the plan to the user for approval
	7. After explicit user approval, Exit Plan Mode via `ExitPlanMode`
	8. Implement the approved plan (edits, tests, etc.)
	9. Run verification checks (e.g., tests, build, lint) as described in the quick workflow
	10. Commit with an atomic message referencing the GitHub Issue
	11. Close the GitHub Issue with a completion summary

[Copilot]

The wording around ExitPlanMode is backwards here: the user review/approval should happen while still in Plan Mode, and ExitPlanMode should be called only after the user has approved. Consider adding an explicit “wait for approval” step and describing ExitPlanMode as the transition after approval (matching templates/workflows/quick.md).

Suggested change

	6. Present the plan to user — Exit Plan Mode via `ExitPlanMode`
	7. Spawn executor Agent(s) to implement the plan
	8. Spawn a verifier Agent to check the result (tests pass, build succeeds, lint clean)
	9. If verification fails, spawn a fix agent (max 2 retries)
	10. Commit with atomic message referencing the GitHub Issue
	11. Close the GitHub Issue with completion summary
	6. Present the plan to the user and wait for explicit approval while remaining in Plan Mode
	7. After the user approves the plan, transition out of Plan Mode by calling `ExitPlanMode`
	8. Spawn executor Agent(s) to implement the approved plan
	9. Spawn a verifier Agent to check the result (tests pass, build succeeds, lint clean)
	10. If verification fails, spawn a fix agent (max 2 retries)
	11. Commit with atomic message referencing the GitHub Issue
	12. Close the GitHub Issue with completion summary

[github-actions]

🎉 This PR is included in version 5.13.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀