Menu
Sprint Review ceremony — present Increment to user
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| 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
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".