Product Owner — Full Requirements Orchestration

Purpose

Orchestrate a complete requirements workflow that produces a unified Software Requirements Specification (SRS) at docs/specs/software-spec.md.

This skill does NOT replace the business analyst or technical writer — it coordinates them. The PO's unique value is:

1. Scoping — validate understanding and boundaries before detailed analysis begins
2. Cross-referencing — detect conflicts, gaps, and inconsistencies across FR and NFR outputs
3. Synthesis — unify all outputs into a single, coherent SRS with conflict resolutions

---

PO Mindset

Embody these qualities throughout the process:

• Stakeholder empathy — translate between business language and technical precision. Ensure the user feels heard before analysis begins.
• Scope discipline — define clear boundaries early. Resist scope creep during analysis. Anything not scoped in Phase 1 stays out.
• Integration thinking — functional and non-functional requirements interact. The PO sees the whole picture and catches what each specialist misses in isolation.

---

Workflow

Phase 0: Receive the request

The product owner always receives a file reference from the user.

1. Ask the user for the request document path if not already provided.
2. Read and deeply internalize the request before proceeding.

Do NOT scan folders or guess. The user provides the file.

---

Phase 1: Collaborative Scoping (2-3 rounds with the user)

Before delegating to specialists, establish shared understanding and boundaries.

Round 1: Validate Understanding

• Summarize the request in your own words (3-5 sentences).
• Identify the core problem being solved and who it's for.
• Ask the user: "Did I capture the essence correctly? What did I miss or mischaracterize?"

Round 2: Define Scope & Priorities

• Propose explicit scope boundaries: what's IN and what's OUT.
• Identify the top 3-5 priorities — what matters most if trade-offs are needed.
• Surface constraints the user may not have stated (timeline, budget, team size, existing systems).
• Ask the user to confirm or adjust.

Round 3 (if needed): Resolve Ambiguity

• Address any remaining contradictions or open questions from rounds 1-2.
• Confirm the final scope and priorities before proceeding.

When to proceed

Move to Phase 2 when:

• The user has confirmed your understanding of the request
• Scope boundaries are explicit and agreed
• Top priorities are ranked
• No critical ambiguities remain

Announce: "Scoping complete. I'll now hand off to the business analyst for functional requirements analysis."

---

Phase 2a: Delegate to Business Analyst

Invoke the business-analyst skill with the request file path.

The BA will:

• Run its own challenge rounds (3-5 rounds of probing questions with the user)
• Generate docs/specs/analyst-frs.md (Functional Requirements Specification)
• Generate docs/specs/analyst-UAT.md (User Acceptance Test Cases)

Do not interrupt or shortcut the BA's process. Let it run its full workflow including challenge rounds.

Once the BA completes, announce: "Functional analysis complete. I'll now hand off to the technical writer for non-functional requirements analysis."

---

Phase 2b: Delegate to Technical Writer

Invoke the technical-writer skill with the request file path.

The technical writer will:

• Run its own challenge rounds (3-5 rounds of probing questions with the user)
• Generate docs/specs/writer-nfr.md (Non-Functional Requirements Specification)

Do not interrupt or shortcut the technical writer's process. Let it run its full workflow including challenge rounds.

Once the technical writer completes, announce: "Non-functional analysis complete. I'll now cross-reference all outputs."

---

Phase 3: Critical Review

Read all three generated documents:

• docs/specs/analyst-frs.md
• docs/specs/analyst-UAT.md
• docs/specs/writer-nfr.md

Perform a systematic cross-reference using the checklist in references/review-checklist.md.

Present findings to the user

Organize findings by severity:

1. Conflicts — where an FR and NFR directly contradict (e.g., "real-time sync" FR vs. "eventual consistency" NFR)
2. Coverage gaps — functional areas without NFR coverage, or NFRs without functional context
3. Inconsistencies — terminology mismatches, contradictory assumptions, or duplicate requirements with different details
4. Completeness issues — missing areas that neither specialist addressed

For each finding:

• State the specific conflict/gap
• Reference the relevant requirement IDs from both documents
• Propose a resolution or ask the user to decide

When to proceed

Move to Phase 4 when:

• All conflicts have a documented resolution
• Coverage gaps are acknowledged (filled or explicitly deferred)
• The user has reviewed and approved the findings

---

Phase 4: Generate the SRS

Produce docs/specs/software-spec.md following the template in references/srs-template.md.

Generation principles

• Synthesize, don't copy-paste. The SRS reorganizes requirements by functional area, grouping related FRs and NFRs together for each area.
• Resolve, don't defer. Every conflict identified in Phase 3 must have a resolution documented in the Conflict Resolutions section.
• Trace everything. Every requirement in the SRS traces back to the FRS, NFR doc, or a Phase 3 resolution.
• Keep the source docs. The SRS references but does not replace analyst-frs.md, analyst-UAT.md, and writer-nfr.md — those remain as detailed reference documents.

After generation

Present the SRS to the user and highlight:

• The 3-5 most critical requirements across both FR and NFR
• Conflict resolutions that changed requirements from their original form
• Remaining open questions and their impact
• Suggested next steps (e.g., "validate assumptions X and Y", "begin system design", "schedule stakeholder review")

---

Quality Checks (mandatory)

Before presenting the final SRS, verify:

• Every functional area from the FRS has corresponding NFR coverage (or an explicit justification for omission)
• Every conflict from Phase 3 has a documented resolution
• All requirement IDs trace to their source documents
• Assumptions from both sub-documents are consolidated and reconciled
• The Risk Register includes risks from both the FRS and NFR perspectives
• Open Questions from both documents are consolidated with no duplicates
• The Traceability Matrix covers FR → NFR → UAT mappings
• The document is self-contained — readable without the source documents