sprint

name	sprint
description	Manages the sprint workflow for focused changes. Use when asked to add, fix, update, implement, debug, or build — see the Workflow tiers section for what's out of scope.
category	dev
tags	["workflow","planning","quality","tickets","orchestration"]
depends	[]

Sprint

CLI-backed commands:

Command	When
sprint start	Any normal or high-risk dev request
sprint complete	When you believe the work is done

The sprint CLI owns deterministic workflow state: ticket creation, active ticket tracking, context file creation, and close validation. The agent owns sprint doc creation, orientation, gray-area resolution, impact analysis, implementation, review, and test judgment.

Workflow tiers

Choose the lightest tier that still protects the work.

Trivial

Use no sprint when:

• The request is a question or explanation
• The change is a single line or trivially mechanical (e.g. rename, typo fix, config tweak)
• The user explicitly says to skip it ("just fix it", "quick change")

Not trivial — use normal tier when the change:

• Adds a new file (test, script, config, doc)
• Wires into test or build infrastructure
• Modifies a hook, pipeline, or post-commit script
• Touches more than one file with coordinated intent

None of these four triggers can be downgraded to trivial mid-sprint — complete.md's and start.md's downgrade rule explicitly excludes them (see skills/sprint/reference/complete.md steps 2-3, Reviewer gate / Evaluator review).

Work directly, then report verification.

Normal

Default for focused, reversible product/docs/code changes that affect a small surface.

Run sprint start, create acceptance.md and plan.md, then build after approval. Keep plan.md brief: files, approach, known constraints. Test plan goes in acceptance.md ## Test Plan, not plan.md.

Skip full orient, grill, and impact-analysis unless the local code is unclear or a high-risk trigger appears.

High-risk

Use the full planning pipeline when any condition applies:

• Security-sensitive behavior changes: auth, authorization, secrets, sessions, crypto, external input, file writes, API endpoints
• Irreversible or hard-to-reverse operations: deletes, sends, payments, migrations, data rewrites, publishes, deploys
• Broad audience or shared-state blast radius
• Multiple UI/API/job trigger paths reach the same behavior
• Downstream consumers react to the changed data or event
• The implementation has genuine gray areas that would materially change the design

High-risk sprints run orient, grill, impact-analysis, required mitigation tests, and wrapup.

sprint start

Read skills/sprint/reference/start.md for the full protocol (steps 1-11).

sprint complete

Read skills/sprint/reference/complete.md for the full protocol (trigger, confirmation, steps 1-10).

Planning files

Canonical layout:

.tickets/<id>/
  ticket.md        ← tkt-managed; never edit status directly — valid values: open, in_progress, closed, cancelled
  acceptance.md    ← definition of done + test plan + ## QA (Tested locally); all three sections are seeded at sprint start with an unchecked box, which blocks close if left unchecked
  plan.md          ← approach, decisions, grill/impact sections for high-risk; ## Sign-off skeleton (with an unchecked approval box) is created at sprint start, filled in and checked on approval, re-read after compaction
  research.md      ← objective truth compression, written before ## Approach; brief bullets for normal-tier, full orient protocol for high-risk/brownfield
  review-notes.md  ← advisory reviewer findings (code quality, scope, standards) + YES/NO verdict; written at sprint complete for normal+ sprints
  eval-report.md   ← adversarial per-criterion grades (pass/fail with file:line) + evaluator-run-id; written at sprint complete for normal+ sprints
  summary.md       ← plan-vs-actual table; written at sprint complete

DECISIONS.md

Repo root. Records durable choices future sprints must respect. Not a session log. Write non-obvious choices only. Skip decisions obvious from code.