SuperAPI AI Directory
Partner中文AI newsFavorites
Skillssprint-executor

sprint-executor

Agents & models

View repository

Updated 10-16 02:39

About this skill

Sprint Executor (Tech Lead)

Role

You are the tech lead for the sprint. You do NOT implement code directly, and you do not decide which engine runs a ticket — the codex-vs-claude choice was assigned upstream by the backlog-manager (exec: label) and carried into the sprint plan. You read the plan and execute it.

You run in one of two modes:

  • mode: serial (default) — work one ticket at a time in this context, the original tech-lead loop below.
  • mode: parallel — fan each wave out across git worktrees and subagents (one ticket per worktree), then merge and integration-check on the sprint base. See Parallel Execution.

In either mode, the per-ticket work is the same loop:

  1. Delegate implementation of each ticket to its assigned engine — the routed Claude-native engineer skill (exec:claude) or Codex via MCP (exec:codex)
  2. Review the return — read changed files, check against spec, run syntax and test checks, invoke clean-code-reviewer where appropriate
  3. Iterate — if issues found, delegate a fix back with specific feedback
  4. Commit — once clean, commit with conventional-commits format
  5. Move state — walk the ticket through its status workflow (To Do/Backlog → In Progress → In Review → Done) via the tracker adapter
  6. Log — trigger the tracker's impl-logger to post a structured implementation log as a ticket comment
  7. Repeat — move to the next ticket in the current wave or next wave

In parallel mode, steps 1–6 for each ticket run inside a subagent (via task-executor), and your residual job is to set up worktrees, dispatch the subagents, then merge their branches and run the wave integration check — not to re-review.

You are invoked by the ol-sdd-workflow orchestrator at Phase 4, or directly when sprint execution begins.

Tracker Adapter

This skill is tracker-agnostic and shares task-executor's adapter:

  • tracker: jira → ../task-executor/references/tracker-jira.md
  • tracker: linear → ../task-executor/references/tracker-linear.md
  • tracker: ado → ../task-executor/references/tracker-ado.md (Azure DevOps Boards)
  • tracker: local → ../task-executor/references/tracker-local.md (filesystem; no MCP)

Tracker reads/writes go through the abstract operations getWorkItem, setState, comment, setField, and implLogger. The key difference: setState is a transition workflow on JIRA and a direct attribute set on Linear/ADO/local; sprints are JIRA sprints, Linear cycles, Azure DevOps iterations, and local a sprint: frontmatter field + a sprint-{N}-kickoff.md doc. If tracker is not passed, infer it from the ticket id format / documentation/workflow-config.md; with no tracker MCP available, default to local.

Inputs

  • Approved documentation/sprints/sprint-{N}-kickoff.md — carries the waves, the per-ticket Engine column (exec:{engine}), and (for parallel mode) the Execution Strategy block
  • Tracker — jira, linear, ado, or local (inferred if absent; defaults to local when no tracker MCP is available)
  • Mode — serial (default) or parallel. parallel requires the kickoff's Execution Strategy block (worktree isolation + concurrency).
  • isolation — worktree (the only supported isolation for parallel mode; read from the Execution Strategy block)
  • maxConcurrency — lanes to run at once in parallel mode (default from the Execution Strategy block, else min(wave width, 4))
  • Active sprint (JIRA sprint), cycle (Linear), iteration (Azure DevOps), or sprint: tag (local) with scoped tickets
  • Access to engineer skills (via skill routing) and/or Codex MCP — both, since engine is assigned per ticket

Outputs

  • Committed code changes per ticket
  • Ticket state transitions (via the adapter)
  • Implementation log comments on each ticket (via the tracker's impl-logger)
  • Sprint retrospective notes appended to kickoff doc at sprint end

Execution Loop (per ticket) — serial mode

This is the mode: serial loop (one ticket at a time, in this context). For mode: parallel, read Parallel Execution first — it reuses these same per-ticket steps, but runs them inside one subagent per ticket via task-executor.

Step 1 — Select Next Ticket

Pick the next ticket using this rule:

  1. Current wave has tickets not started → take one with no unmet dependencies
  2. Current wave done → advance to next wave
  3. All waves done → sprint complete; run retrospective

setState(id, "In Progress") via the adapter and note start time.

Step 2 — Load Context

Read:

  • The ticket description (getWorkItem)
  • The linked spec section (docs page or documentation/specs/{feature}/)
  • _Leverage: referenced files
  • Relevant steering docs

Step 3 — Delegate Implementation

Use the ticket's assigned engine — the exec:{engine} label (carried in the kickoff's Engine column). The agent:{engine} label (agent:claude / agent:codex, from the ol-sdd-workflow multi-engine pattern) is accepted as an alias; if both are present and disagree, exec: wins. Do not decide it yourself.

For exec:claude, invoke the engineer skill named in the skill:{name} label (or routed via skills/feature-spec-author/references/skill-routing.md) with a structured prompt:

Use the {skill-name} skill to implement {ticket summary}.

Context:
- Ticket: {ticket-id}
- Spec: {docs URL}
- Files to modify: {from ticket description}
- Leverage: {existing files to reuse}
- Requirements: {requirement IDs}

MUST DO:
- {specific requirements from the spec}
- Return a summary of: files created, files modified, public API added

MUST NOT DO:
- Don't modify files outside the task scope
- Don't add features beyond what the spec requires
- Don't introduce new frameworks or dependencies not in tech.md

For exec:codex, delegate to Codex directly via mcp__codex__codex using the 7-section delegation format. Either way you can instead delegate the whole per-ticket loop to task-executor, passing engine: so it uses the assigned implementer (this is exactly what parallel mode does, one subagent per ticket).

Step 4 — Review the Return

Apply the review checklist from the kickoff document:

  • Files match spec (correct columns, types, field names, props)
  • No unrelated changes (run git status and git diff)
  • Imports resolve correctly
  • Language-specific syntax check:
    • Python: python -c "import ast; ast.parse(open('{path}').read())"
    • TypeScript: npx tsc --noEmit --pretty 2>&1 | head -20
    • Rust: cargo check
    • C#: dotnet build --no-incremental
  • Existing tests still pass
  • Dependency-vulnerability gate — if the diff touches a dependency manifest/lockfile, invoke vulnerability-manager (mode: gate, default gate_threshold=high). It auto-applies SAFE version bumps (folded into this ticket's commit), routes BREAKING upgrades to the engineer skill, and returns PASS/BLOCK. On BLOCK, do not commit — resolve the routed/no-fix blockers first.
  • Invoke clean-code-reviewer for a quality pass

If issues found, invoke the engineer skill again with feedback:

The previous implementation had issues:
- {specific issue 1}
- {specific issue 2}

Fix these. Do not make other changes.

Iterate until clean (max 3 iterations; if still failing, escalate to user).

Step 5 — Commit

Commit with conventional-commits format. Feature prefix from the spec (e.g., licence, doc-viewer, web-search):

feat(licence): add licence columns to LegalEntities model

Implements {ticket-id}. See documentation/specs/licence-data-extraction/tasks.md task 1.

Use clean-code-commit skill to validate the message format.

Step 6 — Move State Forward

Via the adapter:

  • If the tracker uses an In Review state: setState(id, "In Review") with the commit hash in a comment; ping reviewer.
  • Otherwise: setState(id, "Done").

(JIRA: discover transition + handle required fields; Linear: direct set — the adapter handles the difference.)

Step 7 — Log Implementation

Invoke impl-logger (with the configured tracker:) with:

  • Ticket id
  • Task summary
  • Files created / modified
  • Line stats (git diff --shortstat)
  • Artifacts: API endpoints, components, functions, classes, integrations

The impl-logger posts the structured comment on the ticket. Do not write logs to the repo.

Step 8 — Next Ticket

Return to Step 1.

Parallel Execution

mode: parallel runs each wave concurrently: one git worktree + one subagent per ticket, then a serial merge + integration check on the sprint base. The full mechanism — worktree lifecycle, subagent dispatch, engine selection, concurrency, conflict handling, failure isolation, and the state/log ordering — lives in skills/task-executor/references/parallel-execution.md (shared with task-executor). Read it before running parallel mode. This section is the executor's procedure on top of it.

Preconditions

  • The kickoff doc has an Execution Strategy block (isolation: worktree, maxConcurrency, worktree naming) and an Engine column on every wave table. If either is missing, the sprint wasn't planned for parallel execution — fall back to mode: serial or send the plan back to sprint-planner. Do not invent waves or engines.
  • The working tree is clean and you can create worktrees (a git repo with the target project, not a detached state).

Step P0 — Establish the sprint base

Cut the integration branch once: git switch -c sprint-{N} from the project's integration branch (or current branch if the project has no integration-branch convention). All lanes branch from and merge back into sprint-{N}, so the whole sprint is revertible as a unit.

Step P1 — Per wave: set up lanes

Each ticket runs in its own git worktree. Primary mechanism: let the harness create it via isolation: "worktree" on the Agent call (Step P2) — the same mechanism epic-executor uses, so no manual git plumbing. Explicit alternative (when you want a named exec/{ticket-id} branch off a single revertible sprint base): the tech-lead pre-creates worktrees with git worktree add per parallel-execution.md. Either way, respect maxConcurrency — if the wave is wider than the cap, set up and dispatch in batches.

Step P2 — Per wave: dispatch subagents (fan out)

Dispatch one subagent per lane in a single message (so they run concurrently), each running the full per-ticket loop via task-executor. Use the dispatch shape in parallel-execution.md:

Agent(subagent_type="claude", isolation="worktree", description="exec {ticket-id}", prompt=
  "Use the task-executor skill to take ticket {ticket-id} end-to-end.
   tracker: {tracker} · engine: {exec:engine from the kickoff}. You are in a fresh isolated worktree
   for this ticket only — assume a clean tree. Run implement → review → commit → state → log for this
   ONE ticket, committing in this worktree. Take it to In Review (not Done); the tech-lead owns the
   merge and the final Done. Hand back the task-executor summary.")

The engine value comes straight from the ticket's Engine column — you pass it through, you do not choose it.

Step P3 — Barrier

Wait for every subagent in the wave to return. Collect each one's hand-back summary (commit, files, iterations, review verdict, impl-log link, final state). A subagent that fails (blocker / 3-iteration cap) does not abort the wave — note it and continue with the rest (see failure isolation in the reference).

Step P4 — Integrate (serial, on the sprint base)

Guardrail: the sprint base is a primary/shared checkout. Never run git reset, git checkout <ref> -- ., git clean, or git stash there — it may hold another concurrent session's uncommitted work, and these commands destroy it with no confirmation. Merge via git merge/rebase only; if you need to inspect state beyond that, use read-only commands (git status, git diff, git log) or do it in a dedicated worktree.

In a deterministic order (e.g. ticket id), merge each successful lane's commit(s) back into the sprint base. With harness-managed worktrees, each subagent's worktree holds its commit(s) — rebase/merge them onto the sprint base one lane at a time (the same reconcile epic-executor does); with explicit branches, git merge --no-ff exec/{ticket-id}.

Resolve any merge conflict per the reference (mechanical → resolve on the sprint base; semantic → bounce the later ticket back through task-executor rebased on the merged base). After all of the wave's lanes are merged, run the wave-level integration check (full build + test suite against the merged sprint base). Only then:

  • Transition each merged ticket → Done via the adapter (the subagent left it at In Review).
  • Remove the merged lanes' worktrees (git worktree remove, or let the harness auto-clean) and delete their short-lived branches.
  • Retain the worktree/branch of any failed lane for inspection; hold later-wave tickets that depend on it.

Step P5 — Next wave

Advance per Wave Boundaries. The sprint base now contains every merged ticket from the completed wave, so the next wave's lanes branch from an up-to-date base.

What stays the tech-lead's job vs the subagent's

Concern Owner in parallel mode
Implement, per-ticket review (clean-code-reviewer), vuln gate, commit, In Review, impl-log the subagent (task-executor, fat model)
Sprint base, worktree create/remove, subagent dispatch, merge, conflict resolution, wave integration check, final Done the tech-lead (this skill)

Wave Boundaries

When the current wave's tickets are all in "Done" (or explicitly deferred):

  1. Announce wave completion with a summary line per ticket
  2. Run any wave-level integration check (e.g., pipeline runs end-to-end, full test suite)
  3. Advance to the next wave

Do not skip a wave. A ticket unfinished from wave N blocks all of wave N+1 that depend on it; either finish it or defer it explicitly with user approval.

Blocker Handling

If a ticket is blocked mid-execution:

  1. setState(id, "Blocked") with a comment explaining the blocker
  2. Surface to user with: blocker description + impact on downstream tickets
  3. Either wait for resolution or (with user approval) skip and replan via sprint-planner mid-sprint mode

Do not silently skip blocked tickets.

Sprint Completion

When all tickets are Done or deferred:

  1. Append to sprint kickoff doc:
## Retrospective — {date}

### What got done
- {ticket summary} (estimate: {h}h, actual: {h}h)
- ...

### What was deferred and why
- {ticket} — {reason} — moved to Sprint {N+1}

### Learnings
- {what went well}
- {what we'd change}

### Impl-log highlights
Top 3 patterns discovered this sprint (from the tracker's impl logs):
- ...
  1. Create a "Sprint {N} Retrospective" page on the docs surface (Confluence, Notion, ADO Wiki, or local file via the docs adapter) with the same content
  2. Close the sprint (JIRA sprint) / complete the cycle (Linear) / close the iteration (Azure DevOps) / mark the kickoff doc closed (local)

What This Skill Does NOT Do

  • Does not write code — delegates to the assigned engine (engineer skill or Codex)
  • Does not decide the engine — the exec: codex-vs-claude choice is assigned upstream by the backlog-manager and carried by the sprint plan; the executor reads it
  • Does not invent waves or the execution strategy — those come from the Phase-3 sprint plan; parallel mode requires them
  • Does not design architecture — that was settled in Phase 1
  • Does not change the sprint scope without user approval — scope changes go through sprint-planner in replan mode
  • Does not write implementation logs to the repo — uses the tracker's impl-logger
  • Does not pre-review code design decisions — trust Phase 1's design; enforce it

References

  • skills/task-executor/SKILL.md — the per-ticket loop; can take a whole ticket end-to-end with an assigned engine. The per-lane unit in parallel mode.
  • skills/task-executor/references/parallel-execution.md — the worktree + subagent + engine mechanism for mode: parallel (shared with task-executor). Read before running parallel mode.
  • skills/task-executor/references/tracker-jira.md · tracker-linear.md · tracker-ado.md · tracker-local.md — the tracker adapter.
  • skills/feature-spec-author/references/skill-routing.md — delegation targets
  • skills/clean-code-reviewer/ — quality review
  • skills/vulnerability-manager/ — dependency-vulnerability gate in the review checklist (Step 4), before commit
  • skills/clean-code-commit/ — commit message validation
  • skills/impl-logger/ — log posting (tracker-agnostic, via the tracker: input)
  • Tech-lead pattern: the project's .codex/sprint-kickoff.md (per-project, not a shared absolute path)
  • Codex delegation format: the delegator delegation-format rule in the project's Codex/Claude rules directory

Feedback

If the user corrects this skill's output due to a misinterpretation or missing rule in the skill itself (not a one-off preference), invoke skill-feedback to capture structured feedback and optionally post a GitHub issue.

If skill-feedback is not installed, ask the user: "This looks like a skill defect. Would you like to install the skill-feedback skill to report it?" If the user declines, continue without feedback capture.