A structured skill system that turns Claude into a personalized PM partner — context-aware, role-specific, and tailored to your product.
Important product decisions — UX choices, scope trade-offs, rejected ideas — get made in meetings and Slack but never written down. Six months later, nobody knows why something was built a certain way.
When a manager adds a new request, PMs accept it by quietly dropping something else from the roadmap. The trade-off is never explicit and never visible to the team.
PMs define the happy path well. But edge cases — what happens when a payment is pending, when a user has no permissions, when a service is down — get discovered by engineering mid-implementation.
PMs can't easily see what a feature touches in the codebase. They don't know which modules are affected, which shared services are involved, or what might break when something changes.
The system separates what is fixed from what is personal — and separates Claude's instructions from Claude's knowledge of the product.
The key insight: When the supervisor updates a skill or rule, only the Policy Layer changes. Each PM's CLAUDE.md and context files stay untouched. No merge conflicts. No re-interview.
Every file has a defined owner and a defined purpose. Nothing is ad-hoc.
Three inputs combine at runtime. Each is maintained separately.
Fixed logic. Defines the workflow, decision rules, output format, and quality constraints. Never changes per PM.
Product-specific knowledge. Makes the skill aware of this PM's product, team, and constraints. Different per PM.
PM profile. Defines authority, communication style, technical depth, and behavioral instructions for Claude.
Same skill logic, but the output references the right modules, business rules, team conventions, and authority limits specific to this PM.
Example: The edge-case-finder skill runs identical logic for every PM. But for a fintech PM, it checks payment gateway timeouts, account verification states, and financial compliance limits — because those are in their context.md. For a content PM, it checks a completely different set of constraints.
One structured conversation generates 13 files. Every question maps to a specific output. Nothing is collected without purpose.
Questions are in Persian. Each question includes selectable options. AI uses conversation history to skip things it already knows. Vague answers trigger one targeted follow-up before moving on.
Two commands to install, one interview to personalize. Everything runs from inside Claude Code — no manual file editing required.
One command. Installs the claude-pm CLI on your machine.
npm install -g claude-pm
Installs all PM skills to ~/.claude/ globally, and scaffolds the policy tree, interview file, and placeholder context files inside the repo.
cd your-product-repo
claude-pm init --role pm
Launch Claude Code inside the product repo. Skills and policy files are now discoverable from the session.
Type /start-interview to begin. The interview runs in Persian, takes 20–30 minutes, and generates all 13 context files at the end. Each question maps to a specific output file — nothing is collected without purpose.
/start-interview
13 files appear: CLAUDE.md at repo root, 11 context.md files (one per skill), and product-agent.md in .claude/agents/. Review the key decisions and business rules captured before committing.
git add CLAUDE.md .claude/ .gitignore && git commit -m "feat: add PM workflow context"
Open Claude Code and describe a feature. The full context is loaded automatically on every session.
/new-feature [describe your feature]
Updating policy: When the supervisor ships new skills or rules, run claude-pm update. Your CLAUDE.md and all context files are never touched.
Personal context: Create CLAUDE.local.md at repo root for private notes. It's gitignored and loads alongside CLAUDE.md on every session.
The separation of Policy Layer and Dynamic Layer means supervisor updates never touch PM-owned files. No merge conflicts.
Supervisor pushes to product-team-claude-skills repo. PM runs:
cd claude-workflow && git pull && cd ..
That is the entire update process. Nothing else required.
Because policy files and PM-owned files live in separate directory trees, git pull never creates a merge conflict. The separation is enforced by the repository structure, not by process.
Two configuration files define how Claude behaves by default for every PM in the team.
Each skill is a focused, context-loaded workflow that Claude runs on demand. Invoke by command or let chains run them in sequence.
Vague idea → engineering-ready DOD
Defensible prioritization with trade-offs
Codebase-read dependency analysis
Stress-test a feature definition
Scope creep detection and trimming
Full team alignment spec document
Engineering-precise requirements
Pre-release impact analysis
Structured test plan from codebase
Capture product decisions before they're lost
Inventory existing UI components
Interactive HTML wireframe with all states
Linear task with four-part structure
Agenda prep and action item extraction
Polished HTML slide deck generation
Analyze and rewrite prompts for clarity
Turn a vague feature request or product idea into a precise, engineering-ready Definition of Done — before the team wastes time building the wrong thing.
"I want to build this", "management asked us to do this", "what's the DOD for this task", or any time a feature idea needs to become a precise deliverable before engineering discussion starts.
A four-part Linear task structure: context, user story, DOD (the most critical part), and out-of-scope list. Preliminary edge cases and dependencies are also surfaced.
Invoke: /problem-framing [describe the feature] — or runs automatically as Step 1 in /new-feature
Make prioritization decisions that are explicit, documented, and defensible — not silent trade-offs that quietly reshape the roadmap without anyone noticing.
"Which one should we build first", "management wants this feature but it conflicts with our roadmap", "how do I justify not doing this", or any situation where a prioritization decision needs to be made and communicated.
A scoring analysis across strategic alignment, user impact, technical effort, and risk. Clear recommendation with reasoning, what gets deprioritized, and a handoff to decision-logger to capture the choice.
Includes automatic handoff to decision-logger — every prioritization decision gets captured before it's forgotten.
Read the codebase directly to identify what modules, services, and components a planned feature will touch — so the PM can have informed conversations with engineering.
"Engineering said it has dependencies but I don't know what", "before we start I need to know which modules are affected", or any time a PM needs technical dependency analysis before committing to a feature.
A dependency map of affected files/modules, complexity estimate, cross-team coordination needs, and questions the PM should ask engineering before the sprint begins.
This skill reads the repository directly — it does not ask the PM to describe the code. Requires Claude Code with repository access.
Stress-test a defined feature before engineering starts — finding the cases the PM hasn't thought of, before engineering finds them mid-sprint or users find them in production.
"What did I miss", "what are the edge cases for this feature", "engineering said we didn't consider this case", or any situation where a feature definition needs to be tested before implementation begins.
A prioritized list of edge cases with risk levels (critical/high/medium), each case's required UI state, and flags for which cases need distinct wireframe states in the next step.
Output feeds directly into wireframe-generator — all states found here must be represented as wireframe states in Step 4.
A scope creep intervention tool for features that have grown beyond their original boundaries. Identify what was added, what's essential, and where scope can be trimmed without losing core value.
"This feature keeps growing", "engineering said there's too much work", "we keep adding things mid-sprint", "management is adding requirements". Do NOT use for initial scope definition — use problem-framing for that.
Original scope vs. current scope comparison, categorized additions (essential / nice-to-have / out-of-scope), a trimmed MVP definition, and what to defer to a future iteration.
Use when drift has already started. For initial scope definition before implementation, use /problem-framing instead.
Produce a single comprehensive spec document that serves as the source of truth for a feature — for engineering, design, QA, and stakeholders.
"Write the spec for this feature", "I need a document for the team meeting", "the spec needs to be ready before the sprint starts". Use this for whole-team alignment. Use requirement-writer when engineering needs deeper precision.
Feature overview with business context, user story, design considerations, acceptance criteria for all roles (engineering + design + QA), out-of-scope section, and open questions.
Not the same as requirement-writer: feature-spec is for team alignment; requirement-writer is for engineering precision on error states and validation rules.
Write engineering-ready requirements that leave no ambiguity — every path, every error state, every validation rule — so developers can implement without asking follow-up questions.
"I need engineering to have all the details", "write the technical requirements", "engineering said the requirements are incomplete", "I need to specify every error state and validation rule".
Complete flow documentation covering: all user actions, every API call, every error response, all validation rules, business rules, and edge cases. Structured so a developer can implement without guessing.
Use after feature-spec when engineering needs implementation precision. The spec aligns the team; the requirements guide the build.
Analyze the impact of a feature or change before it goes to production — identifying what else in the system might break or be affected.
"We want to release this, what might break", "what else does this change affect", "what do we need to check before deploying", or any time a PM needs pre-release impact analysis.
Affected modules and services, downstream dependencies, regression risk assessment, suggested rollback triggers, and a list of areas that must be verified before release. Feeds directly into qa-guide.
Reads git history and the repository directly. Run as part of /release-check to automatically chain into a full test plan.
Generate a complete, prioritized testing guide from the codebase — so QA knows exactly what to test, in what order, and why.
"We need to test this, what do we check", "what is the test plan for this feature", "what should QA test", "we changed the payment module and need to make sure nothing broke".
Prioritized test cases (P0/P1/P2) with pre-conditions, steps, and expected outcomes. Regression test list for affected modules. Happy path, edge cases, and error state coverage all included.
Works best after release-impact — uses its output to focus test coverage on the right areas. Also runs standalone for any feature QA.
Capture important product decisions in a structured, retrievable format before they get lost in chat history, meeting memory, or Slack threads.
"We need to write this decision down", "why did we choose this design", "the meeting ended and we decided something but nobody wrote it down", "we reduced scope but never documented why".
A structured decision record with: decision type, context, options considered, final choice, rationale, who made the call, and date. Appended to the project's decision log. Handles UX, architecture, scope, and prioritization decisions.
Called automatically by feature-prioritization at the end of every session. Also invoke directly after any meeting where an important decision was made.
Inventory what UI components already exist in the design system before planning new work — so the team isn't building something that already exists.
"What components do we have", "do we need to build this UI from scratch or do we have a component", "the designer said we need a new component" — before requesting design work for UI that may already exist.
Available components that can be reused as-is, components that need extension, and net-new components that must be built. Feeds into wireframe planning so existing components are used wherever possible.
Invoke: /design-system-check [describe the UI needs]
Generate interactive HTML wireframes showing a feature in multiple states and multiple interaction pattern variants — not just the happy path.
"Show me what this looks like", "generate a wireframe", "I want to see all the states", "show me different ways to implement this", "make a visual prototype of the flow".
A self-contained HTML file with clickable state transitions: empty state, loading, success, error, edge cases. Multiple UX variants presented side-by-side. Uses existing design system components found by design-system-check.
Invoke: /wireframe-generator [feature description + states to show]
Convert any output — a problem framing, a spec, a bug report — into a ready-to-paste Linear task with the team's standard four-part structure.
"Write a Linear task", "create a task for this", "I need to log this in Linear", or when any other skill explicitly hands off to this one. Use after problem-framing or feature-spec.
A formatted Linear task with four parts: (1) Context — why this matters, (2) User Story — who benefits and how, (3) DOD — precise completion criteria, (4) Out of scope — explicit exclusions. Ready to paste directly into Linear.
Invoke: /task-writer [describe what the task is about]
Prepare structured agendas before meetings and extract action items, decisions, and open questions after them.
"Prepare the agenda for our sprint planning", "summarize what we decided", "extract action items from this meeting", "log the decisions from today", "what are the open questions from the meeting".
Pre-meeting: timed agenda with discussion points, decision goals, and prep questions. Post-meeting: structured summary with decisions made, action items with owners, and open questions that need follow-up.
Invoke: /meeting-support [meeting type + context]
Generate polished, single-file HTML slide decks following a precise design system — no external dependencies, scroll-based, publication-ready.
"Make a presentation", "create a slide deck", "build a pitch deck", "I need to present this to the team". Trigger on any request for a presentation, deck, or slide document.
A self-contained HTML file saved to docs/. Title slide, content slides (cards, step rows, arch layers, code blocks), and summary slide — all following the team's flat-color, no-shadow design system.
Invoke: /presentation-style [topic and content description] — saved to docs/ for GitHub Pages publishing
Analyze, critique, and rewrite prompts to maximize clarity, specificity, and output quality — for both claude.ai and Claude Code.
"Optimize this prompt", "improve my prompt", "review my prompt", "what's wrong with this prompt", or when you paste a prompt draft and want feedback. Works for both casual claude.ai conversations and Claude Code workflows.
A critique identifying ambiguity, missing context, and vague instructions. A rewritten prompt with specific improvements. An explanation of what changed and why each change improves output quality.
Invoke: /prompt-optimizer [paste your prompt]
A complete end-to-end feature development workflow — from raw idea to spec, wireframe, and Linear task — in one command.
Define the DOD, preliminary edge cases, preliminary dependencies
Read the codebase — which modules does this touch?
Prioritized edge cases with risk levels and required UI states
Inventory available components before wireframing
HTML wireframe covering all states, using existing components
Complete spec consolidating all previous outputs — ready for team handoff
Invoke: /new-feature [describe the feature] — Claude waits for PM approval between each step before proceeding
Analyze the full impact of a release and generate a complete test plan — from codebase and git history — in one command.
Read git diff and codebase — what modules are affected, what could break, what are the regression risks?
Prioritized test plan (P0/P1/P2) based on the impact analysis, covering happy path, edge cases, and regressions
Invoke: /release-check [feature name or branch] — or omit arguments to use the latest git diff
Compare the feature spec with the current implementation — find where the spec is outdated, where the implementation deviated, and where the PM needs to make a decision.
Reads the feature spec file from the repository, reads the current implementation source files directly, and checks git history for recent changes — no manual description needed.
A Spec Drift Report: (1) Spec outdated — impl is correct, update the spec. (2) Implementation deviated — spec is correct, flag for engineering. (3) PM decision needed — unclear which is right.
Never updates any file automatically. Presents proposed changes and waits for PM approval. Invoke: /sync-spec [feature name or spec file path]
A complete PM workflow system — from first idea to post-release QA — with every step documented, every decision captured, and every artifact structured for the team.
problem-framing → feature-dependency → edge-case-finder → design-system-check → wireframe-generator → feature-spec
requirement-writer for engineering depth, design-system-check for UI clarity, task-writer for Linear — every handoff structured.
release-impact + qa-guide automatically chained in /release-check. sync-spec keeps docs aligned with what was actually built.