feat(execution): wire Execute→Review→Simplify→Review pipeline into executor workflow#20
feat(execution): wire Execute→Review→Simplify→Review pipeline into executor workflow#20maystudios wants to merge 1 commit intomainfrom
Conversation
…ecutor workflow - Add post-task simplification pass to execute-plan workflow (duplication, dead code, complexity) - Add post-wave 2-stage code review gate (spec compliance + code quality) - Update executor agent with Execute→Simplify→Verify→Commit cycle - Add orchestrator status tracking table (EXEC-02) with stage progression - Add task-based context loading instructions (EXEC-03) - Update skill paths from .agents/skills/ to ~/.claude/skills/ - Add skill_paths to ExecutePhaseContext in init.ts - Add progress table and wave review aggregation to execute-phase orchestrator Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR updates the execute-phase / executor workflow templates to add a post-task simplification step and a post-wave two-stage review gate, while also migrating skill directory references to ~/.claude/skills/ and exposing skill path info via the CLI init context.
Changes:
- Add a per-task “simplify” pass (duplication/dead code/complexity) before committing, with re-verification.
- Add a post-wave, two-stage review gate (spec compliance + code quality) and progress/review tables in execution reporting.
- Update skill directory references and add
skill_pathstoExecutePhaseContextoutput fromcmdInitExecutePhase.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| templates/workflows/execute-plan.md | Adds simplify pass and a post-wave code review gate to the execute-plan workflow template. |
| templates/workflows/execute-phase.md | Updates orchestrator wave flow to include a wave review step, progress tables, and skill path reference changes. |
| templates/agents/maxsim-executor.md | Updates executor guidance for task-scoped context loading, Execute→Simplify→Verify→Commit cycle, progress tracking, and skill path references. |
| packages/cli/src/core/init.ts | Extends the execute-phase init context with a skill path field. |
Comments suppressed due to low confidence (1)
templates/agents/maxsim-executor.md:33
- This section calls them “Project skills” but instructs checking
~/.claude/skills/first and only then.claude/skills/as a fallback. That ordering conflicts with later text about project skills overriding built-in/global skills. Clarify precedence (typically project-local overrides global) and align the check order + wording accordingly.
**Project skills:** Check `~/.claude/skills/` directory if it exists (also check `.claude/skills/` in the project root as a fallback):
1. List available skills (subdirectories)
2. Read `SKILL.md` for each skill (lightweight index ~130 lines)
3. Load specific `rules/*.md` files as needed during implementation
4. Do NOT load full `AGENTS.md` files (100KB+ context cost)
5. Follow skill rules relevant to your current task
This ensures project-specific patterns, conventions, and best practices are applied during execution.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Get all files changed in this wave | ||
| WAVE_FIRST_COMMIT=$(git log --oneline --all --grep="{phase}-{first_plan_in_wave}" --reverse | head -1 | cut -d' ' -f1) |
There was a problem hiding this comment.
The suggested command uses --grep="{phase}-{first_plan_in_wave}", but first_plan_in_wave isn’t defined anywhere else in this workflow template (unlike {phase}-{plan} above). As written, this is likely to be copy-pasted and fail or produce an empty commit hash. Consider computing the first plan ID for the wave explicitly (or using the collected plan IDs/commit hashes from the wave) and reference that variable here.
| # Get all files changed in this wave | |
| WAVE_FIRST_COMMIT=$(git log --oneline --all --grep="{phase}-{first_plan_in_wave}" --reverse | head -1 | cut -d' ' -f1) | |
| # Get all files changed in this wave. | |
| # Assumes $WAVE_FIRST_COMMIT was recorded when starting the wave (the first commit for this wave). |
| - .planning/config.json (Config, if exists) | ||
| - ./CLAUDE.md (Project instructions, if exists — follow project-specific guidelines and coding conventions) | ||
| - .agents/skills/ (Project skills, if exists — list skills, read SKILL.md for each, follow relevant rules during implementation) | ||
| - ~/.claude/skills/ (Skills, if exists — list skills, read SKILL.md for each, follow relevant rules during implementation) |
There was a problem hiding this comment.
<files_to_read> now lists only ~/.claude/skills/, but the executor template also mentions a project-local .claude/skills/ fallback/override. If project-local skills are supported, the orchestrator’s startup context list should include them as well so executors discover the correct skill set consistently.
| - ~/.claude/skills/ (Skills, if exists — list skills, read SKILL.md for each, follow relevant rules during implementation) | |
| - ./.claude/skills/ (Project-local skills, if exists — override or extend global skills; list skills and read SKILL.md for each) | |
| - ~/.claude/skills/ (Global skills, if exists — list skills, read SKILL.md for each, follow relevant rules during implementation) |
| 1. Call `skill-context` or read the plan to get the task's file list | ||
| 2. Use the `Read` tool to load only those specific files | ||
| 3. If the task has no `Files:` field, load files referenced in the task description |
There was a problem hiding this comment.
task_context_loading instructs “Call skill-context” to get a task’s file list, but there’s no other reference in the repo to a skill-context command/tool. If this is meant to be a MAXSIM tool, it should be named consistently with other documented commands (e.g., maxsim-tools.cjs ...) or replaced with explicit instructions to parse the Files: field from the plan.
| 1. Call `skill-context` or read the plan to get the task's file list | |
| 2. Use the `Read` tool to load only those specific files | |
| 3. If the task has no `Files:` field, load files referenced in the task description | |
| 1. Read the plan (e.g., `PLAN.md`) and parse the current task's `Files:` field to get the task's file list | |
| 2. Use the `Read` tool to load only those specific files | |
| 3. If the task has no `Files:` field, load files explicitly referenced in the task description |
| state_path: string; | ||
| roadmap_path: string; | ||
| config_path: string; | ||
| skill_paths: string; |
There was a problem hiding this comment.
ExecutePhaseContext is exported from the published CLI package; adding a new required field (skill_paths) is a breaking TypeScript change for any external consumers that construct this type. Consider making it optional (or adding a new optional field) to preserve compatibility, especially since it’s not yet used elsewhere in the codebase.
| skill_paths: string; | |
| skill_paths?: string; |
| @@ -431,6 +434,7 @@ export function cmdInitExecutePhase(cwd: string, phase: string | undefined, raw: | |||
| state_path: '.planning/STATE.md', | |||
| roadmap_path: '.planning/ROADMAP.md', | |||
| config_path: '.planning/config.json', | |||
| skill_paths: skillPaths, | |||
| }; | |||
There was a problem hiding this comment.
skill_paths is set to a single global directory ($HOME/.claude/skills). The templates also mention a project-local .claude/skills fallback/override and the field name is plural, suggesting multiple lookup locations. Consider outputting an ordered list of skill search paths (project-local first, then home) or renaming the field to skill_path if only one location is intended.
| - .planning/STATE.md (State) | ||
| - .planning/config.json (Config, if exists) | ||
| - ./CLAUDE.md (Project instructions, if exists — follow project-specific guidelines and coding conventions) | ||
| - .agents/skills/ (Project skills, if exists — list skills, read SKILL.md for each, follow relevant rules during implementation) | ||
| - ~/.claude/skills/ (Skills, if exists — list skills, read SKILL.md for each, follow relevant rules during implementation) | ||
| </files_to_read> |
There was a problem hiding this comment.
PR description says skill path references were updated “across executor and orchestrator”, but there are still multiple templates referencing .agents/skills/ (e.g., templates/workflows/plan-phase.md, templates/workflows/quick.md, and several agent templates like maxsim-planner.md). If the skills directory move is intended repo-wide, those remaining references will keep pointing at the old location and create inconsistent behavior/documentation.
| WAVE_FIRST_COMMIT=$(echo "${TASK_COMMITS[0]}" | awk '{print $NF}') | ||
| git diff ${WAVE_FIRST_COMMIT}^..HEAD --name-only |
There was a problem hiding this comment.
<wave_code_review> says it reviews only the current wave, but WAVE_FIRST_COMMIT is derived from TASK_COMMITS[0]. Since TASK_COMMITS is only ever appended to in this template and never reset per wave, this diff range will start from the very first task of the entire run, not the wave. Consider resetting the commit list at wave start or tracking a per-wave first commit hash explicitly so the review diff is scoped correctly.
| WAVE_FIRST_COMMIT=$(echo "${TASK_COMMITS[0]}" | awk '{print $NF}') | |
| git diff ${WAVE_FIRST_COMMIT}^..HEAD --name-only | |
| # WAVE_FIRST_COMMIT must be set to the first commit hash of this wave at wave start, e.g.: | |
| # WAVE_FIRST_COMMIT=$(git rev-parse --short HEAD) | |
| git diff "${WAVE_FIRST_COMMIT}^"..HEAD --name-only |
Summary
skill_pathstoExecutePhaseContextininit.tsso orchestrators know where to find skills.agents/skills/to~/.claude/skills/across executor and orchestratorTest plan
npm test— 54 tests, 2 suites)npm run build)biome check)🤖 Generated with Claude Code