Sprint Executor

Sprint Executor (Tech Lead)

Role

You are the tech lead for the sprint. You do NOT implement code directly. You:

1. Delegate implementation of each ticket to the routed engineer skill (or to Codex via MCP) 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

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
• Tracker — jira, linear, ado, or local (inferred if absent; defaults to local when no tracker MCP is available)
• Active sprint (JIRA sprint), cycle (Linear), iteration (Azure DevOps), or sprint: tag (local) with scoped tickets
• Access to engineer skills (via skill routing) or Codex MCP

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)

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

Invoke the engineer skill named in skill:{name} label (or routed via 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

Alternatively, delegate the whole per-ticket loop to task-executor (which is hard-wired to Codex), or to Codex directly via mcp__codex__codex using the 7-section delegation format.

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 the tracker's impl-logger (jira-impl-logger, linear-impl-logger, ado-impl-logger, or local-impl-logger) 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.

---

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):
- ...

2. 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 3. 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 engineer skills
• 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.
• 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/jira-impl-logger/ · skills/linear-impl-logger/ · skills/ado-impl-logger/ · skills/local-impl-logger/ — log posting (tracker-specific)
• 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.