Sprint Manager

Purpose

To autonomously execute a sprint by coordinating the implementation of GitHub issues through a structured workflow that leverages subagents for isolated work and maintains a clean context window for sprint-level coordination.

When to Use

Use this skill in the following situations:

• •Starting work on a set of sprint issues from a GitHub milestone
• •Implementing multiple issues autonomously with minimal user intervention
• •Coordinating a development workflow that requires code review and integration
• •Managing serial execution of dependent or independent issues

Prerequisites

• •GitHub repository with issues assigned to a milestone
• •Git working directory is clean (no uncommitted changes)
• •gh CLI tool installed and authenticated
• •gemini CLI tool installed and authenticated (optional, for plan generation)
• •Codex MCP available for PR review
• •Project has issue-executor and change-integrator skills (or equivalent workflow)

Architecture

The sprint manager operates as a coordinator that delegates work to subagents:

Sprint Manager (main context)
│
├── For each issue:
│   ├── 1. Generate implementation plan (Gemini CLI or manual)
│   ├── 2. Create feature branch
│   ├── 3. Launch implementer subagent → creates PR
│   ├── 4. Review PR (Codex MCP)
│   ├── 5. Fix issues if needed (another subagent)
│   ├── 6. Merge on approval
│   └── 7. Launch integrator subagent → cleanup & retrospective
│
└── Report sprint summary

Core Workflow

Phase 1: Sprint Setup

1. •

   Identify sprint issues by querying the GitHub milestone:

   bash

   gh issue list --milestone "Sprint X" --state open --json number,title,labels
   

2. •

   Prioritize issues based on labels (P0 > P1 > P2) and dependencies

3. •

   Track progress using the TodoWrite tool with all sprint issues

Phase 2: Issue Execution Loop

For each issue in priority order:

Step 1: Generate Implementation Plan

Option A - Use issue-executor skill (if Gemini available):

bash scripts/work-on-issue.sh <issue-number>

Option B - Manual plan generation:

1. •Fetch issue details: gh issue view <number> --json title,body
2. •Read relevant specs from docs/specs/ or docs/changes/
3. •Call Gemini CLI with context to generate a step-by-step plan
4. •Create feature branch following convention: feat/<number>-<kebab-title>

Step 2: Delegate Implementation to Subagent

Launch a Task subagent with a comprehensive prompt including:

• •Issue number and acceptance criteria
• •Implementation plan from Step 1
• •Project conventions (from CLAUDE.md)
• •File paths and schema context
• •Expected deliverables (PR URL, test results, files created)
• •Fallback instructions if tools fail

Select appropriate subagent type based on the issue:

• •backend-architect - API routes, database schemas, backend logic
• •frontend-developer - React components, UI, client-side code
• •general-purpose - Mixed or unclear scope

Example prompt structure (see references/implementer-prompt-template.md):

## Task: Implement GitHub Issue #<number> - <title>

You are working on branch `<branch-name>` in `<working-directory>`.

### Issue Summary
<brief description>

### Implementation Plan
<step-by-step plan from Gemini or manual>

### Project Conventions
<key conventions from CLAUDE.md>

### Your Deliverables
1. Implement the code
2. Run lint and tests
3. Commit with conventional commit message
4. Push and create PR

### Report Back
<what to return: PR URL, test results, issues encountered>

Step 3: Review PR with Codex MCP

After subagent returns with PR URL:

mcp__codex__codex with prompt:
"Review PR #<number>: <title>
URL: <pr-url>

The PR implements: <summary>

Focus your review on: <relevant concerns>

Say APPROVED if ready to merge, or list issues with severity."

Step 4: Handle Review Feedback

If Codex finds issues:

1. •Launch another subagent to fix the issues
2. •Provide specific fix instructions from Codex feedback
3. •Re-review after fixes are pushed

If Codex approves:

• •Proceed to merge

Step 5: Merge PR

gh pr merge <number> --squash --auto

Wait for CI to pass, then verify merge:

gh pr view <number> --json state

Step 6: Post-Merge Integration

Launch integrator subagent (see references/integrator-prompt-template.md):

1. •Switch to main and pull latest
2. •Delete feature branch (local and remote)
3. •Update retrospective with learnings
4. •Close issue if not auto-closed
5. •Report completion status

Phase 3: Sprint Completion

After all issues are processed:

1. •Update TodoWrite to mark all issues complete
2. •Summarize sprint results:
   • •Issues completed
   • •PRs merged
   • •Key learnings
   • •Any blockers encountered
3. •Report to user

Error Handling

Gemini CLI Fails

If the Gemini CLI fails during plan generation:

• •Fall back to manual plan creation
• •Read issue details directly via gh issue view
• •Check relevant specs in docs/specs/ or docs/changes/
• •Construct implementation plan based on acceptance criteria

Subagent Fails

If an implementer subagent fails:

• •Review the error reported
• •Launch a new subagent with adjusted instructions
• •Consider breaking the task into smaller pieces
• •Flag for user intervention if repeated failures

Codex Review Times Out

If Codex MCP doesn't respond:

• •Retry the review request
• •Fall back to basic automated checks (lint, tests)
• •Flag PR for user manual review

PR Merge Conflicts

If merge fails due to conflicts:

• •Rebase the branch on main
• •Launch subagent to resolve conflicts
• •Re-run tests and review

Prompt Templates

See the references/ directory for detailed prompt templates:

• •references/implementer-prompt-template.md - Template for implementation subagents
• •references/integrator-prompt-template.md - Template for post-merge integration subagents
• •references/review-prompt-template.md - Template for Codex PR reviews

Best Practices

Context Management

• •Keep sprint-level state in the main context (issue tracking, PR URLs, blockers)
• •Delegate all implementation details to subagents
• •Each subagent gets a fresh context - include all needed info in the prompt

Prompt Crafting

• •Be specific about file paths and existing code context
• •Include project conventions explicitly (subagents don't read CLAUDE.md)
• •Specify exact deliverables and report format
• •Provide fallback instructions for common failure modes

Serial vs Parallel

• •Default to serial execution for safety and easier debugging
• •Only parallelize truly independent issues with explicit user approval
• •Never parallelize issues with shared file dependencies

User Communication

• •Report progress after each issue completes
• •Flag blockers immediately rather than retrying indefinitely
• •Provide sprint summary at the end

Notes

• •This skill is designed for serial execution to maintain context clarity
• •Each issue gets its own subagent context, keeping the main context clean
• •The workflow integrates with existing issue-executor and change-integrator skills
• •Codex MCP provides automated code review without user intervention
• •Retrospective updates capture learnings for future sprints