16 Claude Code Commands Every PM Should Steal

0. The context interview — the command every other command depends on

Not numbered 1 because it isn't an artifact command — it's the step that makes the other 16 grounded instead of generic. Open a fresh workspace and say: "Interview me to create context files about my product, my users and my company. Ask one question at a time, then write the files." Every command below reads those files before it writes anything. Skip this and you've got a very well-organized version of ChatGPT.

The 16 below are grouped the way an actual week uses them — discovery feeds strategy, strategy feeds delivery, delivery feeds quality and evals, and the week's worth of artifacts feeds the exec update — rather than as an alphabetical list nobody would read past number three. Skim to the group you need today; the rest will still be here next sprint.

Discovery: turn a hunch into evidence

1. /hypothesis-refine — sharpen a vague hunch into a falsifiable bet. Takes a rough idea and pressure-tests it against a six-criteria framework until it's specific enough to actually be wrong about — the difference between "users want better onboarding" and a bet you could design an interview around. Most PMs skip this and go straight to interviews with a fuzzy premise, which is how you end up with forty pages of notes and no clearer sense of what to build.
2. /interview-analysis — extract the insight without losing it. Reads raw interview notes against your hypotheses and reports what gained evidence, what lost it, and what's still untested — instead of a generic theme summary that rounds outliers away. Full workflow here.
3. /ost — map the Opportunity Solution Tree. Takes the evidenced opportunities from interview analysis and structures them under your outcome, Teresa Torres-style, with every branch traceable to a real interview. Full workflow here.

Strategy: turn a diagnosis into a defensible bet

4. /product-strategy — spar your way to clarity. Runs a structured sparring session using the Reforge 4-type strategy model and the Racecar framework, pushing back on vague strategy statements instead of politely accepting them. The value isn't the document it produces — it's the twenty minutes of the agent asking "why that and not the obvious alternative" until your reasoning actually holds up.
5. /initiative — frame the bet. Turns a validated opportunity or strategic direction into an 8-section initiative document built for cross-functional alignment — the bridge between "here's the diagnosis" and "here's what we're specing." It's the artifact you'd actually bring to a planning review, not a slide deck reconstructed from memory the night before.

Delivery: from bet to backlog

6. /prd — a lean, engineer-ready PRD. Grounded in your context files, asks about gaps instead of inventing metrics or personas you never gave it. Full workflow here.
7. /user-story — Jira-ready stories with acceptance criteria. Slices a PRD into INVEST-format stories with testable Given/When/Then criteria an engineering team can build straight from. Full workflow here.
8. /epic — break an initiative into epics, risk-mapped. Structures delivery around Marty Cagan's four big risks (value, usability, feasibility, business viability) instead of a flat feature list, so the risk that actually sinks the project — usually feasibility or business viability, rarely the one everyone worries about — gets named before sprint one instead of discovered in sprint four.
9. /publish — ship straight to Jira or Confluence. Takes the finished artifact and pushes it directly into your tracker, closing the loop between "drafted" and "the team can see it" without a manual copy-paste pass that quietly introduces formatting drift between the doc and the ticket.

An alternative framing entry point: Working Backwards

10. /press-release — an Amazon-style PR/FAQ. For bets risky or ambiguous enough to earn a Working Backwards pass before they get an initiative doc — writes the press release and stress-tests the FAQ before you commit to specing anything. Full workflow here.

Quality and evals: before you ship, and before you trust an LLM feature

11. /test-scenarios — QA test scenarios generated from a PRD. Reads the spec and produces a table of test scenarios an engineer or QA can run against, instead of a tester reverse-engineering the PRD's intent from scratch and inevitably missing an edge case the PRD actually specified three paragraphs down.
12. /evals — a v0 eval plan for LLM-powered features. Designs an initial evaluation plan validated with error analysis — the discipline most PM-owned "AI features" ship without, because nobody wrote the eval plan down before launch and then everyone is surprised when the feature's failure modes only surface in a support queue three weeks later.

Exec communication: judgment under a deadline

13. /decision-brief — a brief that survives the exec room. Builds the brief with reasoning sparring baked in, then runs an exec pushback simulation against it before you're standing in front of the actual room — so the hardest question in the meeting is one you've already answered once, in private, where getting it wrong doesn't cost you the room.
14. Leadership update reports. A periodic-update command that pulls from the week's actual artifacts — the initiative, the PRD, what shipped — instead of you reconstructing the narrative from memory every Friday afternoon and inevitably forgetting the thing that actually mattered most.

The one people forget until QA finds a gap

15. Event tracking specifications. Turns a user story into a taxonomy of events worth tracking, so analytics gets specced at the same time as the feature instead of being bolted on after launch when someone asks "wait, are we even tracking that?" — usually right when you need the number for a leadership update and don't have it.

Sixteen sounds like a lot until you notice the shape: five groups mapping to the five things a PM's week actually consists of — figuring out what's true, deciding what to bet on, specing and shipping it, checking it works, and telling people about it. Nothing here replaces judgment on any of those five. What it replaces is the blank page at the start of each one.

That's 16, and none of them are useful in isolation — the entire point is that each one hands its output to the next: interview analysis feeds the tree, the tree feeds the initiative, the initiative feeds the PRD, the PRD feeds stories, tests, and the eval plan, and the week's worth of artifacts feeds the leadership update. That chaining is what actually separates agentic PM work from a folder of unrelated prompts.

How to actually steal these

You don't need all 16 on day one. Pick the command that maps to whatever's due this week — probably /prd or /user-story — and build it as a saved instruction file in your own workspace: write the prompt once, save it as .claude/commands/prd.md, and from then on typing /prd runs it against your current context. Add the next command when the next artifact type comes up. A command library built this way, one real need at a time, ends up better suited to your actual job than any pack you download and never customize.

Two habits make the difference between a command that gets sharper over time and one that quietly rots. First, when a draft comes back wrong, don't just fix the output — fix the instruction file so the same mistake doesn't recur next time. Second, review your saved commands every few months against how your role has actually changed; a command written for your first PM job will under-serve you once you're framing 8-section initiative docs instead of writing tickets. The commands are supposed to compound, not calcify.

FAQ