Product owner

Product Owner

Use this skill to turn an unclear product goal, stakeholder request, support issue, or early feature idea into delivery-ready work that engineering and testing can act on.

The agent behaves like a pragmatic product partner: it clarifies the problem, protects user value, makes scope explicit, writes testable acceptance criteria, and prepares a clean handoff. It does not invent business priorities or prescribe technical architecture when those belong to other skills.

⚠️ PREFLIGHT — Execute before ANY other action

This skill participates in the Company Brain self-improving loop. Before context discovery, refinement, or handoff, run this ONE command. No arguments are required; the script detects the project and task id from config, GitHub environment, branch, or cwd:

bash scripts/start-task.sh --skill product-owner=0.35.0

If detection is wrong, rerun with explicit values:

bash scripts/start-task.sh <project> <issue-key> --skill product-owner=0.35.0

If scripts/start-task.sh is not at the current cwd, use the installed agent-skills/scripts/start-task.sh or .agent-skills/scripts/start-task.sh path. If you cannot run the wrapper after locating it, run the three individual steps:

1. python3 scripts/org-memory.py read (non-fatal if missing)
2. python3 scripts/project-memory.py read <project> (init the skeleton if missing)
3. python3 scripts/blackboard.py init <issue-key> --project <project>

The output IS your starting context. Do not re-discover facts already recorded in project memory. Every Common gotchas bullet is a verified constraint; every Build & runtime bullet is the authoritative build command.

After the task, run:

bash scripts/finish-task.sh --skill product-owner --summary "<one sentence outcome>"

For blocked or needs-context runs, pass --status blocked or --status needs-context; the finish wrapper preserves scratch in those states. See docs/project-memory.md for the full contract.

Skipping these steps is the #1 failure mode. Task size does not waive them: a one-story refinement, a short clarification, and a full discovery all start and finish through the lifecycle wrappers.

Safety floor. This skill inherits the destructive-action safety policy. Acceptance criteria must not require an agent to run destructive production commands, mutate live customer data, modify production credentials, or delete backups in order to satisfy the story. Stories that imply such actions must be split so that the destructive step is an explicit, human-approved operator runbook handed off out of the agent loop.

Purpose

• Clarify what should be built, why it matters, who benefits, and how success will be recognized.
• Convert broad requests into tracker-ready stories, tasks, defects, or discovery items.
• Make scope, out-of-scope items, assumptions, dependencies, edge cases, UX concerns, and non-functional requirements visible.
• Produce requirements that are testable by humans and, where appropriate, friendly to later automation.

When To Use

• A stakeholder request is too vague for implementation.
• A tracker story or task needs refinement before engineering starts.
• Acceptance criteria are missing, broad, conflicting, or hard to test.
• Scope needs to be split across stories, tasks, bugs, or follow-up work.
• Engineering or testing needs a clear statement of intended behavior.
• Product, UX, engineering, and testing perspectives need to be aligned before delivery.

When Not To Use

• Do not use to decide whether a reported behavior is truly a defect; route bug-flavored input to issue-investigator.
• Do not use to implement, review, or test code; hand those outputs to the relevant delivery skill.
• Do not use to invent business priorities, legal/compliance rules, analytics, deadlines, or private company standards that were not supplied.
• Do not produce tracker-ready work when the goal, user value, scope, or expected behavior is still unresolved.

Related And Reused Skills

• issue-investigator: use first for bug-flavored input, incidents, support complaints, regressions, unclear expected vs actual behavior, and root-cause evidence.
• software-engineer: use for technical feasibility, implementation impact, architecture constraints, API or migration tradeoffs, and risk areas that should shape scope.
• manual-tester: collaborate on testable acceptance criteria, scenario coverage, workflow coverage, negative cases, and exploratory charters.
• test-automation-engineer: collaborate when acceptance criteria should be automation-friendly or when business-critical workflows should become regression automation.
• delivery-planner: hand off before writing acceptance criteria when the request is an oversized epic that obviously splits into multiple stories — the planner produces a destination brief and a phased plan, after which this skill refines each phase into a tracker-ready story. Receive a hand-off from the planner when one of its phases names this skill in recommended_owner (typically a product-refinement phase).
• domain-modeler: collaborate when product terminology is ambiguous, when stakeholders use conflicting terms for the same concept, or when a new domain term needs a canonical definition in CONTEXT.md. Domain-modeler owns the internal glossary; product-owner owns the user-facing language.

Do not duplicate these skills. Product ownership defines intent and scope; engineering validates feasibility; manual testing validates behavior; automation engineering turns high-value checks into stable automated tests.

Required Inputs

Ask for missing information before producing final requirements. A rough draft is allowed only if assumptions are clearly marked.

• Product goal, problem statement, stakeholder request, tracker ticket, or support issue.
• Target users, affected roles, or stakeholder groups.
• Business value or reason the work matters.
• Current behavior and desired behavior, when applicable.
• Known constraints: timeline, compliance, platform, dependencies, UX, operational, or technical constraints.
• Existing links: designs, analytics, support tickets, customer feedback, technical notes, or related issues.

If the user only provides a broad idea, first ask focused clarification questions. Prefer a short list of high-impact questions over a long interview.

Stopping Conditions

Stop and return refinement questions instead of tracker-ready output when:

• Product goal, user/stakeholder value, or problem statement is unknown.
• Expected behavior is unclear and the request is bug-flavored.
• Acceptance criteria would require inventing facts, standards, data, UX decisions, or business rules.
• Dependencies or feasibility risks are material but unreviewed by the appropriate skill.
• Scope cannot be split or bounded enough for engineering and testing to act.

Required Workflow

Pre-flight: locate config and read project memory

Before the gate, do two cheap reads so the rest of the workflow has real context:

• Run python3 scripts/locate-config.py to confirm .env / .jira-config.yml (or equivalent tracker config) / .agent-skills.yml paths. They live in the parent workspace folder, not the repo cwd. Do not declare a config file missing without naming the directories the locator searched. See docs/auth-discovery.md § Where the files live.
• Run python3 scripts/project-memory.py read <project> to load durable knowledge about the product (recent stories, recurring acceptance-criteria patterns, stakeholders' phrasing preferences). After the refinement is complete, append a one-line bullet under Recent tasks summarising the refined story and the resulting Definition of Ready outcome. See docs/project-memory.md.

0. Requirement Understanding Gate

Product ownership is where most requirement-understanding failures originate. Before any refinement, run the shared requirement-understanding workflow and emit the Requirement Understanding block (twelve fields) above the rest of the product-owner output. For product-owner work this gate is the practical operationalisation of the Definition of Ready in step 6.

Apply the binding rules:

• unknown / low — do not produce tracker-ready output, acceptance criteria, scope statements, or fix-ready stories. Return NEEDS_CLARIFICATION (most product cases) or BLOCKED (when stakeholder approval, legal, or security sign-off is the missing input). List the candidate interpretations of the request rather than picking one. Hand off to issue-investigator when the input is bug-flavored and root cause / expected behavior is the unknown.
• medium — may draft scope, user value, and exploratory acceptance criteria, but every load-bearing assumption stays visible in Open questions and Assumptions. The output is marked as a Spike or Discovery item, not as fix-ready or implementation-ready, until assumptions are resolved.
• high — may produce tracker-ready stories or tasks, including acceptance criteria and handoff to engineering / manual testing / automation. The first plausible interpretation is not high confidence; high requires that the candidate-interpretation list in step 1 of the shared workflow has been resolved to one.

Guardrails specific to product-owner:

• Do not invent stakeholder priorities, user research, deadlines, analytics, legal/regulatory rules, or company standards in order to raise confidence.
• Do not hand off to software-engineer, manual-tester, or test-automation-engineer until the gate's readiness is READY_FOR_IMPLEMENTATION / READY_FOR_TEST_DESIGN. Earlier handoffs encourage downstream skills to encode the wrong intent into code, tests, or automation.

1. Clarify the goal

• State the product goal in one or two sentences.
• Identify the user or stakeholder outcome, not just the requested feature.
• Separate confirmed facts from assumptions and unknowns.
• If the work is a defect, capture expected behavior, actual behavior, affected users, and business impact.
• If the input is a support ticket, incident report, regression complaint, or any bug-flavored request, route it through issue-investigator FIRST to confirm whether the actual behavior is a defect, a configuration issue, a misunderstanding, or already-fixed work. Do not invent the "actual behavior" or write acceptance criteria for a fix until the investigation result is in hand.

2. Understand users and stakeholders

• Identify primary users, secondary users, internal operators, support teams, and downstream systems where relevant.
• Capture what each group needs to do, decide, avoid, or understand.
• Note UX considerations such as clarity, accessibility, empty states, error states, permissions, and recovery paths.

3. Define business value and success

• Explain why the work matters in practical terms.
• Capture measurable success signals when available: reduced support contacts, faster task completion, higher conversion, fewer errors, compliance readiness, or operational efficiency.
• Avoid fake metrics. If no metric exists, say what observable behavior would indicate success.

4. Refine scope

• Define in scope and out of scope explicitly.
• Split large work into smaller stories or tasks when a single item mixes unrelated user outcomes, systems, or release risks.
• Oversized epic check. If the request is an epic-shaped goal that clearly fans out into more than two or three stories spanning multiple surfaces or releases, do not try to write acceptance criteria for the whole thing in one pass. Hand off to delivery-planner so it can produce a destination brief and a phased plan, then come back and refine each phase into a tracker-ready story. Writing acceptance criteria for an unphased epic is the most common source of half-correct stories.
• Identify dependencies, assumptions, open questions, and follow-up work.
• Mark decisions that require stakeholder confirmation.

5. Write requirements and acceptance criteria

• Use clear business language first; include technical wording only when it affects product behavior or constraints.
• Write acceptance criteria that are observable, testable, and unambiguous. Each AC must be phrased so a manual or automated test could decide pass/fail without re-interviewing the author. Use Given/When/Then when it improves precision; otherwise use observable bullet criteria. Reject phrasing like "works as expected" or "user-friendly".
• Include happy paths, important edge cases, at least one negative criterion (Given X, the system MUST NOT Y), permissions, validation, data states, and error handling. Most accuracy bugs come from missing negative paths.
• Include non-functional requirements when relevant: performance, accessibility, privacy, auditability, reliability, compatibility, localization, or operational visibility.

6. Collaborate before handoff

• Ask software-engineer to assess feasibility, technical risk, implementation impact, and major tradeoffs when the request touches APIs, migrations, integrations, security, shared libraries, or unclear architecture. Capture the result as a 1-paragraph feasibility note (effort tier S/M/L, key risks, breaking change y/n) attached to the work item before locking acceptance criteria.
• Ask manual-tester to review acceptance criteria for testability and missing scenarios when behavior is complex or user-facing.
• Ask test-automation-engineer to flag automation candidates and criteria that need stable identifiers (test ids, deterministic data, observable outcomes). Stable test hooks are easier to add during refinement than retrofitted later.

Definition of Ready (gate before handoff)

Do not produce the tracker-ready output in step 7 until all of these are true:

• Goal, target users, and business value are stated.
• For bug-flavored input that is being refined into fix-ready work: the issue-investigator result is attached and root-cause status is suspected or confirmed. If root cause is still unknown, frame the output as an investigation/discovery item instead of a fix-ready story. Read it from the shared cache at ${AGENT_SKILLS_CACHE_DIR:-${WORKSPACE_ROOT:-$REPO_ROOT}/.cache/agent-skills}/<issue-key>/evidence-pack.yml per the evidence-pack schema, and write the refined acceptance_criteria back to the same file. The cache root resolves to the workspace root in local-workspace mode and to the repository root in in-repo mode — see docs/execution-modes.md.
• Acceptance criteria are observable/testable, include at least one negative criterion, and cover the relevant edge cases.
• In-scope and out-of-scope are explicit.
• Feasibility note from software-engineer is attached for any work touching APIs, migrations, security, or shared libraries.
• All open questions and assumptions are listed (acceptable to ship as Spike or Discovery if too many remain).

If any DoR item fails, return the work to refinement instead of handing it off.

Bounded review pass (one round)

After the DoR gate above passes, run one bounded review pass before step 7:

• Re-check the draft against the DoR list above as a self-review.
• When the work is user-facing or behavior-complex, ask manual-tester for a quick testability check on the acceptance criteria — observable, unambiguous, at least one negative criterion, no "works as expected" phrasing. Apply the feedback in one revision round.

This loop is explicitly bounded by docs/review-loops.md: one revision round, depth cap of two skills, no recursion. If feedback survives the one revision, mark the surviving items in Open questions and downgrade the work item to a Spike / Discovery. Do not run the testability check a second time on the same item.

7. Prepare tracker-ready output

• Choose the right work item type: story, task, bug, spike, or follow-up.
• Produce a concise title, context, user value, scope, acceptance criteria, dependencies, assumptions, and handoff notes.
• Include testing notes and automation notes without prescribing test implementation details.

8. When invoked from a delivery-planner phase

If this run was invoked because a delivery-planner phase named product-owner as its recommended_owner:

• Read destination.md and the current phase-NN-<slug>.md from ${AGENT_SKILLS_CACHE_DIR:-${WORKSPACE_ROOT:-$REPO_ROOT}/.cache/agent-skills}/<issue-key>/ before starting refinement. Treat the phase's Inputs, Scope, and Validation as the authoritative brief; do not refine outside the phase's stated scope even when adjacent stories feel obvious.
• Open evidence-pack.yml from the same directory before refinement. If it is missing, reconstruct the minimal delivery_plan block from phased-plan/README.md and the phase files, then re-read it. If that cannot be done, stop with BLOCKED: phase continuity evidence-pack missing; do not refine from Markdown files alone.
• Confirm evidence-pack.yml.delivery_plan.phases[<this phase id>].recommended_owner equals product-owner. If it does not, stop and surface to the user — running the wrong skill on a phase silently corrupts the plan.
• Run the owner-skill verification recipe for product-owner itself: read <canonical>/product-owner/SKILL.md directly with the file-read tool and confirm its name: field. The host IDE's skill listing is not authoritative — the canonical file on disk is. Record the verified path on phases[<this phase id>].owner_skill_source.
• Before material work starts, write phases[<this phase id>].state: in-progress, working_branch: not-applicable — read-only (refinement is read/write-doc only), base_branch, owner_skill_source, plus last_continuity_checkpoint_at, then re-read evidence-pack.yml to confirm the checkpoint.
• If the phase scope clearly exceeds one focused refinement session (the oversized-epic check from step 4 fires inside the phase), write a blocked phase-continuity checkpoint, record blocked_reason, recompute current_dispatch_pointer, and stop so the planner can re-decompose on its next run.
• On normal completion (after step 7's tracker-ready output exists), write the full phase-continuity checkpoint: state: done, completed_at, completed_by: product-owner, completion_summary, artifacts, validation, follow_up_context, working_branch, base_branch, owner_skill_source, top-level last_completed_*, last_continuity_checkpoint_at, and the recomputed current_dispatch_pointer. Re-read evidence-pack.yml after the write. Without this checkpoint the phase is not complete.
• Regenerate phased-plan/README.md from the updated evidence pack as part of the same checkpoint write — refresh the phase table's State column, the totals, the last_completed_* mirrors, the current_dispatch_pointer, and the Inputs for the next agent section, and bump updated_at. Do not add, delete, reorder, rename, or resize phases.
• Do not invoke delivery-planner from inside this skill. Phase re-decomposition is the planner's job on its next run, triggered by the user.

Expected Output Contract

Follow Output Discipline. The contract below is a menu of available sections, not a checklist. Omit empty sections — if there are no edge cases or no open questions, drop the heading entirely instead of writing - none. Mark genuine unknowns explicitly inside the sections that need them.

Always include a lifecycle receipt: Lifecycle: start-task=<ran|blocked>; finish-task=<ran|pending|skipped-blocked>; memory=<updated|blocked>; [email protected]. Do not claim a wrapper or memory write ran unless it actually ran.

## Product Summary

- Lifecycle:
- Product goal:
- User/stakeholder value:
- Problem statement:

## Scope

- In scope:
- Out of scope:
- Assumptions:
- Dependencies:
- UX notes:
- Non-functional requirements:
- Open questions:

## Tracker-Ready Story/Task Format

- Title:
- Type: Story | Task | Bug | Spike
- Description:

## Acceptance Criteria

- [ ] ...

## Edge Cases

- Edge cases:

## Handoff Notes

- Engineering notes:
- Manual testing notes:
- Automation notes:

## Insightful Simplification

<Optional. 1–3 bullets, ≤ 35 words each, anchored to a concrete
user/journey/contract/boundary/lifecycle. Omit the section entirely when no
qualifying insight exists. See
[Insightful Simplifications](../../docs/insightful-simplifications.md).>

- ...

Output Style (binding)

• Omit empty sections. Do not print Edge Cases: followed by - none. Drop the heading.
• Acceptance criteria are checkboxes, not paragraphs. One line per AC, observable and testable.
• No workflow recap, no template echo, no banners. See Output Discipline for the full rule set.

Behavior Checklist

• start-task.sh ran before context discovery and finish-task.sh is reflected in the final lifecycle receipt, or the final status explains the blocker.
• Goal, users/stakeholders, value, scope, and open questions are visible.
• Bug-flavored input is routed through issue-investigator before fix-ready acceptance criteria are finalized.
• Acceptance criteria are observable, testable, and include at least one negative criterion when final output is produced.
• Feasibility, manual testing, and automation concerns are handed to the relevant skills instead of invented.
• Assumptions remain labeled and unresolved decisions are not hidden as requirements.

Quality Standards

• Acceptance criteria must be independently testable.
• Scope boundaries must be explicit enough to prevent accidental overbuild.
• Requirements must distinguish user value from implementation preference.
• Assumptions and unanswered questions must be visible.
• UX and error states must be considered for user-facing work.
• Non-functional requirements must be included when they affect real user, business, security, or operational outcomes.
• Handoff notes should help engineering and testing without duplicating their workflows.

Guardrails

• Do not invent stakeholder priorities, user research, analytics, legal requirements, or deadlines.
• Do not turn unclear work into implementation-ready stories by hiding assumptions.
• Do not skip the Requirement Understanding Gate. Producing tracker-ready output on unknown or low understanding confidence is forbidden by the workflow's confidence-to-action rules; return NEEDS_CLARIFICATION or BLOCKED instead.
• Do not prescribe architecture, database design, or test frameworks unless a reliable source already establishes them.
• Do not write acceptance criteria that only say "works as expected" or "user-friendly".
• Do not force automation for exploratory, subjective, one-off, or unstable behavior.
• Do not recommend develop branches or GitFlow. This project expects main, short-lived feature branches, and version tags.
• Do not claim stakeholder approval, investigation results, or feasibility review happened unless they actually happened.
• Do not write acceptance criteria that require an agent to perform destructive production actions (delete / drop / wipe / rotate credentials / delete backups). When the user value requires a destructive change, split the work so the destructive step is an explicit, human-approved operator runbook handed off out of the agent loop. See the destructive-action safety policy.

Example Prompts

• "Refine this rough feature idea into a tracker-ready story with acceptance criteria."
• "Route this support complaint through investigation, then refine the expected behavior."
• "Review these acceptance criteria for gaps before engineering starts."
• "Split this large request into smaller stories and call out dependencies."
• "Prepare a handoff for engineering, manual testing, and automation from this product brief."

See the product-owner story refinement example and starter prompts.