# Product Owner > >- - **Type:** Skill - **Install:** `agentstack add skill-wamalalawrence-agent-skills-product-owner` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [wamalalawrence](https://agentstack.voostack.com/s/wamalalawrence) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [wamalalawrence](https://github.com/wamalalawrence) - **Source:** https://github.com/wamalalawrence/agent-skills/tree/main/skills/product-owner ## Install ```sh agentstack add skill-wamalalawrence-agent-skills-product-owner ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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](../../docs/company-brain.md) 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 bash scripts/start-task.sh --skill product-owner=0.35.0 ``` If detection is wrong, rerun with explicit values: ```bash bash scripts/start-task.sh --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 ` (init the skeleton if missing) 3. `python3 scripts/blackboard.py init --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 bash scripts/finish-task.sh --skill product-owner --summary "" ``` 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`](../../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](../../docs/destructive-action-safety.md). 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`](../software-engineer/skills/issue-investigator/SKILL.md). - 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`](../software-engineer/skills/issue-investigator/SKILL.md): use first for bug-flavored input, incidents, support complaints, regressions, unclear expected vs actual behavior, and root-cause evidence. - [`software-engineer`](../software-engineer/SKILL.md): use for technical feasibility, implementation impact, architecture constraints, API or migration tradeoffs, and risk areas that should shape scope. - [`manual-tester`](../manual-tester/SKILL.md): collaborate on testable acceptance criteria, scenario coverage, workflow coverage, negative cases, and exploratory charters. - [`test-automation-engineer`](../test-automation-engineer/SKILL.md): collaborate when acceptance criteria should be automation-friendly or when business-critical workflows should become regression automation. - [`delivery-planner`](../delivery-planner/SKILL.md): 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`](../domain-modeler/SKILL.md): 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](../../docs/auth-discovery.md#where-the-files-live). - Run `python3 scripts/project-memory.py read ` 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`](../../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](../../docs/requirement-understanding.md) 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`](../software-engineer/skills/issue-investigator/SKILL.md) 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`](../software-engineer/SKILL.md), [`manual-tester`](../manual-tester/SKILL.md), or [`test-automation-engineer`](../test-automation-engineer/SKILL.md) 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`](../software-engineer/skills/issue-investigator/SKILL.md) 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`](../delivery-planner/SKILL.md) 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`](../software-engineer/SKILL.md) 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`](../manual-tester/SKILL.md) to review acceptance criteria for testability and missing scenarios when behavior is complex or user-facing. - Ask [`test-automation-engineer`](../test-automation-engineer/SKILL.md) 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`](../software-engineer/skills/issue-investigator/SKILL.md) 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}//evidence-pack.yml` per the [evidence-pack schema](../software-engineer/references/evidence-pack.md), 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](../../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`](../software-engineer/SKILL.md) is attached for any work touching APIs, migrations, security, or shar … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [wamalalawrence](https://github.com/wamalalawrence) - **Source:** [wamalalawrence/agent-skills](https://github.com/wamalalawrence/agent-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-wamalalawrence-agent-skills-product-owner - Seller: https://agentstack.voostack.com/s/wamalalawrence - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.