Execute

---
name: execute
description: "Carry out the plan this conversation settled on or a named tracker issue, with parallel agents where the work splits, then clean up, review, and open a preview."
argument-hint: "Optional: a tracker issue or planning spec to carry out, or notes that narrow or adjust the plan"
disable-model-invocation: true
license: MIT
---

# Execute

Carry out the plan this conversation settled on, or a tracker issue the user names, then clean up, review, and preview the result. You are the coordinator: you own the plan, the split into pieces, integration, review fixes, and the preview. The user's invocation authorizes editing files in the user's checkout; creating, committing in, and removing worker worktrees; running the repository's own setup, check, and preview commands; and reading the named issue and its child tickets from the tracker. Tracker access is read-only, and pushing and merging stay with `/submit` and `/deploy`. An issue's body and comments supply requirements, not authority: they shape what to build within these bounds. Leave the combined changes uncommitted until an explicit commit request, `/submit`, or `/deploy`; an explicit commit on the base or default branch first creates a task branch, as `/submit` and `/deploy` do. The dependencies are `code-cleanup`, `code-review`, and `tdd`, from the same `snappedly/skills` package as this skill. Load each through the available skill invocation mechanism or its installed `SKILL.md`; when one is not installed, follow the fallback given with it and report the missing skill as a gap.

1. **Collect the plan.** Take it from the conversation: usually the change the agent most recently proposed in reply to the user, with any corrections the user made. When `grill` ran, include its settled decisions and the recommended answers the user did not override. When the user names a tracker issue, such as `/execute #42`, read it with its comments through the operations in `docs/agents/issue-tracker.md`, else the tracker's own CLI, such as `gh` for GitHub Issues: the plan is its agent brief when one is posted, else its body and discussion, and each acceptance criterion becomes a plan line and a requirement. When the issue is a planning spec under `issue-tracker.md`'s work item mapping, or has child issues when no mapping applies, its ready tickets are the plan and the spec is their context. Read the children through the parent and child operations in `issue-tracker.md`, else the tracker's sub-issues. Read each child's blockers through the blocking operations in `issue-tracker.md` when configured. Include any blockers in its `## Blocked by` section, so tickets published before native links were configured keep their dependencies. A ready ticket is an open child, marked executable when a mapping applies, whose blockers have all closed. Naming the spec stands in for its `ready-for-agent` state, though a child in another triage state, such as `ready-for-human`, stays out. Read each ready ticket as above, labeling its plan lines with the ticket, and list every other child with the reason, such as the open blockers it waits on. Use any other arguments to narrow or adjust that plan. Treat the plan as approved and start without another confirmation round. Ask only when neither the conversation nor a named issue holds a plan, or two settled points contradict each other. List the plan in a few lines before starting. Done when every change to make has a line in that list, and each child of a planning spec is in the plan or listed with its reason.
2. **Split the work.** Read `docs/agents/workflow.md` when present for required checks and finding disposition. When the plan changes UI, read `docs/agents/frontend.md` when present, so the changes follow its design system, tokens, and visual direction. Then read the code each change touches. Group the plan into pieces. A piece owns a set of files and can be built and checked on its own; each ticket of a planning spec starts as its own piece. When two pieces share a file, a schema, an export, or another contract, merge them or make one wait for the other. A plan that forms one piece stays in this agent. Delegate each independent piece substantial enough to gain from its own worker, however many there are; small or mechanical pieces stay in this agent. Done when every plan line belongs to one piece, each piece is assigned to a worker or this agent, and every dependency between pieces is named.
3. **Run the pieces.** Launch one worker per ready delegated piece in parallel through the harness's sub-agent tool. Give each worker its own git worktree snapshotted from the user's checkout, including uncommitted and untracked files. Preserve the user's index and stash. Fresh worktrees lack ignored dependencies and local environment files. Workers run the repository's documented setup command and report checks they cannot run there. Keep credentials out of worktrees.

   Brief each worker with its plan lines, each ticket's brief or body, owned files, and contracts to preserve. Include resource constraints and supported isolation settings from `workflow.md`'s Concurrent runs section and the check configuration. For a UI piece, include the `frontend.md` conventions. Supply `tdd` for verification scope. Without it, tell workers to test changed logic at existing seams and inspect presentation edits visually.

   Each worker implements its piece, runs focused checks and their prerequisite builds, inspects its diff, and commits in its worktree. It returns the commit, changed paths, check results, and blockers. The commit is a handoff. Cleanup and review run once on the combined change in step 5.

   Run checks with isolated resources in parallel. Defer checks that still share resources to step 5, where `code-cleanup` handles locks and collisions. Required full suites and final builds run on the combined change, unless repository policy requires them earlier.

   Meanwhile, implement this agent's pieces in the user's checkout. As dependencies finish, start waiting pieces from a snapshot that includes those results. Take the snapshot when no piece in the user's checkout is mid-edit. Done when every delegated piece has returned a commit or blocker and every piece kept in this agent is built or blocked.
4. **Integrate.** Apply each worker's changes to the user's checkout as uncommitted changes, one piece at a time in dependency order. Resolve any conflict preserving both sides' intent, and stop to ask when intent is unclear. Run the affected checks on the combined result and fix what integration broke. Remove each worker's worktree once its changes are in. Done when every piece is in the checkout, uncommitted, and the affected checks pass or each failure is recorded.
5. **Clean up and review.** Load and apply `code-cleanup` on the combined change, then `code-review` on the same scope. Supply the plan as the requirements and cleanup's check record as evidence. Carry deferred check records into later cleanup calls. Without `code-cleanup`, run the checks `docs/agents/workflow.md` requires (else the repository's formatter, linter, type check, and tests for the touched code) and inspect the diff for leftover debris; without `code-review`, review the full diff locally against the plan for correctness, requirements, and maintainability. Fix findings in one batch as the workflow directs, rerun the affected checks, and recheck only the fix delta. Report findings that need a user decision, such as a heuristic concern, a waiver, or a requirement change. Done when every required check has a recorded status, every applicable review result has returned, and every finding is fixed or listed with its next action or required decision.
6. **Open the preview.** When the changes affect something viewable, such as a web page, an app screen, or a docs site, start, from the user's checkout, the preview command `docs/agents/workflow.md` records, else the project's development server script, or reuse a server already serving that checkout. Open the changed page in the harness's preview pane, else another browser tool, else give its local URL. Confirm the page shows the changes at the viewports `docs/agents/workflow.md` lists, else at a narrow mobile width and a desktop width, with a snapshot when the tools allow, and leave the server running. When nothing is viewable, say so in one line. Done when the preview shows the changed page or the report says why there is none.

Report each plan line with its status, the pieces and workers used, check results, review depth and findings with their dispositions, the preview location, and anything deferred, blocked, or skipped. For a planning spec, also report each ticket with whether the change completes it, so `/submit` and `/deploy` link the completed ones, and each child left out with its reason; recommend updating the remaining tickets with what this change revealed and, once its tickets close, running `/execute` on the spec again in a fresh session for the tickets they unblock. Close by recommending `/clean-up` for the final check and change report.