fix(self-improvement): TSV columns, two-batch wizard, two-stage review#186
fix(self-improvement): TSV columns, two-batch wizard, two-stage review#186maystudios merged 1 commit intomainfrom
Conversation
…-stage review - improve.md: Replace 8-column TSV with spec §11.4 canonical 7-column format (iteration, commit, metric, delta, guard, status, description) - improve.md: Restructure parameter collection into two-batch AskUserQuestion pattern with dry-run baseline step - verify-phase.md: Add Step 4b two-stage sequential review (Spec Compliance then Code Quality) gated on strict_mode config - verify-phase.md: Update status determination and comment template with spec_compliance_review and code_quality_review fields Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
🎉 This PR is included in version 5.13.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
There was a problem hiding this comment.
Pull request overview
Updates Maxsim workflow/command templates to align self-improvement logging with the canonical 7-column TSV spec and to add an optional strict-mode verification pass with sequential spec/quality reviews.
Changes:
- Add optional strict-mode “two-stage sequential review” (Spec Compliance → Code Quality) to
verify-phase.md, and extend the verification report schema/table with two new check fields. - Update
/maxsim:improvesetup to use a two-batch AskUserQuestion pattern plus a dry-run baseline, and align its TSV logging description to the 7-column format.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| templates/workflows/verify-phase.md | Adds strict-mode sequential review stages and new verification check fields/rows in the posted report. |
| templates/commands/maxsim/improve.md | Clarifies setup via two question batches + baseline dry-run; updates TSV log column description to canonical 7-column format. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| spec_compliance_review: pass | fail | skipped | ||
| code_quality_review: pass | fail | skipped |
There was a problem hiding this comment.
Since these new check fields allow skipped, it would help to explicitly state (near the strict_mode section or here) that they MUST be set to skipped when strict_mode is disabled, so the verification YAML and the checks_passed/checks_total math stay consistent.
| Spawn a fresh verifier agent: | ||
| ``` | ||
| Agent( | ||
| subagent_type="Explore", |
There was a problem hiding this comment.
subagent_type is set to "Explore", but existing workflow templates consistently use subagent_type="verifier" for verifier agents. If "Explore" isn’t a valid agent type, this will fail at runtime; switch this to verifier (and keep the model as {verifier_model}).
| subagent_type="Explore", | |
| subagent_type="verifier", |
| Agent( | ||
| subagent_type="Explore", | ||
| model="{verifier_model}", | ||
| prompt=" |
There was a problem hiding this comment.
Same issue as Stage 1: subagent_type="Explore" is inconsistent with other verifier spawns (subagent_type="verifier") and may not be a valid agent type. Use verifier here as well to avoid agent-spawn failures.
|
|
||
| ### Step 4b — Two-Stage Sequential Review (Optional) | ||
|
|
||
| When `verification.strict_mode` is enabled in the project config, run an additional two-stage sequential review after the parallel agents complete. Each stage uses a fresh verifier subagent to prevent anchoring bias. |
There was a problem hiding this comment.
The config key referenced here (verification.strict_mode) doesn’t match the config schema and other docs, which use execution.verification.strict_mode. This mismatch can lead to strict-mode behavior being configured incorrectly (or not at all); update the key/path in the text accordingly.
| When `verification.strict_mode` is enabled in the project config, run an additional two-stage sequential review after the parallel agents complete. Each stage uses a fresh verifier subagent to prevent anchoring bias. | |
| When `execution.verification.strict_mode` is enabled in the project config, run an additional two-stage sequential review after the parallel agents complete. Each stage uses a fresh verifier subagent to prevent anchoring bias. |
|
|
||
| Wait for all three review agents to complete before proceeding. | ||
|
|
||
| ### Step 4b — Two-Stage Sequential Review (Optional) |
There was a problem hiding this comment.
This new section is the only step header that uses ### rather than the file’s standard ## Step N — ... format, which makes the step structure inconsistent and can break skimming/TOC behavior. Consider promoting this to ## Step 4b — ... (or renumbering) to match the rest of the document.
| ### Step 4b — Two-Stage Sequential Review (Optional) | |
| ## Step 4b — Two-Stage Sequential Review (Optional) |
| 2. Gather loop parameters via two AskUserQuestion calls: | ||
| **Batch 1** (required — 4 questions): | ||
| - Metric command (the command to run and extract a number from) |
There was a problem hiding this comment.
Step 2 now implies the metric command is always collected via AskUserQuestion, but the command’s <context> section says $ARGUMENTS should be treated as the metric command when provided. To keep the setup flow consistent, update this step to only ask for the metric command when $ARGUMENTS is empty (or explicitly say it’s pre-filled from $ARGUMENTS).
| 2. Gather loop parameters via two AskUserQuestion calls: | |
| **Batch 1** (required — 4 questions): | |
| - Metric command (the command to run and extract a number from) | |
| 2. Gather loop parameters (using AskUserQuestion where needed): | |
| **Batch 1** (required — 4 parameters): | |
| - Metric command (if `$ARGUMENTS` is provided, treat it as the metric command and optionally confirm/edit with the user; otherwise, ask the user for the metric command to run and extract a number from) |
Summary
Test plan
🤖 Generated with Claude Code