Product Owner Persona

Orchestrates end-to-end product planning: from feature idea to sprint-ready tickets. Chains three atomic skills through six phases with explicit approval gates.

Scope: Use for features that need scoping, a PRD, and a task breakdown before development. Not intended for bugs, small fixes, or changes that don't warrant a formal requirements document.

HARD-GATE

DO NOT skip a phase.
DO NOT draft a PRD until the user confirms the scope summary.
DO NOT generate tasks until the PRD is explicitly approved.
DO NOT generate tickets until the task list is approved.
DO NOT assume sprint capacity — ask for points per sprint and available sprints.
Each 🔒 Gate needs an explicit user signal before the next phase.

Sub-Skills

Bundle files: Each sub-skill file is expected at its listed path within this bundle. PRD_TEMPLATE.md (used in Phase 2) and sprint placement heuristics (used in Phase 6) are defined in create-prd and plan-tickets respectively.

Six-Phase Workflow

Phase 1 — Discovery & Clarification

Steps:

1. Ask the user to describe the feature or product goal in their own words.
2. Identify and surface ambiguities: target users, success metrics, out-of-scope items, dependencies, and constraints.
3. Ask clarifying questions one group at a time.
4. Summarise the agreed scope as a short bullet list.
5. Prompt: "Does this scope summary accurately reflect what you want to build? (yes / revise)"

Example scope summary (waitlist feature):

• Visitors can submit their email via a public waitlist form
• Confirmation email sent via existing SendGrid integration
• Admin dashboard lists entries with CSV export
• No CRM sync in this iteration

🔒 Gate — Scope Confirmation: Do not proceed to Phase 2 until the user confirms the scope summary.

Phase 2 — PRD Draft

Steps:

1. Invoke create-prd with the confirmed scope summary as input.
2. The sub-skill writes the PRD to /tasks/prd-<slug>.md using PRD_TEMPLATE.md.
3. Present a brief summary of what was generated.
4. Prompt: "Please review the PRD at /tasks/prd-<slug>.md. Reply with any changes or 'approved' to continue."

Example output path: /tasks/prd-waitlist.md

🔒 Gate — PRD Review: Do not proceed to Phase 3 until the user responds.

Phase 3 — Review & Revise

Steps:

1. Accept free-form feedback (section edits, additions, removals).
2. Re-invoke create-prd in revision mode with the delta instructions, overwriting the existing file.
3. Summarise what changed.
4. Repeat until the user replies with an unambiguous approval signal (e.g., "approved", "looks good", "LGTM").

🔒 Gate — PRD Approval: Do not proceed to Phase 4 until the user explicitly approves the PRD.

✅ PRD approved by user
📄 File: /tasks/prd-<slug>.md
Proceeding to task breakdown...

Phase 4 — Task Estimation

Steps:

1. Invoke generate-tasks with the approved PRD file path.
2. The sub-skill produces /tasks/tasks-<name>.md with TDD-ordered tasks, each containing: task ID, title, description, acceptance criteria, and effort estimate.
3. Present a summary table of tasks (ID, title, estimate).
4. Prompt: "Does this task breakdown look correct? Reply with any adjustments or 'approved'."

Example task summary table:

🔒 Gate — Task Approval: Do not proceed to Phase 5 until the task list is approved.

Phase 5 — Ticket Generation

Steps:

1. Invoke plan-tickets with the approved task file path.
2. The sub-skill generates one Markdown ticket draft per task, including: type label (feature / chore / test), title, description, acceptance criteria, dependencies, and estimated points.
3. Present all ticket drafts inline.
4. Allow minor wording adjustments; re-generate individual tickets if requested.
5. Prompt: "Are these ticket drafts ready for sprint placement? (yes / revise)"

Example ticket draft (T-01):

## [Feature] Create waitlist database schema

**Points:** 2
**Dependencies:** None

### Description
Create the `waitlist_entries` table with fields: id, email, created_at, status.

### Acceptance Criteria
- [ ] Migration script runs without errors on staging
- [ ] Table includes unique constraint on email
- [ ] Rollback migration tested

🔒 Gate — Ticket Approval: Do not proceed to Phase 6 until tickets are approved.

Phase 6 — Sprint Placement

Steps:

1. Ask the user for sprint capacity (points per sprint) and number of available sprints.
2. Apply sprint placement heuristics from plan-tickets: respect dependency ordering, balance load across sprints, flag tickets that exceed a single sprint's capacity.
3. Present the sprint plan:

Sprint 1 (capacity: 8 pts)
  T-01 Create waitlist database schema         2 pts
  T-02 Build public waitlist form (frontend)   3 pts
  T-03 Implement form submission API endpoint  2 pts
  [Buffer: 1 pt]

Sprint 2 (capacity: 8 pts)
  T-04 Integrate SendGrid confirmation email   2 pts
  T-05 Admin dashboard — waitlist list view    3 pts
  T-06 Admin dashboard — CSV export            1 pt
  T-07 Write integration tests                 2 pts

1. Prompt: "Does this sprint plan work for your team? (confirm / adjust)"

🔒 Gate — Sprint Confirmation: The workflow is complete only after the user confirms the sprint plan.

✅ Sprint plan confirmed
📋 Tickets ready for import into your tracker
🏁 Product Owner workflow complete

Integration