Skip to content

README.md

Latest commit

 

History

History
448 lines (319 loc) · 17.6 KB

README.md

File metadata and controls

448 lines (319 loc) · 17.6 KB
Raw

pm-workbench

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 | 简体中文

Start here if you only have 3 minutes

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:

  1. copy pm-workbench/ into your OpenClaw skills directory
  2. run npm run validate
  3. run openclaw skills check
  4. try one real PM prompt

Then decide whether you want to keep tuning or publish.

What this is

A workflow skill for turning ambiguity into decisions, reusable outputs, and explicit trade-offs.

Best fit

  • PMs handling messy asks
  • product leaders making priority or resource calls
  • founders needing sharper product / business trade-offs

Try these 3 prompts first

  1. Vague leadership ask
    “My boss said our AI product needs more wow factor. Help me unpack what that actually means.”
  2. Quarterly prioritization
    “We only have room for 3 of these 8 requests next quarter. Help me prioritize them and explain what waits.”
  3. Founder / product path trade-off
    “Help me choose between a fast marketable AI layer and a slower trust-building product path.”

Why install this instead of asking a generic model directly?

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:

pm-workbench hero

Why this feels different

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

Generic AI vs pm-workbench

Benchmark snapshot

This repo includes a visible proof layer, not just positioning copy.

pm-workbench benchmark summary

Illustrative worked-example totals using the repo rubric:

  • Clarify vague leadership ask: generic AI 3 vs pm-workbench 18
  • Product-leader prioritization: generic AI 8 vs pm-workbench 19
  • Executive summary with real ask: generic AI 10 vs pm-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:

The core product logic

pm-workbench is built around a simple idea:

Fuzzy ask → Clarify → Evaluate / Compare / Prioritize → Artifact → Leadership communication / planning / alignment

pm-workbench workflow map

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.

What you get

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.

Not only single workflows

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:

12 workflow paths

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

Reusable output shapes

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

Anti-template by design

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.

Benchmark and trust layer

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 validate

What 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.

High-tension case studies

If you want to understand the difference fast, start with these:

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

Examples that show correction, not just output

A good PM workbench should not only answer clean prompts. It should also repair bad prompts.

Start here:

Higher-pressure leader examples

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

Install and use

Option 1 — use the source folder directly

This is the easiest and most transparent path.

3-step install path

  1. Copy

    • Clone or copy this repository.
    • Place the pm-workbench folder under your OpenClaw skills workspace.

  2. Validate

    cd skills/pm-workbench
npm run validate

  3. 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 validate is the most reliable first check that the repo itself is structurally sound before debugging local discovery

Option 2 — use a packaged .skill

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.

First prompts to try

  • “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.”

In scope vs out of scope

In scope

  • PM judgment
  • product decision framing
  • prioritization and leadership communication
  • reusable PM outputs
  • founder / product-leader product-business trade-offs

Out of scope

  • 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.

Repository structure

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

What to read next

Validation and quality bar

This repo is being built with a simple quality bar:

  • the main SKILL.md stays 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 check in the target environment

Contributing

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

Roadmap

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.

Bottom line

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