Claude Code for Product Managers: A CLI for PMs

The PM Who Moved Into the Terminal

Dennis Yang, Principal PM for Generative AI at Chime, said something that stopped the product management world mid-scroll: "Cursor is a much better product manager than I ever was." He wasn't joking. He'd replaced his entire PM stack — Confluence for docs, Jira for tickets, Notion for specs — with an AI coding tool, using MCP integrations to sync everything back to the tools his team expected.

That was the signal. But the trend goes further than one PM at one company.

George Nurijanian documented a complete product development pipeline running through Claude Code — from idea extraction through specification, prototyping, development, and deployment. His argument was blunt: "I know IDEs are not the most common tools for PMs, and CLI tools aren't either, but I think it's time for us all in the profession to throw away these old notions."

PMs are moving into the terminal. Not because they became engineers — because the terminal became a better PM environment than anything built specifically for PMs.

Why a CLI Beats Your PM Tool

This sounds counterintuitive. PMs are supposed to use visual tools — boards, editors, dashboards. Why would a command-line interface be better?

Three reasons.

Context density. Claude Code reads your entire codebase. When you write a spec in Claude Code, the AI knows what exists — your data models, your API surface, your component library, your test patterns. Write a spec in Notion and you're working from memory. Write one in Claude Code and you're working from reality.

Action density. In a traditional PM workflow, writing a spec is one action. Creating tickets is another. Syncing the board is another. Checking implementation status is another. In Claude Code, you describe what you want, and the agent writes the spec, generates the tickets, checks the code, and reports back — in one session. The action density per minute is 10x higher.

No context switching. Your spec, your code, your board state, and your agent conversation exist in the same environment. There's no alt-tab between Notion and Linear and GitHub. The information flows through one interface. The context-switching tax that fragments your PM stack disappears.

Setting Up Claude Code as a PM Tool

If you're a PM ready to try this, here's the practical setup. You don't need to write code. You need to configure context.

Step 1: CLAUDE.md — Your Agent's Constitution

The CLAUDE.md file at your project root is always loaded into Claude Code's context. It's where you define how your agent thinks about your product. Shrivu Shankar — whose engineering team processes billions of tokens per month through Claude Code — treats this file as the agent's "constitution" and approaches it like "selling ad space": every line must earn its inclusion.

For PM work, your CLAUDE.md should include:

• Product context. What the product does. Who it's for. What stage it's at. The current business goals.
• Spec conventions. How specs are structured. Required sections. The quality bar.
• Decision history. Key architectural and product decisions that constrain future choices.
• Tool pointers. Where tickets live. Where specs live. What MCP servers are available.

One critical pattern from Shankar's experience: avoid negative constraints. Don't write "never use polling" — write "prefer WebSockets for real-time features (see notification system for pattern)." Agents get stuck on prohibitions without alternatives.

## Product
Stonewall is an AI-native product management platform for
engineering teams (15-80 people) without dedicated PMs.

## Spec Format
Every spec requires: problem statement (with customer quotes),
proposed solution, acceptance criteria (testable), effort estimate,
and out-of-scope section.

## Current Priority
Q2 2026: drift detection and MCP server for agent integration.
All specs should consider these as the active workstreams.

Step 2: Custom Slash Commands for PM Workflows

Claude Code supports custom commands in .claude/commands/. Each command is a markdown file that becomes a slash command in the CLI. This is where PM workflows come alive.

Create a /spec command that generates a codebase-aware specification:

<!-- .claude/commands/spec.md -->
Generate a product specification for: $ARGUMENTS

Read the codebase first. Identify relevant files, data models,
and existing patterns. The spec must include:
1. Problem statement (cite customer feedback if available)
2. Proposed solution grounded in the current architecture
3. Acceptance criteria (testable assertions)
4. Technical constraints from the existing codebase
5. Effort estimate (S/M/L with reasoning)
6. Out of scope (explicit boundaries)

Create a /review-pr command that checks PRs against spec intent:

<!-- .claude/commands/review-pr.md -->
Review the current PR against its specification.

Check for:
- Requirements that were specced but not implemented
- Implementation details that diverge from the spec
- Edge cases mentioned in the spec but not handled
- New behavior introduced that isn't in the spec

Flag each as: DRIFT (spec says X, code does Y),
MISSING (spec requires X, code doesn't address it),
or ADDITION (code does X, spec doesn't mention it).

These commands turn Claude Code from a general-purpose agent into a PM-specific workflow engine. The agent has your codebase context, your product context (from CLAUDE.md), and structured instructions for exactly what you need.

Step 3: MCP Integrations for Your Existing Tools

Model Context Protocol lets Claude Code reach into external systems. For PMs, the critical integrations are:

Linear MCP — query and create issues directly from Claude Code. "What's the current status of the authentication epic?" becomes a direct query, not a browser tab.

GitHub MCP — check PR status, review comments, deployment state. The PM visibility layer that currently requires opening GitHub.

Product spec MCP — expose your specs as structured context so the agent can reference them during any task. This is the bridge between code context and product context that makes AI-assisted PM work actually coherent.

Step 4: Hooks for Guardrails

Claude Code's hooks system lets you enforce rules automatically. Shankar describes the key principle: "CLAUDE.md is advisory while hooks are mandatory." For PM workflows, hooks ensure quality without requiring discipline:

• A pre-commit hook that validates specs have all required sections before they can be committed.
• A post-edit hook that checks specs against a template and flags missing fields.
• A submit hook that warns when a spec references files that don't exist in the codebase.

Hooks are the difference between "please follow the spec template" (advisory, ignored under pressure) and "you cannot commit a spec without acceptance criteria" (mandatory, always enforced).

The Practical PM Workflow in Claude Code

Here's what a Monday morning looks like for a PM using Claude Code:

Morning triage (15 minutes). Open Claude Code. "What PRs merged last week? Summarize each against its spec. Flag any that introduced behavior not in the spec." The agent reads GitHub, cross-references specs, and produces a drift report. In a traditional workflow, this takes 45 minutes of tab-switching.

Spec writing (30 minutes). "Write a spec for adding email notifications to the comment system." The agent reads the codebase, identifies the existing notification infrastructure, the comment module, and the email system. It generates a spec grounded in what exists — not a generic document that ignores your architecture.

Backlog review (20 minutes). "What are the top 5 customer requests from the feedback log? Cross-reference with the current backlog — what's already planned, what's new?" The agent clusters feedback, checks existing tickets, and surfaces gaps. Prioritization with context, not from memory.

Status update (10 minutes). "Generate a weekly status report from GitHub activity and the kanban board." The agent reads PR activity, board state, and open specs, producing a stakeholder-ready summary. No manual compilation.

The Plugin Ecosystem Changes Everything

The raw CLI is powerful. But the plugin ecosystem — skills, commands, and marketplace extensions — is where Claude Code becomes a complete PM platform.

Dean Peters' Product-Manager-Skills package alone includes 47 skills covering user stories, personas, PRDs, competitive analysis, and full product discovery cycles. Install it with one command and Claude Code gains structured PM frameworks — Teresa Torres' Continuous Discovery, Amazon's Working Backwards, Jobs-to-Be-Done, RICE scoring — all encoded as interactive workflows the agent runs on demand.

The Superpowers framework adds brainstorm-plan-implement workflows with automatic git worktree creation, TDD cycles, and PR management. The spec-driven development workflow encodes the requirements-to-implementation pipeline directly into Claude Code.

These aren't toys. They're production PM workflows, battle-tested by teams shipping real products. And they're composable — combine a PM skills package with a spec workflow plugin and a code review command, and you have a PM stack that lives entirely in the terminal.

For the full landscape, awesome-claude-code maintains a comprehensive index of skills, hooks, slash commands, and tooling — it's the best starting point for discovering what's available.

The Uncomfortable Question

If Claude Code can write specs grounded in your codebase, generate tickets, check PRs against requirements, synthesize customer feedback, and produce status reports — what exactly is the PM tool doing that justifies $50/month per user?

The answer, increasingly, is: providing a GUI for work that an agent does better in a CLI.

That doesn't mean PM tools are dead. It means the value proposition is shifting. The PM tool of the future isn't the environment where you do the work — it's the system that gives the agent structured context to do the work well. The knowledge layer. The spec infrastructure. The living spec system that stays connected to code and board.

The terminal is the new PM workspace. The question is what feeds it.