execute

A workflow for carrying out an active sprint in ordered waves, with separate execution agents working in parallel where safe. A sprint is a planned batch of development work.

In plain words
What is it for?
Use it to execute sprint plans, check that parallel tasks do not edit the same files, run test gates, verify the result, and open a pull request.
Why use it?
It coordinates implementation, testing, verification, status updates, and pull-request creation across the sprint.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/koolamusic/claudefiles/execute
Clone the repo
git clone --depth 1 https://github.com/koolamusic/claudefiles
Per session 42 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,674 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00042 $0.01674
Opus 5 $0.00021 $0.00837
Sonnet 5 $0.00008 $0.00335
Haiku 4.5 $0.00004 $0.00167

Measured 2d ago against content hash 2ea45152070a, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

execute scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/jira/commands/execute.md · 101 lines

How it starts

The opening of the file, as written. The whole thing — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Execute the active sprint to completion: every plan executed (parallel within wave), Nyquist criteria validated, goal-backward verification, PR opened.

Steps

  1. Locate the active sprint: slug=$(cat .jira/CURRENT). Stop if missing.

  2. Verify plans exist: ls .jira/sprints/<slug>/*-PLAN.md. Stop if zero — tell the user to run /jira:plan.

  3. Read frontmatter from all plans. Build a wave map (wave and plan IDs are Roman):

    wave I: [I, II]
    wave II: [III]
    wave III: [IV, V]
    

    Pull worktree, branch, issue from any plan (they share these).

  4. Validate parallel-safety within each wave. For each wave, confirm no two plans have overlapping files_modified. If overlap detected, stop and report — this is a planner bug, route back to /jira:plan.

  5. Update STATE.md. Set sprint status to executing. Update last_activity.

  6. Verify clean working tree before delegating: git status --porcelain. If dirty, ask via AskUserQuestion: stash / commit-elsewhere / abort. Don't auto-stash.

  7. Wave-by-wave execution. For each wave in order:

    • Spawn one jira-executor per plan in this wave, in parallel (single message, N Agent calls). Each executor receives:
      • Sprint slug, its plan path, all plan paths (for parallel_with awareness), context path, execution log path, execution template.
    • Wait for all executors in this wave to return. Collect their statuses.
    • If any executor returns deviation or blocked: stop the wave loop. Surface the EXECUTION.md notes via AskUserQuestion: revise plan, retry from current wave, or abort. Don't auto-revise.
    • If all executors return complete: proceed to next wave.
  8. All waves done — spawn jira-nyquist with sprint slug + all plan paths + feature paths (features/*.feature) + execution log path + worktree path (if any). Returns GAPS FILLED (green), PARTIAL (red), ESCALATE (red), or NO TEST INFRA.

  9. If Nyquist red: surface the failing/escalated criteria via AskUserQuestion: route back to executor (with new task), accept-as-is and proceed with caveat, or abort.

  10. If Nyquist NO TEST INFRA: ask user via AskUserQuestion whether to proceed without test validation or pause to set up testing.

  11. If Nyquist green (or user accepts caveat) — spawn jira-verifier with sprint slug + sprint dir + all plan paths + feature paths (features/*.feature) + context path + execution path + verification output path + verification template. Returns verdict: PASS | PARTIAL | FAIL.

  12. If verifier FAIL: the goal isn't actually delivered. Surface VERIFICATION.md findings via AskUserQuestion: route back to planner with the gap list, route back to executor for specific outcomes, or abort. Do NOT open a PR on a FAIL.

  13. If verifier PARTIAL: surface findings via AskUserQuestion: extend sprint with follow-up plan, accept-as-is and open PR with caveat in body, or abort.

  14. If verifier PASS — open the PR.

  • Determine the worktree to PR from. If worktree: true, the branch is <branch> from PLAN frontmatter and lives in the worktree the executor created. If worktree: false, the branch is the current branch (it should not be main — if it is, ask the user which branch to push to).
  • Push: git push -u origin <branch>
  • Write the PR body for an external reader per ${CLAUDE_PLUGIN_ROOT}/templates/author-conventions.md: state the WHAT and why it matters, not the internal how. No internal jargon, no .jira/ paths, no sprint slugs or wave labels, no agent/tool names (e.g. Nyquist, verifier), no AI-attribution trailer.
  • Pick the link keyword (base-aware). default=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name). If this PR's base is $default (it lands on main), use Closes #<issue>. Otherwise — a feature PR into a canary/integration branch — use Refs #<issue>. Omit if no issue in frontmatter. Auto-close must only ever fire on the default branch.
  • Open PR:
    gh pr create \
      --title "<sprint goal from any PLAN frontmatter>" \
      --body "$(cat <<'EOF'
    ## Summary
    <one sentence: the outcome — the change in capability or contract>
    
    ## What changed
    <2–4 plain-English bullets: what changed and why it matters>
    
    ## Validation
    - <how it was checked, in plain English: new behavior covered by tests, goal verified end to end>
    
    <Refs #<issue> — or Closes #<issue> when this PR targets the default branch; omit if no issue>
    EOF
    )"
    
  • Capture the PR URL, append to EXECUTION.md.

Read the full file on GitHub · 101 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 101 lines · 42 tokens per session scan A 2ea45152070a

Subscribe to this mod's changes

execute is a command published in the GitHub repository koolamusic/claudefiles (132 stars, last pushed 3d ago), licensed MIT. It adds 42 tokens to every session and 1,674 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.