| name | po |
| description | Product Owner commands -- backlog management, prioritization, grooming, review, and status. Routes to the product-owner agent. |
| argument-hint | [groom|promote <item>|review|triage|next|backlog] |
Product Owner
Route PO commands to the product-owner agent.
Usage
/po -- WIP status overview (what is in progress, what is next, grooming needs)/po next -- Recommend the highest-priority ready item to work on/po groom -- Scan active tiers, propose refinements for items missing DoR fields/po promote <item> -- Expand a tier file item into a full work item with story + AC, create feature branch and draft PR/po review -- Review completed work against acceptance criteria + DoD/po review <item> -- Review a specific item/po triage -- Phase 0: triage the backlog. Collect signals, assess priorities, write triage report, surface summary to user/po backlog -- Full backlog health report
Model Tiering
| Subcommand | Model | Rationale |
|---|
/po (status) | Sonnet | Data lookup, structured reporting |
/po next | Sonnet | Data lookup with simple priority logic |
/po groom | Opus | Judgment: writing AC, WSJF scoring, NFR drafting |
/po promote | Sonnet | Template expansion, structured output |
/po review | Opus | Judgment: AC verification, accept/reject |
/po triage | Opus | Judgment: signal assessment, prioritization, triage report |
/po backlog | Sonnet | Data aggregation, structured reporting |
Steps
- Parse the subcommand from the arguments. If no argument, default to status overview.
- Dispatch the product-owner agent with the model from the tiering table above.
- Build the agent prompt based on the subcommand.
- Review the agent's output and present the summary to the user.
- If the agent proposes changes, summarize what will be modified and confirm before applying.
Review and Acceptance Workflow
When the subcommand is review, the PO verifies work against acceptance criteria on the deployed environment:
- Verify each AC. Check every acceptance criterion against the deployed result. Document pass/fail for each.
- If all pass: Log
ops/metrics-log.sh item-accepted <item-id>. Item moves to Done. Proceed to Retro (Phase 8).
- If any fail: Log
ops/metrics-log.sh item-rejected-at-acceptance <item-id> --reason "<description>". Item returns to Fix (Phase 5), then back through Build → Review → Deploy → Accept. The original author agent fixes the issue on the existing branch. See .claude/COLLABORATION.md § Acceptance Failure for the full process.
Promote Branching Workflow
When the subcommand is promote, after the PO agent expands the item into a full work item:
- Create feature branch. Run:
git checkout -b <type>/<item-id>-<slug> where type is feat, fix, chore, or docs based on the item category. Push: git push -u origin <branch-name>.
- Create draft PR. Use GitHub MCP
create_pull_request with draft: true. PR body includes the work item's story, acceptance criteria, and NFR flags. PR title format: <type>: <description> (#<item-id>).
- Log events. Run:
ops/metrics-log.sh branch-created <item-id> --branch <branch-name> and ops/metrics-log.sh pr-opened <item-id> --pr <pr-number>.
- Report. Present the branch name and PR URL to the user.
Triage Workflow
When the subcommand is triage, the PO runs Phase 0:
- Determine last triage. Find the most recent
docs/plans/triage-YYYY-MM-DD.md file. If none exists, this is the first triage.
- Collect signals. Check event log for: items accepted since last triage,
item-rejected-at-build events, task-blocked events without corresponding task-unblocked, compliance violations. Check .claude/findings/register.md for findings with severity > normal. Check tier files for items unchanged since last triage.
- Assess priorities. Using collected signals, evaluate: what's newly urgent, what's stale, what's missing, what should be dropped, what needs reordering.
- Update tier files. Add, reorder, move, or drop items as needed.
- Write triage report. Save to
docs/plans/triage-YYYY-MM-DD.md using the template from the spec.
- Surface summary. Present 2-5 sentence summary covering: what's done, what changed, what's next (with rationale), what needs user input.
- Guided input. If items need user decisions, offer to walk through each one. Record decisions in the triage report.
- Log event. Run:
ops/metrics-log.sh backlog-triaged --items-reviewed <N> --items-added <N> --items-dropped <N> --items-reordered <N>
- Record findings. If process issues were discovered during triage, log them via
/findings.
