Turn vague product asks into clear PM outputs people can actually use.
pm-workbench is an OpenClaw skill for PMs, product leaders, and founders who need clearer product judgment under messy real-world constraints.
It is built for the work between “someone asked for something” and “we need a recommendation, reusable output, or next move we can stand behind.”
Current release target: v1.2.0
Language: English | 简体中文
If you are about to copy this to another machine — including a fresh Windows setup — do not overthink the first run. The shortest path is still:
- copy
pm-workbench/into your OpenClawskillsdirectory - run
npm run validate - run
openclaw skills check - try one real PM prompt
Then decide whether you want to keep tuning or publish.
A workflow skill for turning ambiguity into decisions, reusable outputs, and explicit trade-offs.
- PMs handling messy asks
- product leaders making priority or resource calls
- founders needing sharper product / business trade-offs
- Vague leadership ask
“My boss said our AI product needs more wow factor. Help me unpack what that actually means.” - Quarterly prioritization
“We only have room for 3 of these 8 requests next quarter. Help me prioritize them and explain what waits.” - Founder / product path trade-off
“Help me choose between a fast marketable AI layer and a slower trust-building product path.”
pm-workbench is not a PM theory pack or prompt pile. It is an OpenClaw-native PM workbench designed to:
- clarify the upstream problem first
- ask only the missing questions that change the decision
- force explicit trade-offs and “not now” calls
- shape outputs into reusable PM artifacts instead of polished rambling
If you want the shortest path, go here:
- START_HERE
- 3-minute quick start
- Scenario Router
- 10 real entry prompts
- Command-style combinations
- Try 3 prompts in 10 minutes
Most AI tools can talk about product work.
pm-workbench is designed to help you get to a usable next step.
It has a few deliberate habits:
- it routes by the actual PM job to be done, not by abstract framework recital
- when the ask is still fuzzy, it helps get the problem frame right before moving into the right workflow
- it asks for only the missing context that would materially change the recommendation
- it prefers artifacts you can reuse in meetings, reviews, and leadership syncs
- it makes trade-offs, assumptions, risks, and “not now” calls explicit
- it works for both single-feature PM work and product-leader / founder decision work
- it includes a benchmark layer so visitors can inspect side-by-side differences versus generic AI
This repo includes a visible proof layer, not just positioning copy.
Illustrative worked-example totals using the repo rubric:
- Clarify vague leadership ask: generic AI
3vspm-workbench 18 - Product-leader prioritization: generic AI
8vspm-workbench 19 - Executive summary with real ask: generic AI
10vspm-workbench 19
Why this matters:
- the repo shows differentiation across upstream framing, portfolio prioritization, and leadership communication
- visitors can inspect the comparison chain instead of relying on README claims
- the benchmark now documents fairness controls and known limitations, not just self-scoring
Start here:
- Benchmark kit
- Command benchmark guide
- Benchmark run records
- Failure regression checks
- Benchmark contribution guide
- Share-friendly benchmark card
pm-workbench is built around a simple idea:
Fuzzy ask → Clarify → Evaluate / Compare / Prioritize → Artifact → Leadership communication / planning / alignment
This matters because a lot of PM work fails at the upstream handoff:
- vague asks turn into vague discussion
- solution ideas arrive before the problem is clear
- feature evaluation becomes opinion trading
- prioritization becomes politics or scorecard theater
- roadmap reviews hide what is intentionally not being done
- leadership summaries bury the actual conclusion
pm-workbench is designed to reduce those failure modes.
If the user is still figuring out what kind of product problem this is, the skill can help frame it first, then move into the right workflow and output.
pm-workbench is not limited to one workflow at a time.
For recurring PM jobs that naturally span multiple steps, it also supports command-style combinations — compact cross-workflow paths such as:
- clarify -> evaluate
- clarify -> compare
- prioritize -> roadmap -> exec summary
- PRD -> metrics -> exec summary
That matters because a lot of real PM work is not one prompt deep. It is a short sequence: frame the problem, make the call, then turn it into something reusable.
Start here:
| PM job | Workflow | Default output shape |
|---|---|---|
| Clarify a fuzzy ask | clarify-request |
Request Clarification Brief |
| Judge whether to do something | evaluate-feature-value |
Feature Evaluation Memo |
| Choose between options | compare-solutions |
Decision Brief |
| Rank competing work | prioritize-requests |
Prioritization Stack |
| Draft a lightweight spec | draft-prd |
PRD Lite |
| Turn priorities into a staged plan | build-roadmap |
Roadmap One-Pager |
| Define success measurement | design-metrics |
Metrics Scorecard |
| Prepare upward communication | prepare-exec-summary |
Executive Summary |
| Learn from a launch / initiative | write-postmortem |
Postmortem Lite |
| Make an above-the-line portfolio call | portfolio-review |
Portfolio Review Summary |
| Diagnose mixed product operating signals | head-of-product-operating-review |
Head of Product Operating Review |
| Separate founder narrative from business truth | founder-business-review |
Founder Business Review |
This repo does not stop at “analysis.”
It includes reusable PM templates under references/templates/ so the skill naturally shapes outputs into things a PM can actually use.
Current built-in template library:
- Request Clarification Brief
- Feature Evaluation Memo
- Decision Brief
- Prioritization Stack
- PRD Lite
- Roadmap One-Pager
- Metrics Scorecard
- Executive Summary
- Postmortem Lite
- Portfolio Review Summary
- Head of Product Operating Review
- Founder Business Review
A template is a delivery choice, not a substitute for judgment.
This repo explicitly tries to avoid template theater:
- do not fill every section mechanically
- skip sections that add no decision value
- sharpen the conclusion before expanding the structure
- when speed matters, prefer a sharp compressed artifact over a bloated “complete” one
The goal is not to output something that merely looks like a PM doc. The goal is to output something that can actually help a decision, alignment, or review move forward.
This repo includes a concrete proof layer under benchmark/:
- realistic PM scenarios
- a comparison rubric
- a reusable scorecard
- a run-record template for preserving actual side-by-side outputs
- worked comparison artifacts with fuller evidence chains
- higher-pressure worked examples for launch readiness and mixed-signal diagnosis
- fairness-control notes
- known benchmark limitations
- a benchmark contribution guide
- README-ready visual summary assets
It also includes a lightweight local validation script so the repo can check its own structural integrity:
cd skills/pm-workbench
npm run validateWhat the validate script actually checks:
- required repo structure exists
- workflow / template / command wiring is not broken
- command workflow chains point to real workflows
- important docs and onboarding paths still link to real files
- benchmark assets and proof-entry docs are present
- example coverage is still wired correctly
- README / Chinese README / changelog / package version are still aligned
That is not glamorous, but it matters. Repos feel more trustworthy when they can verify more than prose.
If you want to understand the difference fast, start with these:
- Boss says the product needs more wow factor
- Ops wants an AI gimmick feature, PM is unconvinced
- 8 requests, only 3 fit next quarter
These are intentionally more conflict-heavy than standard format examples. They are there to show where the skill should outperform generic AI:
- messy stakeholder input
- hidden assumptions
- real trade-offs
- explicit non-decisions
A good PM workbench should not only answer clean prompts. It should also repair bad prompts.
Start here:
If you want to see where the repo is now aiming to feel more like a real product-leadership workbench, start here:
These are useful for testing whether the skill can:
- make a condition-based recommendation under uncertainty
- explain what not to do, not just what to do
- synthesize mixed signals into a real next focus
This is the easiest and most transparent path.
-
Copy
- Clone or copy this repository.
- Place the
pm-workbenchfolder under your OpenClaw skills workspace.
-
Validate
cd skills/pm-workbench npm run validate -
Confirm recognition
openclaw skills check
Then start with a real PM prompt.
If you prefer, you can also send a one-line install request to your Agent and let it adapt the steps to your setup. That Agent can be OpenClaw or any other AI assistant you already use.
Example:
Please install this skill: , and adapt the installation method to my current environment.
If you want the short install checklist, use:
Notes:
- this repo is designed as a source-first OpenClaw skill
- local recognition can depend on your OpenClaw version and skill-path configuration
npm run validateis the most reliable first check that the repo itself is structurally sound before debugging local discovery
If your environment already produces or distributes packaged OpenClaw skills, this repo is structured cleanly enough for that path too. But the default recommendation is still: start from source, validate fast, then customize.
- “Help me unpack this request before we jump to solutions.”
- “Should we build this feature, or is it not worth doing now?”
- “Compare these two directions and recommend one.”
- “Turn this into a one-page exec summary for leadership.”
- “Help me prioritize this quarter and say what should wait.”
- “Help me write a lightweight postmortem from this launch result.”
- PM judgment
- product decision framing
- prioritization and leadership communication
- reusable PM outputs
- founder / product-leader product-business trade-offs
- raw data-heavy analytics
- deep project or program tracking
- legal or compliance review
- general business operations tooling
- tasks where data crunching matters more than product judgment
This boundary is deliberate. The repo gets weaker if it tries to become a generic operating system for all business work.
pm-workbench/
├── SKILL.md
├── README.md
├── CHANGELOG.md
├── CONTRIBUTING.md
├── ROADMAP.md
├── package.json
├── benchmark/ # scenarios, rubric, scorecard, worked examples
├── docs/ # onboarding, quick-start, visuals, product-leader guide
├── examples/ # reusable PM and product-leader examples
├── references/
│ ├── workflows/ # workflow behavior specs
│ └── templates/ # default artifact shapes
└── scripts/
└── validate-repo.js
Current repo snapshot:
- 12 workflow references
- 12 templates
- 5 command-style combinations
- 23 examples
- benchmark kit with baseline, higher-pressure scenarios, command proof assets, and run-record templates
- failure regression checks for common PM-answer failure modes
- Start here: START_HERE.md
- 3-minute quick start: docs/TRY-IN-3-MINUTES.md
- Install checklist: docs/INSTALL-CHECKLIST.md
- Quick start: docs/GETTING-STARTED.md
- Scenario router: docs/SCENARIO-ROUTER.md
- 10 real entry prompts: docs/10-REAL-ENTRY-PROMPTS.md
- Command-style combinations: docs/COMMANDS.md
- Try it fast: docs/TRY-3-PROMPTS.md
- Benchmark kit: benchmark/README.md
- Command benchmark guide: benchmark/command-benchmark-guide.md
- Failure regression checks: benchmark/failure-regression.md
- Benchmark contribution guide: benchmark/CONTRIBUTING-BENCHMARKS.md
- Product leader guide: docs/PRODUCT-LEADER-PLAYBOOK.md
- Examples: examples/README.md
- How to contribute: CONTRIBUTING.md
- Where the skill is going: ROADMAP.md
This repo is being built with a simple quality bar:
- the main
SKILL.mdstays concise and routing-oriented - detailed behavior lives in workflow references
- reusable output shapes live in templates
- examples should show realistic PM usage, not just abstract format descriptions
- docs should reduce adoption friction for someone discovering the repo cold
- benchmark assets should make side-by-side comparison possible
- benchmark run records should preserve actual prompts, outputs, scoring, and limitations when claims need to be audited
- local validation should catch obvious structural drift early
- install and pre-release checks should be easy to follow for source-first use
Local verification completed for the repo structure:
npm run validate-> passes locally- validation confirms the expected workflow, template, example, and benchmark wiring is present
- OpenClaw skill recognition still depends on local version and skill-path configuration; verify it separately with
openclaw skills checkin the target environment
If you want to improve the skill, do it in a product-minded way:
- strengthen judgment quality, not just template volume
- prefer outputs that help real PM work move forward
- add examples when adding new workflows or templates
- keep claims in docs honest and easy to verify
- use benchmark scenarios to challenge the repo, not just flatter it
Start here: CONTRIBUTING.md
Short version:
- strengthen trust with harder evidence and fairer benchmark framing
- sharpen the 3 highest-signal workflows first
- reduce cold-start friction for new visitors
- deepen product-leader / founder trade-off support without losing focus
- expand only after the core judgment layer gets sharper
See the fuller plan in ROADMAP.md.
pm-workbench is for PMs who do not need more theory theater.
They need help turning ambiguity into:
- a clearer problem
- a stronger recommendation
- a reusable output
- a better decision



