Menu
Sprint Review ceremony — present Increment to user
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Whole-repo, multi-agent audit that IS the Sprint-end cross-review ceremony (product-wide integrity): 4 axes — spec-conformance, logic/defect hunt, redundancy, and product-security — over the ACCUMULATED codebase at HEAD, not the Sprint diff. Findings are swept to zero per defect class — one class = one PBI covering every occurrence, documentation drift batched into a single DOCS PBI — and non-blocking: Critical/High become draft PBIs for the NEXT Sprint, Medium/Low at PO discretion. At Integration-Sprint entry a thin re-check confirms the latest audit is fresh and no open Critical/High audit PBIs remain before testing proceeds.
Sprint-end product-wide integrity gate. The five per-aspect reviews (requirement conformance, functional quality, security, maintainability, docs consistency) now run PER-PBI inside the pipeline before a PBI reaches awaiting_cross_review. Sprint-end cross-review is the whole-repo codebase-audit ONLY: static analysis + 4 audit axes (spec-conformance, logic-defect, redundancy, product-security) over the accumulated codebase at HEAD. The audit is non-blocking — Critical/High findings become draft PBIs for the next Sprint; it never reverts a PBI.
Handles PBI pipeline escalation notifications from Developer. Reads escalation context, applies response matrix (retry / split / hold / human), and routes to user when human intervention is needed.
SM-side merge orchestration for a single PBI. Triggered when the Developer notifies `[<pbi-id>] PBI_READY_TO_MERGE`. Drives `.scrum/scripts/merge-pbi.sh` and handles the failure / retry cycle through SendMessage to the assigned Developer.
PBI development pipeline — orchestrates design, impl+UT, PBI review, and UT-run stages with sub-agent fan-out, file-based handoff, and deterministic termination gates (Anthropic + Ralph + GAN-derived). Used by Developer per assigned PBI. Replaces former design + implementation skills.
PO acceptance verification — launches and operates the app to verify acceptance criteria by command execution. Used in Sprint Review (demo mode) and Integration Sprint (UAT mode) when .scrum/config.json po_mode is "agent".
| name | sprint-review |
| description | Sprint Review ceremony — present Increment to user |
| disable-model-invocation | false |
When .scrum/config.json.po_mode == "agent", every PO-approval prompt
in the Steps below re-targets to the product-owner teammate per
../../rules/scrum-context.md § PO seat resolution; the ceremony shape is
unchanged, and Steps not overridden in this table run verbatim.
| Step | Override (po_mode=agent) |
|---|---|
| 3. Launch app | The PO (not SM) launches the app as part of po-acceptance. SM still emits the access URL/port observation to the main session for the watching human, but does not wait on a human reply. App-launch failure is fail, not skip (the po-acceptance skill enforces this in step 1.4). |
| 4. Demo EVERY completed PBI | SM sends [sprint-<N>] PO_DECISION_REQUEST kind=demo_acceptance options=[pass,fail,waive] recommendation=pass with the completed-PBI list; the PO teammate then runs the po-acceptance skill (mode=demo) on its own (the skill lives in the PO's skills: allowlist, not the SM's). The PO launches and operates the app, verifies each AC by runnable command, and returns one kind=demo_acceptance decision per PBI. fail routes to step 9. |
| 5. Doc-implementation consistency | Unchanged — engineering quality, owned by SM/Developer (the PO cannot lower this gate). |
| 8. Get user feedback | Replaced by a single structured pass — see step 9 override. No human-input wait. |
| 9. Defect/change handling | The "repeat until user says that's all" loop collapses to one structured PO pass: the PO returns a single message listing (a) gaps against docs/product/vision.md and (b) defects observed during the demo, terminated by FEEDBACK_COMPLETE. Each defect is recorded as kind=defect_triage with priority; each becomes a draft PBI exactly as in human mode. |
| 11. Leftover Summary | Include any assumption=true PO decisions (from .scrum/po/decisions.json written this Sprint) as a fourth group: Assumed decisions to re-examine: <dec-id> <kind> <rationale>. These are surfaced for next-Sprint Refinement. |
state.json → phase: "sprint_review", sprint.json → status: "sprint_review":
.scrum/scripts/update-state-phase.sh sprint_review
.scrum/scripts/update-sprint-status.sh sprint_review
Present change summary: Sprint Goal, completed PBIs (status: done), incomplete PBIs (carry-over candidates)
Launch app (mandatory): Detect start command (package.json/Makefile/docker-compose etc)→start→confirm running→fail→fix+retry (never skip demo)→tell user access URL/port
po-acceptance skill (mode=demo) launches it. SM still announces access URL/port observed in _app.log for the watching human (observation only, no wait). Launch failure is fail, not skip.Demo EVERY completed PBI (mandatory):
a. State PBI name
b. Show it working by executing the PBI's demo_plan (backlog.json)
— the local demo path decided at refinement, including its
stubs/local substitutes. Legacy PBIs refined before demo_plan
existed: derive the demo from the ACs (navigate/call API/run
command) and record the gap per step 9
c. Point out what to verify (be specific: "login form with email + password fields")
d. Ask user to confirm→wait→next PBI. Skip only if user explicitly says no need
[sprint-<N>] PO_DECISION_REQUEST kind=demo_acceptance options=[pass,fail,waive] recommendation=pass pbis=[<list>] — include each PBI's demo_plan in the payload; the PO teammate runs po-acceptance (mode=demo) on its own — the skill is on the PO's allowlist, not the SM's. PO operates the app itself following each demo_plan, verifies each AC by runnable command, and returns one kind=demo_acceptance decision per PBI plus the aggregated PO_ACCEPTANCE_REPORT. fail → step 9 defect route.Doc-implementation consistency: For every completed PBI→compare docs vs code→mismatch→add-backlog-item.sh (status: draft). Track each new pbi-id for the Leftover Summary.
Report remaining backlog scope + Product Goal progress
Append the SprintSummary to sprint-history.json via the wrapper
(direct edits are blocked by the scrum-state guard). --id and
--goal are required; the rest are optional (--completed-at
defaults to now). The call is idempotent on --id, so a retried
Sprint Review does not duplicate the entry:
.scrum/scripts/append-sprint-history.sh \
--id "<sprint-id>" \
--goal "<sprint goal>" \
--type development \
--pbis-completed <N_done> \
--pbis-total <N_total> \
--started-at "<sprint.json started_at>" \
--completed-at "<ISO 8601 now>"
Get user feedback
Defect/change handling:
a. NEVER fix during Sprint Review (not even quick fixes — inspection ceremony only)
b. Each defect/change/feedback item → add-backlog-item.sh (status: draft). Track each new pbi-id.
b2. A demo gap is a defect. A PBI whose demo_plan cannot be
executed locally — or that has none and cannot be demonstrated —
is recorded as a draft PBI (Demo gap: <pbi-id> — <what blocks a local demo>). "Read the code instead" and "needs cloud deploy to
see it" are never acceptable demo outcomes.
c. "Will be prioritized in next Sprint via Backlog Refinement→Sprint Planning"
d. After user confirms "that's all"→proceed
[sprint-<N>] PO_DECISION_REQUEST kind=defect_triage options=[high,medium,low,reject] recommendation=<...> once; the PO returns a single message listing (a) gaps against docs/product/vision.md and (b) demo-observed defects, terminated by FEEDBACK_COMPLETE. Each listed defect produces a separate kind=defect_triage decision + a draft PBI via add-backlog-item.sh. No further round-trips.Carry-over PBIs (mandatory): For every PBI in this sprint where status is neither "done" nor "cancelled" (any in_progress_* / awaiting_cross_review / cross_review / escalated / blocked / refined-but-not-started — cancelled PBIs have no remaining work and are never carried over):
a. Create a new draft PBI capturing the remaining work via add-backlog-item.sh — embed origin in description (Carry-over from <pbi-id>: <what is left>).
b. Original PBI keeps its current status (immutable historical record of this Sprint).
c. Track each new pbi-id for the Leftover Summary.
.scrum/scripts/add-backlog-item.sh \
--title "Carry-over: <orig title>" \
--description "Continuation of <pbi-id>. Remaining: <concise scope>." \
--ac "<criterion 1>" --ac "<criterion 2>"
Leftover Summary (mandatory report): Print to user a single consolidated list of every draft PBI created during this Sprint Review, grouped:
<new-pbi-id> ← <orig-pbi-id>: <title><new-pbi-id>: <title><new-pbi-id>: <title>State explicitly: "These N items enter the backlog as drafts and will be re-prioritized in the next Sprint's Backlog Refinement → Sprint Planning. Nothing is dropped."
Assumed PO decisions to re-examine: listing every entry from .scrum/po/decisions.json written this Sprint with assumption=true — <dec-id> <kind> <rationale>. These are not new PBIs; they are PO-side risk items surfaced for next-Sprint Refinement.Commit Sprint deliverables: git status→stage relevant files (exclude temp/artifacts/.DS_Store)→commit:
feat(sprint-N): <Sprint Goal>
Completed PBIs:
- PBI-XXX: <title>
Co-Authored-By: <contributing developers>
Report commit hash. Do NOT push.
Ref: FR-010, FR-011