sprint-workflow
Execute this skill should be used when the user asks about "how sprints work", "sprint phases", "iteration workflow", "convergent development", "sprint lifecycle", "when to use sprints", or wants to understand the sprint execution model and its convergent diffusion approach. Use when appropriate context detected. Trigger with relevant phrases based on skill purpose.
- License 许可
- MIT
- 最近更新
- 2026-03-20
- Stars
- ★ 4
- Forks
- 0
01 前言 Front Matter
- name
- sprint-workflow
- author
- Damien Laine <damien.laine@gmail.com>
- license
- MIT
- version
- 1.0.0
- description
- Execute this skill should be used when the user asks about "how sprints work", "sprint phases", "iteration workflow", "convergent development", "sprint lifecycle", "when to use sprints", or wants to understand the sprint execution model and its convergent diffusion approach. Use when appropriate context detected. Trigger with relevant phrases based on skill purpose.
- allowed-tools
- Read
- compatible-with
- claude-code, codex, openclaw
02 资源文件 3
- 参考文档references/errors.md165 B
- 参考文档references/examples.md8.8 KB
- 参考文档references/sprint-phases.md1.6 KB
03 SKILL.md 正文
Sprint Workflow
Overview
Sprint Workflow describes the convergent diffusion execution model used by the Sprint plugin. A sprint progresses through six distinct phases -- from loading specifications through architectural planning, parallel implementation, testing, review, and finalization.
Prerequisites
- Sprint plugin installed (
/plugin install sprint) - Project onboarded via
/sprint:setup(creates.claude/project-goals.mdand.claude/project-map.md) - Sprint created via
/sprint:newwith a completedspecs.md - Understanding of the agent system (see the
agent-patternsskill)
Instructions
- Phase 0 -- Load Specifications. The orchestrator locates the sprint directory at
.claude/sprint/[N]/, readsspecs.mdfor requirements, readsstatus.mdif resuming a prior iteration, and detects the project type for framework-specific agent selection. See${CLAUDE_SKILL_DIR}/references/sprint-phases.mdfor the full phase reference. - Phase 1 -- Architectural Planning. The project-architect agent reads
project-map.mdfor architecture context andproject-goals.mdfor business objectives. It produces specification files (api-contract.md,backend-specs.md,frontend-specs.md) and returns SPAWN REQUEST blocks for implementation agents. - Phase 2 -- Implementation. The orchestrator spawns implementation agents in parallel based on the architect's SPAWN REQUEST blocks. Agents include
python-dev,nextjs-dev,cicd-agent, andallpurpose-agent. Each agent reads its assigned spec files and the sharedapi-contract.md, then returns a structured report. - Phase 3 -- Testing. Testing agents execute sequentially:
qa-test-agentruns first (API and unit tests), thenui-test-agentruns browser-based E2E tests. Framework-specific diagnostics agents (e.g.,nextjs-diagnostics-agent) run in parallel with UI tests. All agents produce test reports. - Phase 4 -- Review and Iteration. The architect reviews all agent reports, analyzes conformity against specifications, updates specs (removing completed items, adding fixes for failures), and updates
status.md. The architect then decides: spawn more implementation agents, run more tests, or finalize. - Phase 5 -- Finalization. The orchestrator writes the final
status.mdsummary, ensures all spec files are in a consistent state, cleans up temporary files likemanual-test-report.md, and signals FINALIZE to end the sprint. - Convergence model. Each iteration reduces noise: completed work is removed from specs, working code is preserved, and only failures are re-addressed. Most sprints converge within 3-5 iterations. After 5 iterations without convergence, the orchestrator pauses and prompts for manual intervention.
Output
- Phase-by-phase execution log showing agent spawns, reports, and decisions
- Updated
status.mdafter each iteration reflecting completed and remaining work - Specification files that shrink with each iteration as requirements are satisfied
- Final
status.mdsummary upon sprint completion - FINALIZE signal to the orchestrator when all specs are satisfied
Error Handling
| Error | Cause | Solution |
|---|---|---|
| Sprint stuck in iteration loop (hits 5 iterations) | Specs too broad or contain unresolvable conflicts | Review status.md for blocking issues; narrow scope or resolve conflicting requirements |
| Phase 2 agents not spawned | Architect SPAWN REQUEST missing or malformed | Verify architect agent produced valid SPAWN REQUEST blocks with correct agent names |
| Tests fail repeatedly on same issue | Implementation does not match contract | Compare agent output against api-contract.md; check for schema mismatches |
| Sprint cannot find specs | Wrong sprint directory number | Verify .claude/sprint/[N]/specs.md exists; run /sprint:new if needed |
| Architect skips testing phase | Testing section missing from specs.md |
Add QA: required and UI Testing: required to the specs (see spec-writing skill) |
Examples
Starting a new sprint:
/sprint:new # Creates .claude/sprint/1/specs.md
# Edit specs.md with requirements
/sprint # Executes the full phase lifecycle
Resuming after iteration pause:
# Review .claude/sprint/1/status.md for blockers
# Adjust specs.md to narrow scope or fix conflicts
/sprint # Resumes from Phase 0, reads updated specs and status
Typical convergence flow:
Iteration 1: Architect plans → 3 agents implement → tests find 2 failures
Iteration 2: Architect narrows specs to 2 fixes → agents patch → tests pass
Iteration 3: All specs satisfied → FINALIZE
Resources
${CLAUDE_SKILL_DIR}/references/sprint-phases.md-- Detailed reference for all six phases with agent assignments and handoff rules- Agent patterns skill for SPAWN REQUEST format and report structure
- Spec writing skill for authoring effective
specs.mdfiles - API contract skill for designing the shared interface between agents
04 同仓库更多 Skills
azure-apim-architecture
Analyzes and explains Azure API Management architecture decisions for enterprise API marketplace implementations using VNet Internal mode, Front Door, hybrid authentication, and multi-environment strategies. Use when discussing APIM component selection, network topology, cost optimization, or comparing alternatives like workspaces vs instances, VNet Internal vs External mode, or Front Door vs Application Gateway.
apiops-deployment
Guides deployment of Azure API Management infrastructure using Infrastructure as Code (Bicep/Terraform), CI/CD pipelines (GitHub Actions/Azure DevOps), and APIOps workflows. Use when deploying APIM, creating pipelines, or implementing dev→test→prod promotion strategies.
apim-policy-authoring
Creates production-ready Azure API Management policy XML for authentication (OAuth 2.0, JWT validation, subscription keys), rate limiting, CORS configuration, error handling, and API transformations. Use when implementing API security, access control, or request/response processing logic.
api-security-review
Reviews Azure API Management configurations for security vulnerabilities, OWASP API Security Top 10 compliance, VNet Internal mode validation, Private Link verification, and Azure Security Benchmark alignment. Use when performing security audits, pre-deployment validation, or compliance reviews.
jira-cli
Interact with Jira from the command line to create, list, view, edit, and transition issues, manage sprints and epics, and perform common Jira workflows. Use when the user asks about Jira tasks, tickets, issues, sprints, or needs to manage project work items.
calculator
Performs arbitrary-precision arithmetic calculations including addition, subtraction, multiplication, division, and exponents. Use when the user asks to calculate, compute, or evaluate math expressions, or when precise decimal arithmetic is needed to avoid floating-point errors.