arn-code-execute-task

Arness Execute Task

Execute a single task from the task list by spawning a arn-code-task-executor agent. Optionally run a arn-code-task-reviewer to validate the implementation before marking the task complete.

Pipeline position (this is an alternative entry point, not in the main pipeline):

arn-code-taskify -> arn-code-execute-task (single task) -> [optional] arn-code-review-implementation

Use cases:

• Re-running a failed task after manual intervention
• Testing a single phase independently
• Implementing one task without the full pipeline
• Retrying a task that was escalated during arn-code-execute-plan

Prerequisites

If no ## Arness section exists in the project's CLAUDE.md, inform the user: "Arness is not configured for this project yet. Run /arn-implementing to get started — it will set everything up automatically." Do not proceed without it. Task list must exist (run /arn-code-taskify first).

Workflow

Step 1: Load Configuration

1. Read the project's CLAUDE.md and extract the ## Arness section to find:
2. Plans directory -- base path where project plans are saved
3. Code patterns -- path to the directory containing stored pattern documentation
4. Template path -- path to the report template set (JSON templates)
5. Template version -- plugin version the templates were copied from (if present)
6. Template updates -- user preference: ask, auto, or manual (if present)
7. Specs directory -- path to the directory containing specification files (if present)

Template version check: If Template version and Template updates fields are present, run the template version check procedure documented in arn-code-save-plan Step 1 (Template Version Check) before proceeding. If ## Arness does not contain these fields, treat as legacy and skip.

Step 2: Identify the Task

• If user provided a task ID or number: verify it exists in TaskList
• If user provided a description: search TaskList for a matching task
• If no task specified: show all available tasks (pending, unblocked) and ask user to choose
• Show the selected task: ID, description, status, dependencies
• If task is blocked: warn user that dependencies haven't completed, ask if they want to proceed anyway

Step 3: Choose Review Option

Ask (using AskUserQuestion):

"Run with review gate after execution?"

Options:

1. Yes, review after execution (Recommended) -- Spawn reviewer to validate
2. No, execute only -- Skip review, mark complete after executor finishes

If review chosen, also ask:

Ask (using AskUserQuestion):

"How should Arness handle critical review findings?"

Options:

1. Resume executor with feedback (Recommended) -- Resumes the original agent with its full implementation context
2. Dispatch fresh executor with review report -- Spawns a new executor with the review report as context

Store the choice for the execution session.

Step 4: Execute the Task

1. Ask the user for PROJECT_NAME if not provided in the trigger message
2. Verify the project directory exists:

`` <plans-dir>/<PROJECT_NAME>/ ├── INTRODUCTION.md ├── TASKS.md ├── PROGRESS_TRACKER.json ├── plans/PHASE_*.md └── reports/ ` If PROGRESS_TRACKER.json` is missing, warn that progress tracking will not be available. Execution can still proceed.

1. Mark task as in_progress via TaskUpdate
2. Check if the project has ### Visual Testing configured in the ## Arness section of CLAUDE.md. If found, extract: capture script path, compare script path, baseline directory, diff threshold.

Note: Extract only the top-level fields (implicit Layer 1). Do NOT parse #### Layer N: subsections — multi-layer visual validation runs during /arn-code-review-implementation, not per-task.

1. Determine the executor model. First check the per-phase upgrade override:
2. Read PROGRESS_TRACKER.json. Find the phase entry whose implementation.taskId matches the current task ID.
3. If phase.implementation.modelOverride is non-null (e.g., "opus"), use that value as the model parameter for this dispatch. Skip the standard agent-models lookup. Emit a one-line status to the user: Phase <N> (<phaseTitle>) executor model: <override> (upgraded — complex phase per pipeline.complex-phase-upgrade).
4. If phase.implementation.modelOverride is null or the field is missing, fall through to the standard lookup: pass the model from .arness/agent-models/code.md as the model parameter (see plugins/arn-code/skills/arn-code-ensure-config/references/ensure-config.md "Dispatch convention" for fallback).

Then spawn arn-code-task-executor via the Task tool with the determined model. Full context:

• Task ID and full task description
• Project name: <PROJECT_NAME>
• Project folder path: <plans-dir>/<PROJECT_NAME>/
• Phase plan file path (extracted from the task description)
• INTRODUCTION.md path: <project-folder>/INTRODUCTION.md
• Code patterns directory path: <code-patterns-dir>/
• Specs directory path: <specs-dir>/ (if relevant to the task)
• Report template path: <template-path>/
• Visual testing config (if configured): capture script path, compare script path, baseline directory, diff threshold
• Record the agent ID returned by the Task tool (needed for resume mode)
• Wait for executor to complete

Step 5: Review (if requested)

1. Read the executor's output to extract:
2. Report file path(s)
3. List of files created and modified
4. Visual capture directory path (if reported)
5. Spawn arn-code-task-reviewer via the Task tool, passing the model from .arness/agent-models/code.md as the model parameter (see plugins/arn-code/skills/arn-code-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:
6. Task ID and full task description
7. Project name and folder path
8. INTRODUCTION.md path
9. Code patterns directory path
10. Report template path (for TASK_REVIEW_REPORT_TEMPLATE.json)
11. Implementation/testing report path(s) from executor
12. List of files created/modified by executor
13. Visual testing config (if configured in Step 4): compare script path, baseline directory, diff threshold
14. Note: Only Layer 1 visual config is passed to the reviewer. Multi-layer visual validation runs during /arn-code-review-implementation.
15. Visual capture directory (if reported by executor)
16. Handle verdict:
17. pass -- mark task as completed via TaskUpdate
18. pass-with-warnings -- append warnings to implementation report (reviewFindings section), mark task as completed via TaskUpdate
19. needs-fixes -- apply chosen feedback mode:
20. Resume mode: resume the original executor agent (using its agent ID from Step 4.6, via the resume parameter of the Task tool) with review feedback, then re-run reviewer
21. Fresh dispatch mode: spawn a new executor with the review report + original context, then re-run reviewer
22. Maximum 2 review cycles, then escalate to user with full findings
23. After marking the task as completed (pass or pass-with-warnings), update PROGRESS_TRACKER.json:
24. Read <plans-dir>/<PROJECT_NAME>/PROGRESS_TRACKER.json
25. Find the phase entry whose implementation.taskId or testing.taskId matches this task
26. Set the matching status to "completed" and completedAt to current ISO 8601 timestamp
27. Set review.verdict to the reviewer's verdict and review.reviewCycles to the number of review cycles
28. If all phases now have implementation.status = "completed" (and testing.status = "completed" or "none"), set overallStatus to "completed"; otherwise set overallStatus to "in_progress" (if not already)
29. Update lastUpdated and write to disk
30. If no review was requested: same update but leave review.verdict and review.reviewCycles at their initial values
31. If `PROGRESS_TRACK