// Execute the implementation plan for a reviewed task module. Triggered after check PASS (from review status) or on NEEDS_FIX continuation (from executing status with fix guidance).
Process Plan panel annotations — triage, cross-impact assessment, and execution. Triggered automatically when annotations (Insert/Delete/Replace/Comment) are submitted from the Plan panel UI.
Autonomous execution loop — single Claude session orchestrates plan/check/exec cycle internally
Cancel a task module — set status to cancelled, stop auto if running, optionally clean up worktree. Use when a task becomes infeasible, is deprioritized, or needs to be abandoned.
Check plan feasibility at key checkpoints — post-plan, mid-execution, post-execution
Initialize a new task module in AiTasks/ directory with system files, git branch, and optional worktree. Use when starting a new feature, bug fix, or refactoring task that needs structured lifecycle tracking.
Query task status and relationships — read-only, no file writes. Use to inspect task inventory, check progress, view dependency graphs, or audit status transition history.
| name | exec |
| description | Execute the implementation plan for a reviewed task module. Triggered after check PASS (from review status) or on NEEDS_FIX continuation (from executing status with fix guidance). |
| arguments | [{"name":"task_module","description":"Path to the task module directory (e.g., AiTasks/auth-refactor)","required":true},{"name":"step","description":"Execute a specific step number (optional, executes all if omitted)","required":false}] |
Execute the implementation plan for a task module that has passed evaluation.
/moonview:exec <task_module_path> [--step N]
review (post-plan check passed) or executing (NEEDS_FIX continuation).target.md and at least one plan file must exist.analysis/ should contain a PASS evaluation file (warning if empty/missing)depends_on modules must meet their required status — simple string entries require complete, extended { module, min_status } entries require at-or-past min_status (see depends_on Format in commands/ai-cli-task.md). If any dependency is not met, exec REJECTS with error listing blocking dependencies and their current statuses.plan.md in the task module.target.md for requirements context.type-profile.md if exists — "Implementation Patterns" and "Key tools" sections are the primary source for tool selection and implementation approach. If execution reveals the profile's patterns are inaccurate, update the relevant sections with findings.summary.md if exists (condensed context from prior plan/check/exec runs — primary context source).test/ latest criteria file for per-step verification criteria and acceptance standards.analysis/ latest file only for evaluation notes and approved approach.bugfix/ latest file only if exists for most recent issue and fix guidance.notes/ latest file only if exists for most recent research findingsAiTasks/.references/.summary.md if exists — find relevant external reference files by keyword matching. Read matched .references/<topic>.md files for domain-specific implementation guidance.type-profile.md lacks implementation guidance OR .references/ lacks knowledge for the current step's technologies/APIs, trigger research --scope gap --caller exec to collect missing references before proceeding.plan.md (ordered by heading structure)Context management: When .summary.md exists, read it as the primary context source instead of reading all files from .analysis/, .bugfix/, .notes/. Only read the latest (last by filename sort) file from each directory for detailed info on the most recent assessment/issue/note.
Read the type field from .index.json to determine the task domain. Execution strategy MUST adapt to the task type — different domains use fundamentally different tools, verification methods, and workflows.
For each implementation step:
init/references/seed-types/<type>.md for per-type seed methodology, or .type-profile.md for task-specific guidance).test/ criteria using domain-appropriate verification (see per-type seed file or .type-profile.md for domain verification methods).notes/<YYYY-MM-DD>-<summary>-exec.md when implementation deviates from plan, an unexpected workaround is needed, or a non-obvious API behavior is discovered. Skip for straightforward steps that follow the plan exactly.notes/.summary.md — overwrite with condensed summary of ALL notes files in .notes/| Situation | Action |
|---|---|
| Step succeeds | Record in progress log, continue |
| Minor deviation needed | Adjust and document, continue |
| Significant issue | Stop execution, signal (mid-exec). Interactive: suggest check --checkpoint mid-exec. Auto: daemon routes to mid-exec evaluation |
| Blocking dependency | Set status to blocked, report which dependency |
.index.json — validate status is review or executingdepends_on from .index.json, check each dependency module's .index.json status against its required level (simple string → complete, extended object → at-or-past min_status). If any dependency is not met, REJECT with error listing blocking dependencies.index.json status to executing, clear phase to "", update timestamp.plan.mdcompleted_steps field from .index.json to determine progress; skip steps ≤ completed_steps.bugfix/ and .analysis/ latest files, using the most recent file (by filename date) as the primary fix guidance. .bugfix/ entries indicate mid-exec issues; .analysis/ entries indicate post-exec issues. Address fix items before continuing remaining steps--step N specified, execute only that step; otherwise execute remaining incomplete steps in order.test/ criteria (diagnostics / build check). For domain-specific testing, can optionally invoke verify --checkpoint step-N
d. Record result
e. Update .index.json completed_steps to current step number.index.json timestamp.summary.md with condensed context: current progress, steps completed, key decisions, issues encountered, remaining work (integrate from directory summaries){ "step": "exec", "result": "(done)", "next": "verify", "checkpoint": "post-exec", "timestamp": "..." }{ "step": "exec", "result": "(mid-exec)", "next": "verify", "checkpoint": "mid-exec", "timestamp": "..." }--step N single step complete (manual invocation only — auto mode does not use --step): signal { "step": "exec", "result": "(step-N)", "next": "verify", "checkpoint": "mid-exec", "timestamp": "..." }{ "step": "exec", "result": "(blocked)", "next": "(stop)", "checkpoint": "", "timestamp": "..." }| Current Status | After Exec | Condition |
|---|---|---|
review | executing | Execution starts |
executing | executing | NEEDS_FIX continuation (fix issues, stay executing) |
executing | blocked | Blocking dependency encountered |
Execution progress is tracked via .index.json fields:
completed_steps: integer, incremented after each step completes successfully. Reset to 0 when plan changes (by plan sub-command on re-plan). Validation: must be integer >= 0. If value is invalid (negative, non-integer), reset to 0 with warningupdated: timestamp of last execution activityFor long-running executions, intermediate progress can be observed by:
completed_steps in .index.json.summary.md for condensed context-- ai-cli-task(<module>):exec execution started-- ai-cli-task(<module>):feat <description>-- ai-cli-task(<module>):fix <description>-- ai-cli-task(<module>):exec step N/M done-- ai-cli-task(<module>):exec blockedfeat/fix type, state file changes use exec type| Result | Signal |
|---|---|
| All steps done | { "step": "exec", "result": "(done)", "next": "verify", "checkpoint": "post-exec", "timestamp": "..." } |
| Significant issue | { "step": "exec", "result": "(mid-exec)", "next": "verify", "checkpoint": "mid-exec", "timestamp": "..." } |
| Single step (--step N) | { "step": "exec", "result": "(step-N)", "next": "verify", "checkpoint": "mid-exec", "timestamp": "..." } |
| Blocking dependency | { "step": "exec", "result": "(blocked)", "next": "(stop)", "checkpoint": "", "timestamp": "..." } |
executing (NEEDS_FIX), exec reads both .bugfix/ and .analysis/ latest files, using the most recent by filename date as fix guidance (.bugfix/ = mid-exec source, .analysis/ = post-exec source)--step N is used, the executor verifies prerequisites for that step are met, then signals (step-N) on completion for mid-exec checkpoint/moonview:check --checkpoint post-exec.test/ criteria is done during execution; full test suite / acceptance testing is part of the post-exec evaluation by checkAiTasks/<module>/.lock before proceeding and releases on completion (see Concurrency Protection in commands/ai-cli-task.md)research sub-command before planning. During execution, if you discover valuable implementation details via web searches, you may still save findings to AiTasks/.references/<topic>.md and update .summary.md — acquire AiTasks/.references/.lock before writing (see .references/ Write Protection in commands/ai-cli-task.md)verify --checkpoint step-N for domain-specific testing. For lightweight checks (build + lint), inline verification is sufficientauto mode (unattended), the following operations are PROHIBITED unless the plan explicitly calls for them: modifying .env or credential files, running destructive commands (rm -rf, git push --force, DROP TABLE), installing system-level packages (apt install, brew install), sending external requests (email, webhook, API calls to production). Violation → stop execution and signal (mid-exec) for human review