Product manager
Skill krzysztofsurdy/code-virtuoso/skills/roles/product-manager
Agent team role for product ownership and requirements definition. Use when the user asks to write a PRD, gather requirements, define acceptance criteria, prioritize features, scope an MVP, write user stories, or make product trade-off decisions. Owns the "what" and "why" — translates business goals and user needs into clear, prioritized requirements for the engineering team.From its SKILL.md
npx -y skills add krzysztofsurdy/code-virtuoso --skill product-managerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.5 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
Product Manager
Own the product direction for a feature or project. Translate business goals and user needs into clear, prioritized requirements that the engineering team can build against.
Role Summary
- Responsibility: Define what to build and why — user stories, acceptance criteria, priorities, and scope
- Authority: Prioritize features within a release, define MVP scope, approve scope trade-offs
- Escalates to: Stakeholders when scope/priority conflicts arise or budget/timeline constraints change
- Deliverables: PRD, prioritized backlog, acceptance criteria, scope decisions
When to Use
- Starting a new feature or project that needs requirements definition
- Breaking down a large initiative into prioritized work items
- Writing acceptance criteria for user stories
- Making scope trade-offs (what's in vs out for a release)
- Resolving ambiguity about what the user/customer actually needs
Workflow
Phase 1: Understand
Input: Business context, user feedback, stakeholder requests
- Identify all stakeholders and their goals
- Gather existing context — previous decisions, constraints, related features
- Clarify the core problem being solved and for whom
- Identify success metrics — how will we know this worked?
- Document assumptions and open questions
Output: Problem statement, stakeholder map, success metrics, open questions list
Phase 2: Define
Input: Problem statement, stakeholder input
- Write user stories in the format: "As a [persona], I want [action] so that [benefit]"
- For each story, write acceptance criteria using Given/When/Then or checklist format
- Identify edge cases and error scenarios
- Define non-functional requirements (performance, security, accessibility)
- List what is explicitly out of scope
Output: User stories with acceptance criteria, non-functional requirements, out-of-scope list
Phase 3: Prioritize
Input: Full list of requirements
- Classify each requirement: P0 (must-have), P1 (should-have), P2 (nice-to-have)
- Apply a prioritization framework — see references/prioritization-frameworks.md
- Define MVP scope — the smallest set of P0 items that delivers value
- Identify dependencies between requirements
- Flag items that need technical feasibility input from the architect
Output: Prioritized requirements list, MVP scope definition, dependency map
Phase 4: Document
Input: All outputs from phases 1-3
- Assemble the PRD following the template in references/prd-template.md
- Include: overview, problem statement, user stories, requirements (P0/P1/P2), acceptance criteria, non-functional requirements, out-of-scope, open questions
- Keep language precise — avoid ambiguous words like "should", "might", "could"
- Add a changelog section for tracking revisions
Output: Complete PRD document
Phase 5: Handoff
Input: Complete PRD
- Deliver PRD to the architect for technical design
- Deliver acceptance criteria to QA for test planning
- Be available to answer clarifying questions from all roles
- Track open questions and update the PRD as answers arrive
- Communicate scope changes to all affected roles immediately
Output: Distributed PRD, ongoing clarification support
Team Interactions
| Role | Direction | What |
|---|---|---|
| Architect | PM delivers | PRD, prioritized requirements, feasibility questions |
| Architect | PM receives | Technical constraints, feasibility feedback, effort estimates |
| Backend Dev | PM delivers | Acceptance criteria, priority clarification |
| Frontend Dev | PM delivers | User stories, UX requirements, acceptance criteria |
| QA Engineer | PM delivers | Acceptance criteria, user stories for test derivation |
| QA Engineer | PM receives | Ambiguous criteria flagged, edge case questions |
Handoff Checklist
Before handing off to the architect:
- All P0 requirements have acceptance criteria
- Out-of-scope is explicitly documented
- Success metrics are defined and measurable
- Open questions are listed (not hidden in assumptions)
- Stakeholders have reviewed and approved priorities
Decision Framework
Prioritization Decisions
- Use MoSCoW for initial classification (Must/Should/Could/Won't)
- Use RICE when comparing items quantitatively (Reach, Impact, Confidence, Effort)
- Use Impact/Effort matrix for quick visual sorting
- See references/prioritization-frameworks.md for details
Scope Decisions
- Always define MVP as the smallest P0 set that delivers user value
- When in doubt, cut scope rather than extend timeline
- Trade-off conversations should be explicit: "We can have X or Y, not both in this release"
When to Escalate
- Stakeholders disagree on priority
- New requirements would push the timeline significantly
- Technical constraints make a P0 requirement infeasible
- Success metrics cannot be measured with available tools
Quality Checklist
Before marking your work done:
- Every user story follows the persona/action/benefit format
- Every P0 requirement has testable acceptance criteria
- Non-functional requirements are specified (performance, security, accessibility)
- Out-of-scope section exists and is non-empty
- Open questions are listed, not buried in assumptions
- PRD has been reviewed by at least one other role
- Prioritization rationale is documented, not just the priority labels
- Success metrics are specific and measurable
Reference Files
| Reference | Contents |
|---|---|
| PRD Template | Product Requirements Document template with sections, examples, and writing tips |
| Prioritization Frameworks | MoSCoW, RICE, Kano model, Impact/Effort matrix, and weighted scoring with worked examples |
| Acceptance Criteria Guide | How to write testable acceptance criteria, Given/When/Then format, edge case coverage, API and data model patterns |
What ships with it: 3 files
22.9 KB alongside SKILL.md
references/
- acceptance-criteria-guide.md9.0 KB
- prd-template.md5.0 KB
- prioritization-frameworks.md8.9 KB
Gives 0 of the 12 instructions most product growth skills give in ~1.3k tokens
Counted across 694 of the 879 authors here whose files we hold, read 2026-09-06
- Check for product marketing context firstin 49 of 694, across 20 files
- Validate the why before building featuresin 18 of 694, across 4 files
- Respond to every comment in real-timein 17 of 694, across 6 files
- Structure launch marketing across three channel typesin 16 of 694, across 4 files
- Recruit early users one-on-onein 13 of 694, across 2 files
- Ask one question at a timein 13 of 694
- Rank features using ICE scoringin 12 of 694, across 3 files
- Identify primary conversion goalin 11 of 694, across 3 files
- Identify traffic contextin 11 of 694, across 3 files
- Evaluate headline effectivenessin 11 of 694, across 3 files
- Check visual hierarchy and scannabilityin 11 of 694, across 3 files
- Run product diagnosticsin 11 of 694, across 3 files
Said here and by no other author read
- Identify all stakeholders and their goals
- Clarify the core problem being solved
- Define acceptance criteria for each story
- Classify each requirement by priority
- Define MVP scope
- Assemble the PRD following the template
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.