On day two, mid-task, it read my CLAUDE.md and caught it teaching the exact pattern my own quality gate bans. I hadn’t asked for a review. It hit the contradiction and flagged it on its own.

That file is 320 lines. The knowledge layer behind it is 166 files, around 300k words of rules my agents follow every day. And every one of those rules was written by and for a weaker model.

This guide is what I did about that, plus everything else from 7 experiments and 1,000+ timed runs in Fable 5’s first four days.

One honest note before we start. I published my launch-day numbers on day two, then retested everything at 20 rounds per cell on a single build. Two headline claims didn’t survive. They’re corrected below with the old numbers named, not quietly replaced.

We’ll cover:

• What changed, what it costs, and the migration gotchas that bite first

• The effort dial and the “Fable is slow” complaint at 20 rounds per cell, including what flipped

• What a real finding costs: Fable bills 2x per token and still wins the audit math

• When your model silently swaps mid-conversation, and why the swap sticks

• The audit prompt to run before giving Fable real work, and the migration workflow behind the paywall

• Objectives, not tasks: /goal patterns (paid)

• My depth-10 nesting experiments, the real cost multiplier, the decision rule (paid)

We won’t cover: API migration fine print, benchmark-by-benchmark analysis, or anything I haven’t run myself.

1. What Actually Changed

According to Anthropic, Fable 5 is “a Mythos-class model that we’ve made safe for general use. Its capabilities exceed those of any model we’ve ever made generally available.”

They built a model they don’t fully release. Mythos 5 stays limited-access, available to trusted partners. Fable 5 is the version of it you’re allowed to have.

That framing matters more than any spec row, and we’ll come back to it in Section 3.

Fable plugs in wherever Opus 4.7/4.8 did, with a few breaks that will bite you if you migrate blind:

Three migration gotchas hiding in that table:

1. You can’t turn thinking off. Pipelines that set thinking: disabled for speed get a 400 error. The effort dial survives. Zero doesn’t.

2. Temperature is gone. If your eval suite sweeps sampling settings, those configs fail on Fable.

3. Until June 22, your API keys can’t reach it. Subscription surfaces only (Claude Code, Cowork, the apps). Plan your team’s testing window accordingly.

1.1 Fable 5 effort dial, measured

Instead of taking the docs' word for it, I measured. First at 5 rounds on launch day, then at 20 rounds per cell on day four:

What held from launch day:

• Below max, the dial barely moves. Thinking is adaptive. The model ignores budget it doesn’t need.

• Correctness never moved. On a hard math puzzle with a checkable answer, every effort level got it right, with the same method. The extra seconds bought re-verification and caveats, not better answers.

What’s new at n=20: max is where Fable and Opus separate the most, 60.8 vs 49.0 seconds at the median. And that gap moved between builds. The top of the dial is the unstable part.

One gotcha worth this whole section. Pass a typo to --effort and the CLI silently falls back to your configured level, not the model default. I ran --effort xyz 20 times as a control: median 17.6 seconds, right on top of xhigh (18.5s), nowhere near high (13.6s).

So check your settings before you benchmark anything. My machine had xhigh persisted, which means every flag-less run I timed ran both models at xhigh. Matched, so the ratios stand. But the honest label on my charts is “matched effort,” not “out-of-box default.” The documented default is high on both Fable 5 and Opus 4.8.

The practical setting hasn’t changed: default to high. Dialing down buys back a few seconds, not different answers. Max should stay a rare exception. It’s now the least stable level, too.

Subscribe now

1.2 Fable 5 speed question, retested

The loudest day-one complaint after the classifiers: “Fable is slow.” One widely shared review called it a crawl, “even on simple tasks.”

I couldn’t find numbers, so I made my own. 320 timed runs, both models at matched effort, stream-level timestamps, exact token counts, outliers kept:

What held:

• The starting pause is real. First visible activity at a median 6.7 seconds vs 4.3 for Opus. That 2.4-second blank screen is my bet for where the “it crawls” feeling comes from.

• The trivial tax is modest. On one-shot questions, Fable averaged 1.48x Opus wall-clock. Every answer correct from both models.

What flipped on the retest:

• “Denser, not slower” didn’t survive. On launch day, Fable used about 40% fewer output tokens on the same math problem and finished sooner. At n=20 the token gap shrank to 8%, and Fable finishes 1.5x behind.

• Neither did “the gap vanishes on real work.” Across 20 heavy multi-file audits, the median tax is 1.29x (best pair 0.92x, worst 1.70x). Two of twenty beat Opus outright. The tax flattens with task size. It doesn’t vanish.

What didn’t move: correctness. All 240 graded answers correct, from both models.

So the verdict is narrower than the discourse: budget a short pause at the start of every exchange, accept a 1.3 to 1.5x time tax, and ask what the extra time buys. Section 2 prices exactly that.

Subscribe now

1.3 The benchmarks

Anthropic’s official chart covers these better than any table I’d retype:

Two things the official chart won’t tell you:

• The row that tells you what tier this is: FrontierCode Diamond, the hardest unseen problems in the set, where Fable more than doubles Opus 4.8 (29.3 vs 13.4) and runs 5x GPT-5.5:

  

• And one honest footnote from the system card: Fable’s published scores already include its production safeguards, which is why some rows run slightly below Mythos.

2. What a Real Finding Costs

Fable bills 2x per token. Here’s what that turns into when the task is finding problems, not answering questions.

I ran 60 audits of the same three style-guide files, 30 per model. Every run was metered from session traces and validated to the cent against the CLI’s own billing:

Three prices for the same work:

• Per audit: 2.5x. $2.93 vs $1.17 at the median. Wider than the price sheet, because Fable also writes more.

• Per finding: 1.25x. Fable surfaces a median 14 distinct findings per report vs Opus’s 7. So $0.21 vs $0.17 each.

• Per the bug that matters: 0.25x. One planted issue required reading two files against each other. Fable caught it in 20 of 30 audits. Opus caught it in 2.

That last row is the one your invoice feels. Expected spend per deep catch: $4.40 with Fable, $17.55 with Opus. The expensive model is 4x cheaper!

It’s not “Fable finds everything,” though. A same-file style clash got caught more often by Opus, 16/30 vs 12/30. Depth and breadth are different axes.

For PMs: price the outcome, not the tokens. Per token, Fable costs 2x. Per deep finding, a quarter. Whoever frames the unit wins the budget conversation, and that’s as true for your product’s pricing page as it is for your AI bill.

3. The Safeguard Layer Most Coverage Missed

3.1 The visible layer: routing

Fable 5 ships with classifiers that screen for high-risk domains. When a query trips one, the session is routed to Opus 4.8 instead, and you get a notification. Anthropic puts it at ~5% of sessions.

My own experiments with subagents got capped, too:

It doesn’t fail the query. It hands it to a different model, on purpose, and tells you. The capability ceiling and the safeguard layer are different things, and knowing which one you hit changes what you do next.

And the reroute sticks. Per the Claude Code docs, the session continues on Opus after a flag. /model fable takes you back, but if the trigger is still in your context, the next request just bounces you again. I learned that one live. My first read was “you can’t switch back.” The docs’ version is more precise: you can switch back, you just can’t stay.

The classifier reads your workspace, too. CLAUDE.md content and git status ride along on the first request. So a repo full of security or biology material can reroute a session before you’ve typed anything unusual.

Why does the screen exist at all? According to Anthropic, “Mythos-class models have reached a threshold where they present significant risks.“ The example they give: these models “excel at discovering and exploiting software vulnerabilities,” enough to make cyberattacks “substantially easier and cheaper to commit.”

There’s also a second, invisible layer. Per the system card’s Section 1.5, requests targeting frontier LLM development itself don’t reroute. They get quietly degraded, with no notification, on ~0.03% of traffic. Unless your team pretrains models, you’ll never hit it. Researchers are furious anyway (Elie Bakouch’s “very very sad for the research community“), and the precedent stands: the model you bought can be tuned down by topic, silently.

3.2 What this means for your team

Four practical notes from the first four days:

• Expect occasional routing, especially if your work touches security, healthcare, or biotech. Anthropic admits it (Claude Code’s Boris Cherny: “We know the classifiers are trigger-happy, and are working on improving it“). The notification is your signal: you did nothing wrong, and the floor is “merely Opus 4.8.” For security audits, the supported path is the built-in /security-review command. Also see my /security-review-static, which inspects the full solution, not just the diff.

• Two diagnostics worth knowing. For example, claude --safe-mode starts a session without your customizations, so you can check whether your own files are the trigger. And /config has a toggle that asks before switching instead of switching silently.

• Once flagged, decide fast. Treat the session as an Opus session or start clean. Don’t fight the classifier mid-context.

• The API behaves differently. When per-token access opens June 22, a tripped classifier blocks the request and returns a structured refusal category. There’s no automatic fallback by default. Server-side fallback to Opus is opt-in. The same applies to claude -p scripts today: non-interactive runs get a refusal, not a reroute.

The safeguard is worth copying: it swaps your model mid-session for safety. We can swap on purpose, for cost. Keep a cheaper model as your default and bring in Fable 5 only for the one call that needs it. Section 8 has what that costs.

Side Note: On September 1 we’re launching the 3rd edition of Claudathon. It’s a hands-on program to learn by building and shipping production-ready apps with embedded agents.

Before the cohort you should get familiar with the basics: VS Code, CLAUDE.md, skills (we provide the materials).

Early bid discount: https://go.productcompass.pm/claudathon
Paid annual subscribers who enroll get a refund for the current billing period.

4. Judgment Is the Feature

The benchmarks got their chart in Section 1. The interesting part of this launch is a behavior change.

One disclosure before the quotes: every voice quoted in praise here works at Anthropic. Read them as insider testimony, not independent validation, then check them against my receipts.

Karpathy called it “a major-version-bump-deserving step change forward,” strongest “for long problem-solving sessions on very difficult problems:”

The people building Claude Code describe the same thing. Cherny, from his launch post: Fable "has judgement, taste, and dimensionality in a way that previous models didn't:"

He asked it to debug something, and it took measurements, added logs, and verified the fix before declaring victory. Then the line that stuck with me: "There's nothing in claude code's prompting telling the model to do that, it's just part of its personality."

Thariq Shihipar compressed it to six words: "it's time to be more ambitious:"

The closest thing to an outside read, four days in, is the shape of the criticism. Researchers are angry about the invisible safeguards (Section 3). Dylan Patel of SemiAnalysis reports power users defecting to Codex after “refusals for nonsensical reasons.” Both complaints are about access to the capability. Neither questions the capability.

My version of that moment is the one this guide opened with. Fable read my instruction files and started surfacing contradictions instead of executing them. Previous models followed my rules. This one evaluated them.

Subscribe now

5. Your Knowledge Layer Was Built for a Weaker Model

Fable flagged the first contradiction on its own, mid-task, before I’d read anyone’s tips. So I gave it the full job: read everything my agents follow and report what’s wrong.

That conclusion is consistent with voices inside Anthropic. Alex Albert’s launch tips name the same mechanism: instructions written for old models keep Fable behaving like those old models. Rework your skills and CLAUDE.md files. Let the model use its own judgment first.

5.1 What Fable found in my repo

My agents maintain those files, not me. I trusted Opus to keep them clean enough. Still, five finds:

• A hardcoded date telling the model what day it is. One strategy file contains “(today is 2026-05-24)“, written during a May session and never noticed again. Every session since has been told the wrong date by its own instructions.

• A rule documented with the pattern it bans. My writing system bans em dashes in published content. The file that documents the ban is written with em dashes. Instructions teach by example as much as by rule.

• Calibration constants that drifted. An X voice rule still gates on an audience under 50K followers. That number was true when the rule was written. It isn’t two months later (75K).

• Guardrails for failure modes the new model doesn’t have. Rules like “never delegate judgment-heavy work to cheaper models“ and complex self-check procedures exist because earlier models needed them. Each one now eats context and pulls the model toward old habits.

• The same rule stated in three files. Three maintenance surfaces, three chances to drift apart.

Some were plain mistakes. The rest were right for the model they were written for. That’s exactly the problem. The better your system was for the last model, the more it holds back this one.

5.2 Written by a weaker model

The pushback I got within hours of posting my first thoughts on X: if your files contradict each other, isn’t that just sloppy housekeeping?

Fair question, wrong model of the system.

This knowledge layer isn’t a config file a human writes once. It’s self-improving: agents file evidence as they work, turn evidence into working rules, and edit their own CLAUDE.md (the system from Three CLAUDE.md Blocks). 166 files, maintained partly by the things that read them.

In a system like that, contradictions aren’t carelessness. They’re drift, the same drift every wiki and every org’s process docs accumulate, except here it accumulates as fast as the agents write.

That creates the real trap: a knowledge layer written by a weaker model has a flaw no amount of review can fix. Every line an agent added passed review by the model that added it, by definition. A system maintained by model N tends to preserve the errors model N can’t see.

I review these files every day and didn’t catch it. Neither did Codex, which reviews my knowledge files as a second pair of eyes.

5.3 The audit prompt

So the first prompt I ran with Fable 5 wasn’t a task. It’s the prompt I’d now run before giving any new model real work, and it’s yours:

Read your own instruction files (CLAUDE.md, skills, rules, memory files) end to end.

1. Where do they contradict each other? Quote both sides.
2. Which rules exist to manage a weaker model: guardrails for failure
   modes you don't have, recipes for things you no longer need spelled
   out, hardcoded facts that have drifted? List them with file:line.
3. Which rules teach by bad example: documents that violate the
   patterns they prescribe?
4. What would you delete? What would you keep exactly as is, and why?

Don't fix anything yet. Report first. I decide what gets cut.

The audit is the model's judgment; the deletions are yours. What you do with the report, and how I turned mine into a repeatable migration workflow, is where we go next.

Behind the paywall:

• The migration workflow → the three-bucket rule classification (constraint, calibration, scaffolding) so you cut anchors without cutting your actual taste

• Objectives, not tasks → the /goal patterns that let Fable run long PM work unattended + 2 prompt templates

• How deep agents and workflows stack now → my depth-10 experiments, the 2.54x cost multiplier

• Delegating and escalating work with Fable → my CLAUDE.md snippet

• What doesn’t work (yet) → the honest list, so you spend your first week on the parts that do

• The week-one plan → day by day, copy-paste ready

Read more

Here’s what you might have missed:

• Introduction to AI PM: Neural Networks, Transformers, and LLMs

• From Weeks to Hours: How Claude Design Compresses Product Discovery

• Claude Code for PMs: The Beginner’s Guide

• Claude Code’s Limits Are Generous. The Problem Is Your Setup.

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

Consider subscribing or upgrading for the full experience.

Subscribe now

Last week, inside Claude Code, I gave Claude a product-discovery job and added one short keyword: ultracode. I expected a better answer. Instead, it wrote a short program, spun up a fleet of agents, and ran the work through that program.

113 agents spent 1.95M tokens. The JavaScript that coordinated them spent zero model tokens. That distinction matters: the model did the judgment, the code did the coordination.

What surprised me wasn’t that Claude wrote code. It was that the most important coordination moved outside the model’s context window.

That changes how much one PM can run.

We’ll cover:

• What a dynamic workflow is, and the token number that proves it

• How it compares to n8n

• Why it works: four reasons, and the three failure modes a harness fixes

• The six patterns worth knowing

• A worked product-discovery loop on 100 interviews, end to end

• How to build, run, and contain one, and when not to

We won’t cover:

• The Agent SDK internals

• Fancy terms to memorize

This is the operating model, not the API docs.

1. What a Dynamic Workflow Is

1.1 The mechanism: the orchestrator is code, not a model turn

A dynamic workflow is a short JavaScript program Claude writes on the fly to coordinate subagents. You trigger it with the ultracode keyword, or by asking Claude to use a workflow. It reads the job, writes a script, spawns the agents, and merges what they return.

When you fan out 20 agents, something decides what each does, collects results, and drops duplicates. The old way, that something was the model, and every decision was a paid turn. Now it's ordinary code: loops, filters, sorting. None of it calls a model, so the routing is free. The agents still cost tokens; the glue between them doesn't.

1.2 How it compares to n8n

If you run n8n, you've made half this move. n8n took the glue between your tools and put it in a graph. A dynamic workflow takes the glue between agents and puts it in code. Same instinct, one level up.

This isn't an n8n replacement. n8n asks: how do I connect tools I already know? A dynamic workflow asks: how do I let the agent build the procedure for this run?

You could already ask Claude to write code that coordinates agents with the Agent SDK, but those are embedded agents: the ones you build into your own app or product. A dynamic workflow coordinates workspace agents: the ones doing your actual work (coding, research, knowledge work) inside Claude Code. The SDK is for the agents you ship; dynamic workflows are for the agent you work with.

1.3 When a workflow beats a subagent

How do you know it’s time to stop prompting and start orchestrating?

Subagents already fan out and synthesize: Opus delegating to a fleet, one round, then a merge. So a single fan-out is not the reason to reach for a workflow. The reason is what happens after the fan-out, when the output of one stage decides the next.

A mental model:

• Use subagents when the job is one round of parallel judgment.

• Use a dynamic workflow when stage N’s output determines stage N+1: route, score, filter, loop, retry, generate, verify, build.

For PMs: subagents are the workers; the workflow is the operating procedure. The expensive resource (a model's reasoning) goes to each stage; the cheap resource (code) decides the order, which model tier runs each stage, and what carries forward.

2. Why Move the Orchestrator Off the Model

The reason to reach for a workflow isn't that it's more "advanced" than an agent. It's that it moves the fragile part out of the model's context. Order, routing, stopping, and model choice become code. The model still does the thinking; it no longer has to remember the plan, police its own laziness, grade its own work, or decide when the job is done.

The structure that does this got a name that caught on in 2026: a harness. I'd been making the same case since 2025, under a different one: orchestration over autonomy. The model gets the judgment; the structure around it gets everything else.

Four things follow:

• Determinism. Code owns the order, the routing, and the stop condition. They run the same way every time, instead of depending on whether the model feels done.

• Context isolation. Each agent gets a fresh, bounded job. The goal lives in the script, not in a window that compacts and drifts.

• No orchestration-token tax. The coordination layer isn’t another model conversation, so routing the fleet is free (§1.1).

• Model tiering. Bounded, repetitive stages run on a cheaper model. (Subagents can do this too; it’s a pro tip, not the differentiator.)

The first two are the point; the last two are why it’s cheap. You feel their absence as three specific failures, and I’ve hit all three.

2.1 Agentic laziness

Ask Claude to review all 50 items; it reviews 35, writes a confident summary, and declares it done. A workflow holds the 50 in a for loop and runs until the array is empty. Humans get tired and models drift; a loop just checks the same condition again.

2.2 Self-preferential bias

Ask Claude to grade its own work and it grades generously, especially in judge-or-verify tasks. A workflow makes the judge a separate agent, with separate context, sometimes a different model. Spawn several skeptics, require a majority. The bias doesn’t survive being split.

2.3 Goal drift

Over a long session the objective loses resolution; every compaction is lossy, and the “don’t touch auth” constraint can evaporate by turn 80. A workflow holds the goal in the script, outside the model’s drifting memory. Agents come and go with fresh context; the goal doesn’t drift because it was never in a context that compacts.

For PMs: you've seen all three: 70% delivered as 100%, a self-review an outsider would shred, a Friday build that forgot Monday's requirement. Name the step your agent keeps redoing. That's your first workflow.

3. The Six Patterns Worth Knowing

Once the orchestrator is code, six shapes recur. Learn the names; they're how you recognize what a task wants.

• Classify-and-act: one agent decides the task type; the script routes accordingly. Reach for it when: triaging inbound (bug vs feature vs noise), routing support tickets.

• Fan-out-and-synthesize: one agent per piece in parallel, then merge in code. Reach for it when: competitor teardown, customer-call synthesis, a market map.

• Adversarial verification: separate agents check the output against a rubric. Reach for it when: fact-checking a PRD against its sources, a second reviewer on a risky call.

• Generate-and-filter: many candidates, filtered and deduped, survivors kept. Reach for it when: naming, positioning lines, experiment ideas.

• Tournament: N agents attempt the task different ways; judges compare until one wins. Reach for it when: a strategy memo or a hard design with no single right approach.

• Loop-until-done: keep spawning until a stop condition (no findings, no errors, empty queue). Reach for it when: a backlog triage or an audit where you don’t know how much work there is.

For PMs, on your actual work:

• Synthesize customer interviews → one agent per transcript, merged into a themes-and-JTBD table. Every interview read, not the first 20 (the worked example below runs this on 100).

• Check 80 user stories against INVEST → a loop that runs until every story is checked, not until the model tires at 50.

• Pressure-test a PRD before the review → a separate agent red-teams it against your goal and surfaces the assumption you’d otherwise defend at launch.

You're not learning to code. You're learning which weekly PM jobs can become standing workflows: set the goal once, save the procedure as a skill, and let it run end to end.

Subscribe now

4. A Worked Example: A Product Discovery Loop on 100 Interviews

This is where a workflow earns its keep.

Here’s the pipeline I ran on 100 synthetic customer interviews (1-2 pages each).

Six stages, each feeding the next:

• Step 1: Extract → fan out one cheap-model agent per interview; each returns structured opportunities, personas, and verbatims. Bounded, repetitive work: Haiku or Sonnet, not Opus.

• Step 2: Canonicalize → one agent clusters the raw opportunities into a canonical set. The extractors invent a fresh label per interview, so the same need arrives under a dozen names; merging synonyms is judgment, so it’s a model, not code.

• Step 3: Opportunity score → code ranks each canonical opportunity by frequency × importance × (5 - satisfaction). No model runs the math.

• Step 4: Generate and triage → for the top-scoring opportunities, an agent generates several solution ideas; a separate judge then ranks each by ROI (impact vs build effort) and keeps the top 3 to build. ROI re-orders the list, so a cheap, high-impact need can take a build slot from one that scored higher.

• Step 5: Build → for the top 3 ideas by ROI, an agent uses the frontend-design skill to write a distinctive, clickable HTML prototype I can open.

• Step 6: Inspect and rerun → a smoke check flags any prototype that fails to render, or any extraction that came back low-confidence, and the workflow reruns just that stage. This is the real loop: the output of one stage decides whether an earlier stage runs again.

That second stage wasn't in my first prompt. I'd written "merge and dedupe" and assumed code could do it; the counts came back fragmented. So I added one line to the prompt, cluster synonyms to a canonical set before counting, and Claude rewrote the harness with a clustering agent in front of the scorer. Even the fix lived off the model.

This is how it runs:

I measured the run: 113 agents spent 1.95M tokens in 12.5 min. 3/3 prototypes built and verified. The JavaScript that routed, scored, gated, and looped spent zero model tokens.

That's the payoff. The rest is how you build it 👇

Read more

You write the plan, you share it, people nod. The assumption that sinks it never gets named until launch.

So I built a command that names it first.

Paste a roadmap, a PRD, or a one-line bet into Claude. You get back the riskiest assumptions, ranked by what would hurt most, what is most likely to be wrong, and what is cheapest to test this week.

The impolite questions, before the market asks them.

It shipped today in PM Skills 2.0, the free, MIT-licensed marketplace 12,000 of you have starred on GitHub.

This is the biggest update since the March launch:

• 68 skills

• 42 commands

• 9 plugins

• one new AI Shipping Kit

• one new red-team command for PRDs, roadmaps, and strategy

Subscribe now

1. What PM Skills Actually Is

Generic Claude gives you text. PM Skills gives you structure.

Ask a raw model to “prioritize this backlog” and you get a confident paragraph. Ask it with the prioritization-frameworks skill loaded and it runs the actual framework, with the trade-offs named and the math shown.

The difference is not the model. It is the judgment encoded in the skill.

Each skill turns a proven PM method into a reusable workflow: discovery, assumption mapping, prioritization, strategy, pricing, GTM, execution, analytics, and now AI shipping.

There are three pieces:

• Skills give Claude a method or framework. They load automatically when the work matches.

• Commands are slash workflows you trigger directly. /discover chains four skills: brainstorm ideas, identify assumptions, prioritize assumptions, and design experiments.

• Plugins group related skills and commands by PM domain. Installing the marketplace gives you all 9 at once in Cowork.

The full catalog lives in the GitHub README. For this release, two plugins changed.

• pm-execution was updated with one new skill, strategy-red-team, and one new command, /red-team-prd.

• pm-ai-shipping is new: two skills, five commands, and a workflow for turning an AI-built repo into something a human can review.

2. The New Command: /red-team-prd

This is the one to try first, because you can feel it in thirty seconds.

/pre-mortem imagines the plan already failed and narrates why. /red-team-prd does the opposite: it attacks the live assumptions now, while you can still change them, and hands you the cheapest test for each.

Here is what that looks like on a one-line bet:

It also tells you what is already well-reasoned and what it could not assess. A useful red team does not manufacture doubt to look smart. If the plan is strong, it should say so.

Five real kill-assumptions with tests beat twenty generic risks.

3. The New Plugin: The AI Shipping Kit

The other half of the job changed this year. PMs and founders are now accountable for code an AI wrote.

AI writes fast, but it leaves no written record of intent:

• what the system should do,

• who may do what,

• where the secrets live,

• which permissions are actually enforced,

• which rules are verified by tests.

The AI Shipping Kit restores that record.

The umbrella command, /ship-check, answers the question you actually have:

Is this safe to ship?

It:

• documents the system,

• audits the code against that documented intent,

• maps test coverage,

• and compiles a shipping packet a human can sign off on.

The gate is intended vs. implemented.

/ship-check looks for the places where the product promise and the repo disagree: the permission that is documented but never enforced, the scheduled-job endpoint anyone can call, the test that proves nothing about the workflow it claims to cover.

You do not need to be technical to run it.

You need to know what the system was supposed to do.

The kit has two skills:

• shipping-artifacts defines the docs that make an AI-built app reviewable: architecture, flows, permissions, variables, tests, and conditional docs for email, scheduled jobs, SEO, or automation.

• intended-vs-implemented audits the gap between documented intent and actual code, with evidence on both sides.

And five commands:

• /document-app creates the system documentation.

• /security-audit-static checks security against the documented intent.

• /performance-audit-static checks over-fetching, missing indexes, and caching.

• /derive-tests maps what is tested, what is proposed, and what is unverified.

• /ship-check runs the full sequence and compiles the shipping packet.

Subscribe now

4. How to Install It

The repo is the source of truth: https://github.com/phuryn/pm-skills

If you use Claude Cowork, install the whole marketplace:

1. Open Customize in the bottom-left corner.

2. Go to Browse plugins -> Personal -> +.

3. Select Add marketplace from GitHub.

4. Enter https://github.com/phuryn/pm-skills

All 9 plugins install at once. Enable those you need:

If you use Claude Code, add the marketplace:

claude plugin marketplace add phuryn/pm-skills

Then install the plugins you want. To install the full marketplace:

claude plugin install pm-product-discovery@pm-skills
claude plugin install pm-product-strategy@pm-skills
claude plugin install pm-execution@pm-skills
claude plugin install pm-market-research@pm-skills
claude plugin install pm-data-analytics@pm-skills
claude plugin install pm-go-to-market@pm-skills
claude plugin install pm-marketing-growth@pm-skills
claude plugin install pm-toolkit@pm-skills
claude plugin install pm-ai-shipping@pm-skills

If you only want the new and updated pieces from this release:

claude plugin install pm-execution@pm-skills
claude plugin install pm-ai-shipping@pm-skills

New to Claude Code? Start with the beginner’s guide, then the advanced guide when you want the power-user setup.

The commands flow into each other. A real week looks less like a feature list and more like one continuous thread:

• /discover a new idea,

• /write-prd the winner,

• /red-team-prd the PRD before the review,

• /ship-check once the code exists.

After any command finishes, it suggests the natural next one.

One more note: the skills are portable. The slash commands are Claude-specific, but the SKILL.md files follow the universal skill format and can be copied into tools like Codex CLI, Cursor, Gemini CLI, OpenCode, or Kiro.

The README has the exact copy instructions.

5. How It Composes With PM Brain

PM Skills gives Claude the method. PM Brain gives Claude your product context.

PM Brain is a markdown second brain for product managers: strategy, users, decisions, hypotheses, stakeholders, and recurring knowledge in plain files on your laptop.

Run them together and the frameworks stop being generic.

/red-team-prd can attack your plan using what PM Brain knows about your real constraints. /strategy can build on your actual positioning. /ship-check can review a repo against documented product intent instead of a blank canvas.

One supplies the rigor. The other supplies the context.

6. Start Here

If you have a plan you are not sure about, run:

/red-team-prd [your PRD, roadmap, or strategy]

If you have an AI-built app you are close to shipping, run:

/ship-check [repo or folder]

If you are starting from zero, run:

/discover [your product idea]

Everything is free and MIT-licensed. If it helps, star the repo so the next PM finds it.

AI does not fix weak product judgment.

It scales it.

PM Skills is where the judgment lives.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a great rest of the week,
Paweł

Resources

Get the marketplace (free):

• PM Skills on GitHub - 9 plugins, 68 skills, 42 commands, MIT-licensed.

• PM Brain - the markdown second brain that composes with it. MIT.

Go deeper (The Product Compass):

• Claude Cowork for PMs - agents without IDE, start here.

• Claude Code: the beginner’s guide - start here if you are new to IDE.

• Claude Code: the advanced guide - the power-user setup after you get the basics.

• Codex setup for PMs - wiring a second model alongside Claude. I've found it catches ~80% of my errors.

• Intent engineering for AI agents - lead with context, not instructions.

• I don’t review the code, I review the artifacts - the review method behind the AI Shipping Kit, plus the downloadable artifact prompt pack.

• Security and performance testing prompts - the worked teardowns the kit automates.

• Claude Code's Limits Are Generous. The Problem Is Your Setup - how I cut my Claude costs over 5.5x.

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session - critical concepts for building self-improving agentic systems.

• Vibe Coding vs. Vibe Engineering published in Sep, 2025 (in 2026, labeled “agentic engineering” by Andrej Karpathy)

If you are curious, a few things I’m shipping:

• claude-usage - Embed your Claude Code usage dashboard (token counts, costs, sessions, projects) directly inside VS Code.

• agentlift - Deploy agents to Claude Managed Agents, AWS Bedrock AgentCore, and Google. One folder, one definition, one command.

• Grok Build for VS Code - The only visual UI for Grok Build (non-CLI), 1,400 active installations. A bet in case Grok surprises us.

More than 800 tests and eval checks across the three repos, from unit tests to LLM judges, nearly all green. I’m a PM, not an engineer, and I barely read the code.

And this isn’t just me, or just indie builders shipping side projects. A Google PM described the shift from writing-first to building-first:

It’s not only Google.

Meta PMs now vibe-code prototypes and demo them straight to Zuckerberg, and the company added a prototyping round to its PM interview; LinkedIn replaced its APM program with an “Associate Product Builder” role gated on a live AI build. The prototype is becoming the PM’s first deliverable inside large companies, not a side-project trick.

So what did I review? The artifacts:

• the plan before it ran

• the decisions it encoded

• the strategy the agent reads every turn

• the docs that say what the thing does and why

It’s the same shift whether your surface is a repo, Claude Code, Cowork, or a chat window. Experimenting got cheaper than building agreement, and that reorders the work.

None of them started with a spec. Each started with a conversation, and what I kept was the artifacts.

What this post covers:

• What the artifact layer is, and why a PM reviews it instead of the code

• Why building now comes before agreement, not after

• Where your strategy has to live to actually steer the agent

• The boundaries that let you hand an agent real autonomy and walk away

• The AI Shipping Artifact Prompt Pack to download at the end

Subscribe now

What I Actually Ship Now

The product is the obvious artifact: the extension on the Marketplace, the tool people install. The one that decides whether the next change goes well is less obvious. It’s the knowledge layer.

Not the README or the changelog, every repo has those. The docs that hold the decisions: why this architecture, who it’s for, what we ruled out:

• In PM Brain that’s files like architecture.md and why-this-matters.md

• For accredia.io it was more than twenty docs, from database.md and security.md to a fuckups.md

• For a multi-agent app I built with my cohort, it was the agent contracts: what each agent takes in, what it returns, which tools it can touch, and how they hand off.

Keeping that layer true is a question of what to automate, and when:

• In claude-usage, git tags are generated from the CHANGELOG automatically: the changelog is the source of truth, the tag is a deterministic projection.

• In Grok I keep version bumps manual on purpose, because automating them there hasn’t earned its keep yet.

Seven things shipping this way taught me.

Lesson 1: Review Artifacts, Not Code

The question I get from PMs is “do I have to learn to code?” I don’t, and I don’t review the code, beyond the odd snippet.

That layer isn’t a side effect of the build. It’s a deliberate, human-and-agent-readable summary of the solution, so neither of us has to reverse-engineer the product from the source. It often duplicates what the code already says, and that’s the point: it’s far easier to consume.

It’s also what I check the code against. When I care whether the implementation matches the intent, whether the security model holds, whether performance is where it should be, I read the artifact, not the diff.

So when work comes back, I don’t read changes in the code. I read changes in the artifacts. I review across three modes, escalating only as far as the decision needs:

Cheapest mode first. A durable artifact is the receipt: it survives the context window, and it survives me. Only commit one when the alternative is losing the thread.

Here’s one from a build. I opened the session with a document, not a ticket: “See the research in plan-mode.md. Can we really implement that logic reliably on our side?”

The agent didn’t start writing code. It read the doc, ran a quick probe to test the doc’s core assumption against the real tool, and reported what it found. I signed off on the approach from that exchange, not from a single line of the implementation.

And this matters more on a team, not less: your teammates don’t carry your context in their heads, so the artifact layer is how a decision or a hard-won finding survives past the person who made it.

Subscribe now

Lesson 2: Build Before Building Agreement

The old motion was: write the PRD, get everyone to agree, then build. That order made sense when building was the expensive part. You spent weeks of engineering, so you spent days up front making sure it was the right thing.

That’s why I shipped two major releases in a day, and why none of these projects started with a spec. Two-week iterations start to feel dead in this mode. Not because planning is useless, but because the unit of learning changed: when a working version costs an afternoon, a sprint is too slow to be the main loop. You ship, watch, revise, and ship again before the old process would have turned the debate into tickets.

A prototype, even a rough one, collapses the ambiguity: the team sees what the customer clicks, where they hesitate, what they ignore, what they ask for next. Highly regulated industries aside, agreement around an untested doc is low-value at best: the idea changes the moment it touches reality. At worst it's harmful, because the team gets attached to a product that only existed in language.

Lesson 3: Put Strategy Where the Agent Works

I still write the strategy down:

• who it’s for

• what changes for them

• what I won’t build

• the trade-offs I’ll accept

• what would make the work a failure

What changed is where it lives and what it’s for. It doesn’t sit in a folder someone might open before a kickoff. It lives in the repo, a strategy.md the agent reads every time it acts.

If the strategy isn’t in its context, those decisions get made from whatever’s nearby: the last prompt, the surrounding code, a guessed convention, the model’s own confidence.

The repo becomes the product’s memory, too:

• experiments

• decisions

• evals

• screenshots

• release notes

• the constraints I hit

They accumulate there anyway. My job is to keep that context clear enough that the agent can use it. (The one thing I stopped writing is the spec, the user stories and acceptance criteria that told engineering exactly what to build. That part is cheap now; it falls out of the conversation.)

Your strategy is only doing work if it changes what the agent does next.

Share

Lesson 4: Cross-Examine Confident Answers

I asked Claude to bump the version and publish. It was confident: “Just run the publish command. CLAUDE.md says the publisher’s already authenticated.” I almost did it. Then I asked: “Are you sure? I’ve been publishing by hand through the Marketplace website.”

The confidence collapsed. That claim was from a past session I’d never verified, and the setup it promised had never happened. The command would have failed at the first step.

That one was harmless. A command fails in front of you, you fix it in a minute. The claims that bite are the confident ones you act on instead of run, where the failure is silent and lands downstream. Pushback is how you catch those before they cost you. The moment you ask “are you sure?” carries more weight than the next instruction you give.

But you can’t interrogate everything, or you become the bottleneck you were trying to remove. So I triage. I cross-examine the confident answers that are expensive to be wrong about:

• irreversible changes

• anything touching auth, billing, security, or the data model

• anything that becomes context future work depends on

• any claim that sounds too clean

The strongest version of pushback isn’t you, though. Your attention doesn’t scale. A second model gives you more review surface without funneling every hard question back through your head.

When I had the extension audited for bugs, the agent built a confident, elaborate theory and walked straight past a one-line bug in the same function: a failure was being reported as a success. Trust that, and it keeps building on a false "it worked": wrong analysis, maybe a destructive next step. Codex caught the one-liner Claude had talked itself past.

A second copy of the same model shares its blind spots. A different model, trained differently, fails differently. Self-review feels like diligence. Cross-review is. (I wrote up how I wire Codex alongside Claude separately. You can watch one play out in public: the cross-check narrowed a contributor’s over-broad fix to a single bad value, and he confirmed it.)

Lesson 5: Make Failures Teach the System

The best artifacts in my projects usually began as failures I didn’t want to debug twice.

The loop is the same every time: a failure surfaces, I find the smallest thing that would have caught it, a test, an eval, or a line of policy, and I make it permanent so the system can’t forget it.

The most load-bearing line in my CLAUDE.md is four words: “Don’t introduce abstractions speculatively.” It earned its place after an earlier project drowned in structure it didn’t need. A line copied off social media is a guess about a problem you might have; a line written after the third time something went wrong is policy. accredia.io keeps a fuckups.md in its docs; that’s where its rules come from.

Tests are the same idea in a different file. Early on, the model offered a 27-test suite and I took it, but the next bug I hit wasn’t in any of the 27, it was a sequencing problem they tested around. So now, when a real bug shows up, I ask: “What’s the smallest test that would have caught this?” and add that one.

The claude-usage triage routine mechanizes it: on every fix it adds the test, then reverts the fix to confirm the test fails without it. A green suite proves the past; manual smoke probes the future.

Evals are the same instinct for AI that’s in the product: read the traces, name what’s failing, then turn each failure into a test, an LLM judge, or a new line in CLAUDE.md. PM Brain’s judges are each named after a real failure (decision_quality, evidence_hierarchy_respected), never from a spec up front. (I go deeper in evaluating AI products through error analysis.)

Subscribe now

Lesson 6: Point Every Agent at One Source of Truth

I had three coding agents open during this build: Claude Code in the terminal, a Grok tab in VS Code, and Codex through a separate skill. Same repo, same files, three independent conversations. Without a shared source of truth, they’d have proposed three different architectures, and I’d have spent the build arbitrating instead of building.

So I keep one master doc: CLAUDE.md, with the project, the conventions, and the decisions already made. The other agents don’t read it by default, so each gets a tiny AGENTS.md whose only job is to point them at it. It duplicates nothing; it just redirects.

In claude-usage I flipped the direction: there AGENTS.md holds the guidance and CLAUDE.md is one line, @AGENTS.md, that imports it. Either way works. One source, everything points at it.

It isn’t only CLAUDE.md, either. The source of truth is the whole working-context layer, the docs, rules, skills, and hooks each agent can reach, and I keep that synced too. Each agent can have its own entrypoint; it shouldn’t have its own reality. (Full setup in Codex Setup for PMs.)

Lesson 7: Grant Autonomy, Enforce Boundaries

Early on, I babysat every run. I watched the model think, approved each step, sat at the screen the whole time. That doesn’t scale across the number of things I’m trying to ship.

The shift was setting a goal, giving the agent room to pursue it, and walking away. The clearest example runs every week without me. The goal: go through every open pull request and feature request on claude-usage, merge the clear bug-fixes, mark the duplicates, push out-of-scope features to a Discussion, and report back only what couldn’t be resolved. It runs headless, on a schedule. I read the summary later, often from my phone.

Autonomy that wide only works with two kinds of limit, and the difference is the whole game:

Steering prompts are soft: a one-line reminder, or a repeatable procedure like the gate rules in my content system. Either way, under pressure the model can talk itself out of one.

Hard boundaries are enforced where the model gets no vote. In the triage routine:

• nothing closes unless the second model writes a sign-off file with an exact approval phrase

• it won’t auto-merge anything touching auth, secrets, or more than 200 lines

• it never pushes to main

Those aren’t requests. They’re mechanical gates.

The strongest version of a hard boundary is the tool surface itself. In the Grok extension, plan mode isn’t a polite “please don’t edit files yet.” The extension gates the actual file-write and terminal calls, so while a plan is pending the model physically cannot touch the disk.

Same idea as a Claude Code hook or a tool allowlist: if a limit has to hold, it lives in code, not in a sentence the model can reinterpret. PM Brain enforces a different limit the same way: a hook fires after every file write and blocks the agent from saving a brain file with an untagged claim. No clean save, no write.

The same logic runs at the shipping boundary. On claude-usage, no pull request merges to main on a red test suite. I didn’t know how to wire that up, so I asked Claude to set the branch protection for me. The agent can be confident and a contributor can be in a hurry; the merge button stays disabled until the tests pass.

PM Brain’s /review edits knowledge files on its own, but it’s hard-stopped from changing a decision’s status; that judgment is mine. Wide lane, real walls.

What Still Needs Human Judgment

Here’s what the system still can’t decide for me.

• Models over-rate their own findings. In that audit, the agent tagged three findings “high severity.” Checked against the actual code, all three were medium or low. The model is good at producing candidates. Deciding what’s actually serious is still mine.

• A second model helps; it isn’t magic. Two models from the same family share blind spots. Claude and GPT diverge enough to be worth pairing, but neither makes the load-bearing check stop being yours.

• Taste regressions still need eyes. No agent caught the copy button overlapping the header buttons. I did, on a manual pass. Design judgment isn’t in the test suite.

• The workaround becomes part of what you ship. Grok’s CLI returned unreliable tool results, so every session in the extension opens with a hidden primer: “Do not trust the tool result.” That scar tissue is product judgment too.

So What Do PMs Ship Now?

Across all of it, the extension, the knowledge system, the premium section behind this newsletter, the pattern held.

None of it shipped because I wrote a better spec, and none of it shipped because I read the code. It shipped because the conversation was good, and because I kept the few artifacts that turned out to be load-bearing: the strategy, the decisions, the constraints, the CLAUDE.md the agent actually reads.

PM Brain made it obvious. The brain it scaffolds is 44 markdown files around a single CLAUDE.md, and that structure emerged from use, not from a document I wrote first.

The AI Shipping Artifact Checklist

If the artifact layer is what you actually ship, here’s the starting set. Organized by purpose, not by stack, because the project changes but the knowledge-layer needs don’t. Steal the list; name the files whatever fits your repo.

None of these is a spec. Each is a place the decisions live, so you and the agents can read them instead of reverse-engineering the code. You don't have to hand-write them, either.

The AI Shipping Artifact Prompt Pack

One download, two kinds of thing, both built around the artifact layer above:

• The artifact prompts: seventeen of them, one per kind of file and risk, from strategy to workflow maps to cross-model review. Point an agent at your repo, run a prompt, review the doc it writes. They generate the layer; they aren’t the layer.

• The audit commands: a static security audit and a performance twin, for code you didn’t write. The security one, /security-audit-static, traces untrusted input to the places it could do real damage, then refutes its own findings before reporting. I pointed it at Langfuse, a leading LLM engineering platform, and it surfaced a real weakness in how provider connections were fetched. The hardening fix merged, 964 lines added, 334 removed.

Some of the 20+ issues I’ve since responsibly disclosed to public-repo security teams (Langfuse at the top):

Get the pack below: 👇

Read more

Codex grew from about 200K to roughly 4M weekly active users in four months. Claude Code crossed 2M in early March. If you opened this post, you're probably one of those 2M. The other 4M are on a tool you haven't tried.

And it's not just a developer tool anymore. If VS Code has felt like a wall, the Codex app is a chat window with a file tree, visual diffs, and long-running sessions. PMs who've avoided code repos no longer have to.

ChatGPT Plus is $20/month and includes Codex. The setup takes about five minutes. This guide is the walkthrough.

By the end of this guide, you’ll have:

• Codex app installed and pointed at your repo

• AGENTS.md bridged to CLAUDE.md so both runtimes share one source of truth

• Plugins installed for the apps you use, with project skills mirrored if you build with AI

• MCPs running in both runtimes, with a one-shot prompt to do the import

• Claude Code able to call Codex as a peer for review

• A plan for working from your phone (cloud tasks vs. remote control)

Full Cowork / Claude Code / Codex comparison is at the bottom. First, the setup.

Subscribe now

1. Why Add Codex as a PM

Five reasons I added Codex, in order of how often they show up in my work:

• A way into a repo without VS Code. If the IDE has felt like a wall, the Codex app (desktop) is a chat window with a file tree, visual diffs, and long-running chat sessions. No commands to learn, no extensions to wire. You can even edit files by leaving comments for Codex. Cowork is chat-first; no tree, no diffs.

• Manual Compact. You decide when to compress the session instead of waiting for the model to hit the wall. In Codex, type c, then /com, and choose Compact when it appears. Claude Code has /compact in the CLI. Cowork does not have an equivalent manual reset. This matters for your budget: Claude Code’s Limits Are Generous. The Problem Is Your Setup.

• An extra perspective. When I want a second pair of eyes on a prompt, or a piece of code, I hand it to the runtime that didn’t write it. Different model, different misses.

• Image generation in the bundle. The ChatGPT subscription that Codex ships with includes image generation. Claude doesn’t cover that workflow.

• Runs next to Claude Code on the same repo. Same files, same skills, same MCPs. Switch runtimes without rebuilding your setup.

Subscribe now

2. Install Codex (Desktop App and VS Code Extension)

You'll install two things. Codex app (desktop) is the chat workspace where long sessions and Compact live. Codex for VS Code is the editor extension that lets you call Codex in the same window as Claude Code.

Both share one OpenAI login, both work on the same repo, and you'll use both for different jobs.

Codex app (desktop)

Download Codex app from OpenAI. Sign in with the ChatGPT account that has Plus, Pro, or Business. Codex is bundled with all three.

The first prompt asks you to migrate your VS Code settings. I skip it. Not because it’s hard. Because you should know what’s being imported before you click yes. You can always migrate later from Settings or by asking Codex for help.

Open the same project folder you already use with Claude. The file tree loads on the right. Visual diffs appear in the same panel.

Codex for VS Code

Install the Codex extension from the VS Code marketplace and sign in with the same OpenAI account.

If you already use the Claude Code extension in VS Code, both extensions will show up in the activity bar. You can switch between them by tab.

Why both surfaces? The Codex app is for long chat sessions and Compact. Codex for VS Code is for editing the repo, including dot folders (.agents, .codex) that the app’s file picker hides - full dev experience.

Subscribe now

3. Teach Codex Your Repo: AGENTS.md to CLAUDE.md

Codex looks for AGENTS.md at the repo root. Claude Code looks for CLAUDE.md. If you maintain both as separate sources of truth, they drift.

The fix is a one-file bridge. AGENTS.md is a short pointer. CLAUDE.md stays the canonical document. Codex reads AGENTS.md, sees the pointer, follows it.

Drop this at the repo root as AGENTS.md:

# AGENTS.md

This repository keeps its canonical agent instructions in [CLAUDE.md](./CLAUDE.md).

When operating in this repo:

1. Read and follow `CLAUDE.md` as the source of truth.
2. Treat references to "Claude Code" as applying to Codex when you are the acting agent.
3. Do not duplicate `CLAUDE.md` content here. Update `CLAUDE.md` instead.

One file. One source of truth. Both runtimes follow it.

AGENTS.md is the bridge. CLAUDE.md is the long part. The structure I use:

1. Communication: How the agent should talk, what content it should produce.

2. [For personal work] About me: Role, audience, social media handles

3. [For product work] Strategy: Market segments, value propositions, tradeoffs.

4. Project structure: Where things live, architecture, conventions.

5. Workflow: How we do things (reviewing, shipping). Not a procedure manual. The rules of engagement.

6. Progressive disclosure: Links to deeper files (strategy.md, knowledge/INDEX.md, whatever you’ve built) that load on-demand, not on every session.

Each section earns its place when something would otherwise have to be re-explained per session. CLAUDE.md isn’t documentation. It’s the agent’s memory of how you work.

Progressive disclosure matters because context isn’t free. Don’t dump 500 lines of text into CLAUDE.md if 100 of it only matters for one workflow. Keep the core file lean. Link out to the rest.

4. Configure and Share Skills

If you haven’t used skills before, think of them as reusable instruction bundles. A SKILL.md file tells the runtime when to fire and what to do.

Two ways to configure them in Codex.

Start with user skills. The Codex app ships with a Plugins panel. One click installs Gmail, Linear, Jira, Slack, and others. You get the app’s connection and its skills together.

With Plugins installed, Codex reads your CLAUDE.md and talks to the apps you use daily.

That’s the minimum viable Codex setup for a PM.

The next step is making Codex and Claude Code behave like one operating system: curated skills, project skills synced between runtimes, mirrored MCPs, and a repeatable review loop.

Read more

Research preview. The architecture has months of dogfooding behind it on my content work. The product as installed by real PMs in real organizations is days old. The eval suite is the floor; your install feedback is how it gets better. Monday May 26, I'm running a live workshop session for paid subscribers, and there's a dedicated #pm-brain Slack channel for 1:1 install help. Details in §11.

You manage one product. Your context lives in five places: Notion, Linear, Slack, your dashboards, and your head.

You ship a feature. Six weeks later, nobody remembers why you killed the other option. The customer interview that should have informed the call is buried in a doc you forgot to link. The stakeholder who pushed back has a new concern, and the old one is gone.

I built a second brain for it.

Folder of markdown files in a git repo. A small operating manual (CLAUDE.md) tells Claude how to use them. The agent reads them before answering, writes to them after, sweeps them weekly.

No vector database. No embeddings. No cloud. No auto-tagging. Everything is grep-able. You can open the entire brain in any editor.

It's also not an agent memory system. Those embed everything you feed them so the agent can recall it later. PM Brain does the opposite. You write down only what matters, in markdown you can read, and the agent reads what you wrote. The point isn't agent recall. It's PM judgment with an audit trail.

A PM Brain doesn’t store everything. It promotes only what’s recurring, decision-relevant, or strategy-relevant. Everything else stays in working memory until it earns its way into the durable layer.

This post is the long version. The short version is in the README. The shortest version: open Claude Code in an empty folder, run /pm-brain, answer a five-batch interview, and you have a working brain in 10 minutes.

What You’ll Learn

• Why your PM context decays at month three, and where the trail goes

• The five failure modes that kill most AI memory systems, and the five structural choices that answer them

• A week with PM Brain, told as Lena’s first five days on a real account

• The architecture: five knowledge areas, three lifecycle areas, one CLAUDE.md

• Provenance, the unique technical idea, and why it carries more weight than people expect

• The six commands you’ll actually use

• How to install it today, and what to do in week one

1. Why This Exists

Most AI memory systems fail by month three. The same five failure modes show up across vector-DB memory, RAG over your docs, “AI second brain” apps, and most agent-memory frameworks:

1. Accumulate, never synthesize. Every interview gets stored. Nothing compresses. The system becomes a landfill.

2. Flatten contradictions into consensus. Three interviews say three things, summarized into one bland insight. The disagreement was the signal.

3. Drift silently from strategy. Two months of decisions point one way. The strategy doc points another. Nobody surfaces the tension.

4. Lose decision context. Why did we ship X? What were the alternatives? Most systems store the decision and lose the reasoning.

5. Overload context. The agent loads too much, gets confused, generates shallow output.

PM Brain is structured around five corresponding design choices, each one targeting a specific failure:

1. Epistemic boundaries. Every claim is tagged: observation, interpretation, hypothesis, assumption, decision. A Slack comment is not automatically truth.

2. A maintenance model that runs. Weekly sweep. Stale evidence flagged, recurring patterns compressed, contradictions preserved.

3. Flag, never gate. The system surfaces. The PM decides. The moment it becomes a blocker, it dies.

4. Inspectable, not opaque. Markdown, repo-native, editable, version-controllable. Trust is the bottleneck.

5. Resists complexity creep. No taxonomies, no agent swarms, no graph ontologies. Opinionated and lightweight.

Full mapping with the architecture choices behind each fix: docs/why-this-matters.md.

Subscribe now

2. A Week With PM Brain: Lena’s First Five Days

The fastest way to see what PM Brain does is to watch someone use it. This is a short story. The character is invented, the artifacts are real-shaped, the team and the tool are not. The full version lives in docs/walkthrough.md.

Lena Vasquez just took over PM for a B2B project-collaboration tool called Mosaic. The previous PM left a Notion workspace, a Jira project, and a 3-month-old Miro discovery board.

🚀 Monday: onboarding

Lena plugs in the Notion, Jira, and Miro app connectors, then runs /pm-brain. The skill enters migration mode, runs a five-batch interview (about 10 minutes), then reads through the three tools.

Forty-five minutes later: a folder of markdown files, an INDEX.md, and a short onboarding report. Buried in it:

Tension surfaced. The strategy doc says the north-star is activation: 60% of new accounts invite a teammate by day 3. But of 47 Jira tickets shipped in Q1 and Q2, 38 are tagged “enterprise permissions” or “admin tooling.” Only 4 touch the activation funnel.

A new PM usually catches this in week three, after they’ve already built plans on top of the official story. Lena has it on day one because the brain cross-checked two folders humans tend to read separately.

🎧 Tuesday: a discovery call

Lena has a 45-minute call with Talia Brennan, Head of Operations at Northridge Construction. Quiet user, seat count plateaued, no complaints. After the call: /ingest northridge-talia-transcript.md.

Four things happen in parallel:

1. The transcript copies to source/interviews/.... Read-only. Audit anchor.

2. A synthesis note lands in ingestion/interviews/... with observations tagged by speaker and date.

3. The brain tells Lena that two stakeholders flagged the same invite-link friction back in March, that there’s a candidate hypothesis the previous PM never tested, and that the Miro discovery board has a “magic-link onboarding?” sticky from January, never explored.

4. Talia’s observation lands as a new evidence row on the invite-link hypothesis. It promotes from candidate to proposed. Three independent observations now.

One call. The weight of three.

📣 Wednesday: the loud stakeholder

Slack lights up. Rahul Pillai (marketing): “We need to ship dark mode this quarter. Every demo asks for it. It’s killing conversion.”

Loud, recent, plausible. A less-confident PM might tell engineering to start scoping.

Lena types into Claude: “Rahul just messaged about dark mode. Capture as verbal stakeholder claim, flag any conflict with documented evidence.”

The brain tags the claim (stakeholder-verbal, rahul-pillai, 2026-05-20). Then it surfaces what’s documented:

• Q1 close-loss review: 27 demos analyzed. Dark mode flagged in 2 as a wishlist item. Zero blockers.

• Cascadia Health interview, 2026-03-15: buyer named integrations and admin controls. Not dark mode.

• Brillstone interview, 2026-04-18: same.

• Q2 strategy doc: activation north-star, not feature parity.

The brain doesn’t argue with Rahul. It puts his verbal claim next to 27 sales calls, two customer interviews, and the team’s stated strategy, each wearing its actual provenance.

Lena replies: “Want to dig into this. Friday.” She has the documented case ready and a productive conversation booked.

👨‍🏭 Thursday: engineering proposes an alternative

1:1 with Mateus Okafor (engineering lead): “What if we ran a 1-week spike on magic-invite-links? If it works, we save four weeks of UI.”

Lena adds a line. The brain records the verbal, files it as a solution option on the invite-link hypothesis, findable next to Talia’s evidence and the Miro sticky from January. The suggestion doesn’t die in Slack scrollback.

🧘‍♀️ Friday: /review, then Monday’s prep is done

Lena runs /review. One page:

This week

• Strategy gap (still open): flagged Monday, not raised yet.

• Invite-link hypothesis: candidate → proposed. Three observations.

• Dark mode tension (Rahul): verbal claim captured, flagged against documented evidence. Friday meeting is your action.

• Magic-invite-links spike (Mateus): solution option logged.

Drifting

• enterprise-permissions-v2: no new evidence in 47 days. Revive, demote, or archive?

For your Monday strategy meeting

1. Open with the strategy-vs-shipped-work gap. Activation-first or enterprise-first? One is wrong.

2. Bring the invite-link hypothesis forward. Three observations + one engineering alternative. Ask for a go/no-go.

3. Park dark mode until Friday’s meeting with Rahul.

Lena reads this in five minutes. Monday’s prep is done.

What Lena got, in five lines:

• Monday: a real question to bring into your first strategy meeting, on day one

• Tuesday: one call that landed with the weight of three

• Wednesday: documented evidence ready when a loud voice contradicted it

• Thursday: an engineering suggestion that didn’t die in Slack

• Friday: a one-page summary that made Monday’s meeting easy

None of this is automation. It’s the brain doing the small, boring work of cross-referencing what she already knew, so the judgment work, which is her job, gets easier.

3. The Architecture

Five knowledge areas, three lifecycle areas, four ingestion modes, one maintenance loop.

Plus source/ (immutable copies of original artifacts), a maintenance log, and a docs folder.

Evidence flows in one direction. It fans out at the durable layer. The same artifact updates multiple destinations in parallel. Talia’s 45-minute interview touched six files: one source copy, one ingestion record, one insight promoted to knowledge/users/, one hypothesis strengthened, one stakeholder touchpoint logged, and a candidate solution option logged on the hypothesis.

When a hypothesis is confirmed, it gets promoted and a decision record is auto-drafted (status: pending, waiting for your sign-off). When a decision’s reversal condition triggers, the weekly sweep surfaces it.

Most systems mash hypotheses and decisions together. They become useless.

Subscribe now

4. Provenance: Every Claim Wears a Tag

This is the load-bearing technical idea.

Every claim in hypotheses/, decisions/, and knowledge/users/insights.md carries a small tag, a provenance marker, that says where it came from.

The tags carry an implicit hierarchy: documented decisions outweigh documented research, which outweighs verbal claims, which outweighs PM intuition. The brain leans on that hierarchy when evidence conflicts. The leaning is in plain text. You can override it.

The brain enforces the vocabulary, not the workflow. PMs have intuitions. They hear things off-the-record from execs. They inherit claims with no clear pedigree. Those are legitimate inputs. The tag just makes them wear their actual provenance instead of laundering them through a fake ingestion/ record.

Three months later your CTO asks: “Why did we kill real-time alerts?” You open the decision file. Every evidence row carries a tag. Path-typed tags walk in two clicks to the synthesis, then to the raw transcript. Non-path tags tell you honestly that no artifact exists. Both are auditable. Only a missing tag is a bug.

5. The Six Commands

/ingest is the workhorse. /plan is where the system earns its keep. A new objective lands (”reduce onboarding drop-off 20% in Q3”) and the brain loads strategy, current metrics, user insights, active hypotheses, past decisions, stakeholder constraints, then drafts the six blocks.

That output is the difference between “another second brain” and a system that does product work with you.

6. The Maintenance Sweep

Memory systems rot in predictable ways. The weekly sweep is the forcing function that catches those failure modes before they compound. Skip /review for a month and the brain becomes a graveyard. Run it weekly and the system pays you back every Friday.

Eight failure modes; six checks. Dated report in maintenance/log/:

1. Stale knowledge audit. Files not updated in 6+ weeks. Still true? Archive?

2. Stale evidence flagging. Market intel past 30–60 days, interviews past 90, stakeholder assumptions past 30, strategy assumptions past quarterly. Flags; doesn’t auto-decay confidence. You decide what to refresh.

3. Hypothesis and decision hygiene. Active hypotheses with no evidence in 30+ days. Promoted hypotheses without a corresponding decision (drafts one). Decisions whose reversal condition triggered. Pending decisions older than 14 days with blocker impact (decision debt).

4. Stakeholder cadence and strategy tensions. High-influence stakeholders not touched in 3+ weeks. Recent decisions or signals diverging from strategy. Surfaced as tensions, not as drift to fix.

5. Knowledge synthesis (compression). The highest-leverage step. Identifies recurring patterns AND recurring contradictions. Preserves minority signals: the dissenting interview, the contrarian metric, the off-pattern stakeholder concern. Compression is additive, never destructive.

6. Archival sweep. Shipped features inactive 90+ days. Resolved hypotheses. Closed asks. Before archiving anything, extracts durable lessons.

Twenty minutes Friday afternoon. Set a recurring calendar reminder. Without it, the brain rots.

7. Will This Stay Healthy After a Year?

Yes. The layer the agent loads by default (your durable knowledge of strategy, product, users, market) grows logarithmically by design. The raw layer grows linearly with your activity but stays cold unless something cites it.

Default loads target the durable + active layers. Brain age doesn’t change what routine commands read.

The architectural payoff: plain markdown in a git repo is forward-compatible with every future Claude, every future Cursor, every future agent. The format doesn’t bind to today’s tooling. Context windows expand; your brain stays the same shape.

Longer version with the realistic envelope numbers (~50-100 interviews/year, 10-20 active hypotheses, 10-30 stakeholders) and the four on-demand triggers that pull old material into context: docs/scaling.md.

8. Does It Actually Work? The Test Scoreboard

PM Brain is new. The architecture isn’t. I’ve been running the same pattern (operating manual, tags, hypotheses, decisions, weekly maintenance sweep) on my content work for months.

PM Brain is that architecture adapted to PM-specific schemas, validated against 17 scenarios I designed from PM situations I’ve shipped through, with synthetic data generated across persona, stage, and risk dimensions.

404 of 406 individual checks pass (≈99.5%) on Sonnet 4.6.

The split:

• Structural checks: 329 / 329 (100%). Files exist where they should. Links resolve. Evidence rows carry valid provenance tags. Decision schemas are valid. Hypothesis statuses match the evidence claims.

• LLM-judge content checks: 75 / 77 (≈97%). Rubrics evaluating whether the brain surfaced the right contradictions, drafted the right decisions, asked the right questions.

Each scenario is multi-turn. The harness spins up a fresh brain in a temp directory, replays the inputs through claude -p, runs structural assertions after every turn, and runs LLM-judge rubrics on substance at the end. Full breakdown and snapshots in tests/RESULTS.md.

The point isn’t 99.5%. Most “AI memory” projects don’t have an eval suite at all. When the skill changes, the suite tells you whether it got better or worse on real-shaped PM situations, with snapshots you can diff.

9. What It Isn't

A few notes the grid doesn’t cover:

• The ad-hoc inbox tempts laziness. “I’ll route this later.” No. Every ad-hoc item gets resolved in the same session. The folder is a sorting bench. The moment it becomes a backlog, it becomes a graveyard.

• Memory promotion requires judgment. The agent proposes what to promote. The call is yours. Rubber-stamp everything and the durable layer fills with noise. Reject everything and the system never learns.

• Stakeholder files feel awkward at first. Writing down what your manager cares about, in a file, in your git repo, can feel like treating people as objects. The reframe that worked for me: this isn’t about them, it’s about your continuity. You forget. The file remembers.

10. How to Start

Install & migrate

Two stages:

• Skill is global; brains are per-product. One shell command installs the skill (macOS / Linux / WSL / Git Bash, or Windows PowerShell).

• Then in any folder, run claude and /pm-brain.

The skill auto-detects what’s in the directory:

• Empty folder = greenfield.

• Folder with existing PM artifacts (Notion exports, meeting notes, Jira CSV) = migration.

Either way, a five-batch interview captures your context. The scaffold drops in. The CLAUDE.md operating manual lands at the brain root. The brain commits locally. Never pushes.

Install commands, requirements, and troubleshooting: github.com/phuryn/pm-brain.

Next: Don’t backfill old artifacts retroactively

Migration handles your current state. Don’t backfill old artifacts retroactively. Two different things:

• Migration mode, recommended: When you point /pm-brain at a folder with your active strategy doc, your in-flight hypotheses, your recent decisions, and your current stakeholder list, the skill reads them, organizes them, and produces a short report on what it found. That’s the goal. Let migration absorb your current organized PM artifacts.

• Backfilling everything, the trap: The temptation is to spend a weekend manually feeding 200 old interview transcripts, six months of Slack threads, and every meeting note you’ve ever taken through /ingest. Don’t. If a six-month-old interview matters, it’ll come up through current work and you’ll ingest it then, with the context to know why it matters. Forcing stale artifacts in now wastes a weekend and clogs the durable layer with stuff the agent has no context to promote properly.

Week 1

The system dies if these three habits don’t take hold in week one. Do them in order, in the first seven days:

1. Ingest one real artifact today. Paste your most recent customer interview, meeting notes, or competitor screenshot. Watch where it lands in ingestion/, then which durable areas it updates. This is how you learn what the system does.

2. Prep your next 1:1. Before your next conversation with your highest-friction stakeholder, run /prep . Let the agent surface what to ask. The first real value is here, not in the scaffold.

3. Run /review Friday. Set a recurring calendar reminder. Twenty minutes Friday afternoon. Without it, the brain rots.

That’s week one. Don’t add anything else.

Week 2

Ingest two more interviews. Log one decision. Add one feature file for your most active feature. Open knowledge/strategy.md and fill in the Non-goals section if the interview didn’t capture it.

Week 3

Second /review. Now you can compare two reports. Patterns start showing up: recurring contradictions, drifting strategy, hypotheses with no evidence. This is when the system starts paying off.

Week 4+

It compounds. Every meeting note, every market signal, every decision feeds the same loop. The brain learns the shape of your product as you work.

The goal isn’t a complete brain. The goal is a brain that compounds over time.

11. A Research Preview, with Help

PM Brain is a research preview. The architecture has months of dogfooding behind it on my content work; the product as installed by real PMs is new. I want to learn what breaks in real organizations, in the first week of use.

Three things to make adoption easier:

• Live workshop session, Monday May 25 May 26, for paid subscribers. I’ll walk through install, migration, and the first week of usage live, then take questions. See: https://go.productcompass.pm/premium

• Dedicated #pm-brain Slack channel for 1:1 install help (paid members). Office Hours members get the channel. I’m in there for install pain, first-week confusion, and the awkward moments where the system feels wrong but you can’t articulate why. Those are the highest-signal reports.

• Public issues. github.com/phuryn/pm-brain/issues. Install bugs, feature requests, scenarios you want the eval suite to cover. Anyone can open one without a Substack subscription.

Subscribe now

If you’re in a real product role and the system might fit your workflow, your install feedback in week one is what makes the next version better.

12. Closing

Most product organizations repeatedly lose the same things: failed bets, abandoned assumptions, historical reasoning, unresolved tensions. The PM job is partly to remember these. The PM job is impossible when your context lives in five different places and none of them talk to each other.

One repo. One operating manual. An agent that reads it.

The brain isn’t a notes app you fill in. It’s a folder of plain-text files that grow with the work, traceable back to the source on every line, swept clean every Friday, free for anyone to use, and inspectable by anyone you trust.

P.S. The repo is at github.com/phuryn/pm-brain.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a great rest of the week, Paweł

Resources

The PM Brain OS

• The repo. github.com/phuryn/pm-brain. Skill, example brain, docs, tests, all MIT licensed.

• The walkthrough. Lena’s first five days, the long version of Section 2.

• Why this matters. Five failure modes that kill most AI memory systems, and the five structural choices that answer them.

• The architecture doc. Two design decisions and one operating loop.

• Scaling. How the brain stays healthy as it grows, growth shapes, compression mechanisms, realistic envelope numbers.

• How it works. The technical version, one ingestion, six files touched, end to end.

• Prior art. What PM Brain borrows from Zettelkasten / RAG / CLAUDE.md patterns, and what it rejects.

• Glossary. Every term in plain English.

• Tests scoreboard. 404 / 406 checks, per-scenario snapshots, two residual failures called out honestly.

• Issues. github.com/phuryn/pm-brain/issues. Install bugs, scenarios you want covered, feature requests. Open one.

Composing with PM skills

PM Skills (11K+ stars). github.com/phuryn/pm-skills. PM Brain is the memory layer; PM Skills is the workflow layer. They compose. A JTBD PM Skill extracts jobs from an interview using the proper framework; PM Brain makes sure that job updates the right user insight, hypothesis, stakeholder note, and decision record. The skill is how to do the work once. The brain is what we know across all the times we did it.

Related newsletter posts

• Claude Code for PMs: The Beginner’s Guide (May 12). Everything to start.

• Claude Code Guide (Mar 8). Full version. The tool this runs on.

• Self-improving AI systems (Mar 16). The parent pattern for compounding agents.

• Intent Engineering Framework (Jan 13). The agent design language behind CLAUDE.md.

• What Is Product Discovery? The Ultimate Guide (updated 2025). Critical for PMs.

When looking for a job, expect:

• “How do you use AI/Claude in your day-to-day?”

• Vibe coding / prototype rounds: from PRD to evals

• Portfolio/case studies: Show agents/prototypes built with AI

• Questions focused on AI product sense + execution with agents

Even people like Garry Tan (Y Combinator) went back to "coding" and ships a custom brain for agents after work hours:

In the past, we’ve discussed many aspects:

• The Guide to Claude Code for PMs

• What I Learned Building a Self-Improving Agentic System with Claude

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• Your .claude/ Folder Is a Production Agent

• The Ultimate Guide to Claude Opus 4.7

• Claude Code's Limits Are Generous. The Problem Is Your Setup.

The first Guide above assumes you’ve used Cowork. Talking to the community, I realized many PMs haven’t, and they need a zero-to-one path.

This article has everything you need to start:

1. How to install Claude Code step-by-step

2. A ready-to-use Claude Code solution template

3. How to configure MCP servers in Claude Code step-by-step

4. How to use and create skills in Claude Code step-by-step

5. How to use Claude Code with free frontier models

Subscribe now

1. How to Install Claude Code Step-By-Step

This combines Claude Code with the recommended interface, Claude Code extension in VS Code.

Step 1: Install Visual Studio Code for MacOS or Windows

Step 2: Launch VS Code, click “Extensions,” and install “Claude Code for VS Code”

Step 3: Log in with Claude.ai Subscription after typing “/login” in the Claude window. There are two interfaces, it’s easy to get confused:

• Skip this one: Claude Code in Terminal - opens at the center

• Use by default: Claude Code Extension for VS Code - opens in the secondary side bar on the right

Note: On the right side in the video you can see two tabs:

• [Codex] - OpenAI extension I installed earlier

• [Claude Code] - that’s our Claude Code extension

Sometimes you may also see “Chat” - it’s a Microsoft solution. Ignore it.

2. A Ready-To-Use Claude Code Solution Template

This knowledge work template contains everything you need to start:

• Preconfigured plugins, skills, and permissions

• My minimal CLAUDE.md that makes your agent more autonomous

• Setup that reduces costs by at least 50% by managing models, subagents, and context windows better

• Ready-to-use configuration so you can work with free frontier LLM models

You can download the solution below (click File > Download):

claude-template.zip

Extract the archive and open it with VS Code:

You will see:

Inside:

• Predefined configuration:

  • CLAUDE.md / AGENTS.md - agent’s constitution

  • settings.json - cross-team project settings, predefined permissions and plugins

  • settings.local.json - your local project settings with 200K context window and 80% autocompact

• Examples:

  • SKILL.md - an example custom skill, you can remove it.

  • tools/reddit_api_example.py - an example custom tool generated by Claude. You can remove it, in that case remove line 53 from AGENTS.md too.

  • .env - here, you configure your API keys. Not committed to GitHub. You can remove two lines: REDDIT_CLIENT_ID and REDDIT_CLIENT_SECRET.

  • .mcp.json - an example custom MCP server. You can remove Linear (lines 3-6), if you don’t need it.

Tasks for you:

• Review and remove or adapt examples listed above.

• Update ## Strategic context, about me in AGENTS.md with a brief summary of your strategy or/and about you (for an individual)

• Update ## Communication and style in AGENTS.md so it follows your writing style and preferences

• Update docs/strategy.md with a information about your product

3. How to Configure MCP Servers in Claude Code Step-By-Step

MCP is a common protocol to connect apps such as Stripe, Gmail, Notion, Jira, or Slack. The easiest way is to go to https://claude.ai/customize/connectors and configure them there:

Those connectors are automatically available in Claude Code, too, as long you use a Claude subscription. Here’s how Claude works with my Gmail Connector:

Task for you: Connect the apps you use the most, such as Gmail, Notion, or Google Calendar. Configure actions that require your approval, such as sending an email, in claude.ai (presented in the screenshot above).

For apps not available in the Claude catalogue or when using a free LLM, use Google to find a dedicated MCP server and ask Claude to configure it in a chat based on the documentation:

MCP servers can be available:

• Only for you when using this project

• For any user using this project

• For any project on your local machine

Include your preference in the prompt.

4. How to Work with Skills in Claude Code Step-By-Step

Each skill gives Claude domain knowledge, analytical frameworks, or a guided workflow for a specific task.

They always contain SKILL.md file and can also include additional resources, for example:

---
name: substack-to-pdf
description: Export Substack posts to self-contained PDFs
  with embedded images.
---

# When to use
When asked to create PDFs from Substack posts.

# Steps
1. Fetch post HTML
2. Download images, embed as base64
3. Render with Playwright

# Files
- script.py
- styles.css

By default Claude can see only the frontmatter ("description"). The full skill is loaded automatically when relevant to the conversation.

4.1 Skills and plugins available publicly

Top recommended public repos. Each contains installation instructions. You can also give your agent an URL and ask to import specific skills:

1. github.com/phuryn/pm-skills: PM Skills Marketplace — 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth

2. claudemarketplaces.com: Browse and discover plugin marketplaces you can add to Cowork or Code

3. github.com/travisvn/awesome-claude-skills: Community-curated collection with battle-tested skills for TDD, debugging, collaboration

4. github.com/sickn33/antigravity-awesome-skills: 868+ universal agentic skills — covers security, DevOps, full-stack, AI/ML, and more. Role-based bundles (Startup Founder, Marketing & Growth, etc.) let you pick what’s relevant. Works with Claude Desktop, Claude Code, Cursor, Gemini CLI, Codex, OpenCode, and Antigravity

5. skills.sh: Vercel’s open skills ecosystem — directory and leaderboard, CLI installer (npx skills add). PM-relevant skills include product strategy frameworks, pricing strategy, launch playbooks, discovery interview guides, PRD generator, analytics tracking setup, resume optimizer, and more. Full repo also covers marketing, SEO, copywriting, and web design.

The bottom line: don't install skills you don't need. Start with none and add one when a real task forces it. Even unloaded skills cost context - the frontmatter description always loads.

4.2 How to create your own Claude Code skills

When you perform a specific task multiple times, ask Claude to turn it into a skill. It's way easier than editing markdown files manually.

Here, I continue the example from point 3:

Next time you ask Claude to summarize emails, it will reuse that logic while saving tokens.

Tip: Skills can be available for any user using this project or for any project on your local machine. It can also be called as subagent - use this option when the skill doesn't need your entire conversation history. Include your preferences in the prompt.

Task for you: When you notice a recurring pattern, ask Claude to turn it into a skill.

5. How to Use Claude Code with Free Frontier Models

Before you start: There is an open Anthropic bug, 36179. Using alternative models works only with Claude Code in terminal, not with the Claude Code extension for VS Code. Start by using your Claude subscription, especially if you're not comfortable with Claude Code yet.

Step 1: Go to OpenRouter, sign up: https://openrouter.ai/

Step 2: Verify your email address by clicking a link in an email message

Step 3: Add $5 credits to your account (to verify the account): https://openrouter.ai/settings/credits

Step 4: Create a free API key: https://openrouter.ai/workspaces/default/keys

Step 5: Open a folder with your project. Create settings.local.json in the .claude folder. Inside:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "{your-API-key}",
    "ANTHROPIC_API_KEY": ""
  },
  "model": "inclusionai/ring-2.6-1t:free"
}

You can also rename this file, already in your template. Create a backup of the original settings.local.json:

I suggested inclusionai/ring-2.6-1t:free. It’s a 63B model with a 262K context window. Note: free models on OpenRouter change regularly.

Here’s how it works with Claude Code in terminal, completely free:

Task for you: Get comfortable with Claude Code and Anthropic models before switching to alternative models. You don’t want to learn Claude Code and solve OpenRouter issues simultaneously.

Closing

You have everything you need to start.

Install it this week. Connect apps (MCP servers) you’ll actually use. Build one skill from a task you already do twice.

The more you use Claude Code, the easier it becomes. Later, review other posts listed in the intro:

• The Guide to Claude Code for PMs

• What I Learned Building a Self-Improving Agentic System with Claude

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• Your .claude/ Folder Is a Production Agent

• The Ultimate Guide to Claude Opus 4.7

• Claude Code’s Limits Are Generous. The Problem Is Your Setup.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have an amazing rest of the week, Paweł

10 minutes later I had a fully interactive prototype I could iterate on.

Not a mockup. Not a screenshot. A clickable flow built on top of my real design system, ready to share, comment, refine, and implement. Two examples:

Some compare Claude Design to Figma speed when iterating on the canvas. That framing misses the point.

What matters for a product team is Time to Learn - the time from “we should try X” to “we have evidence it works or fails.” And Claude Design can radically reduce it.

What you’ll learn:

• How to import or reverse-engineer your design system

• The PM context Claude Design needs to ship a usable first cut

• How to modify an existing production feature

• How to run the workflow with the product team and stakeholders

• What this means for product discovery, hiring, and the shape of senior roles

Subscribe now

1. What Changes for Your Team

I loved working with my designers. Ideating, challenging usability, sharing clickable prototypes with the business, running experiments. But sometimes I wished I had more of their time.

I didn’t enjoy Jira handoffs. In particular, keeping everything in sync as decisions changed and waiting for designers to verify the implementation is aligned with Figma.

Claude Design compresses two parts of the workflow:

Idea → prototype:

• Old: several days with a dedicated designer. Weeks if you don’t have capacity.

• New: same afternoon. Iterate in hours via chat, comments, or sketch.

Approved design → code in production:

• Old: weeks. You hand Figma to engineers. Engineers rebuild in code. Implementation drifts. Back-and-forth on what the design “really” meant.

• New: days. Engineers continue from the prototype and design system through Claude Code. No rebuild.

Some argue that Figma is faster for experienced designers. That might be true, but the difference is smaller than these two compressions. And can be radically reduced by selecting the right model - Sonnet for small fixes.

Designers should adopt this too. Cleaner handoff to engineering. More time on the work that needs design judgment instead of checking pixels.

The same design system also generates slide decks, motion videos, and custom templates. Marketing, sales, and support reuse the brand without rebuilding it.

2. How to Define Your Design System

Most product teams I’ve worked at had a design system in some form. A Figma library, a Storybook, a brand doc. Start by importing what you have.

Step 1: Open Claude Design > Design systems > Create

Go to https://claude.ai/design:

Step 2: Provide company name, examples, and sources

You can mix multiple sources and also drop in sketches, screenshots, photos, fonts, logos, and a text description of voice and brand. Claude Design can also pull context from the open web.

I tested reverse-engineering my existing codebase. According to multiple user reports, code wins when both code and Figma exist.

Note: DESIGN.md, introduced by Google is the lowest-fidelity option in the table because it’s rules-only - no assets, no components, no motion, and not all layout patterns. It’s a fast seed when you have nothing. Move to a codebase or .fig file as soon as you have one.

Tip: For a new product without a system yet, you can clone an existing brand you admire (Ferrari, Apple, Linear) and iterate from there 🙂 Faster than starting from a moodboard, and you keep refining until it’s yours.

You can also run multiple design systems in parallel. Useful if you ship across product lines, or if you’re testing a brand refresh without breaking production.

Step 3: Click “Continue to generation”

Three artifacts:

• Design System. UI kit, type, colors, spacing, components, brand. Every prototype anchors on this.

• Design Files. Assets, HTML, images, stylesheets you can preview.

• Skill.md. A skill Claude Design generates as a representation of the design system. The agent uses it to keep every new design consistent with your brand.

You can review your design system, iterate via chat, set permissions, and share with the team. Comments work the same way they do in Figma.

Step 4: (Optional) Export your design system as a skill

When you export your design system as a .zip archive, it becomes a skill you can give to any agent (Claude Code, Cowork, Codex, etc.). The skill is a complete representation of the system and contains all design files.

That’s the theory. In my tests, I faced errors. Waiting for a fix.

Share

3. How to Prototype a Product or Feature

Same flow whether you're prototyping something new or modifying what already ships. The difference is what you point Claude Design at on the way in.

Step 1: Open Claude Design > New prototype > Create

Pick the design system you generated in §2 and name your prototype.

Step 2: Provide Context

Depending on what you’re prototyping:

• New feature. Brief Claude Design from scratch.

• Existing feature. Point at the codebase, or branch from a previous Claude Design version.

You can also include screenshots, Figma files, web elements, or reference Claude Design projects (via “Import”).

What to brief it on:

• Objective. Should explain why it’s important and how the success will be measured. Often implicit, especially when you have a well-documented system.

• Persona. Who’s actually using this. Not the buyer. The person inside the screen.

• Value proposition. What this screen is supposed to deliver to that person.

• Job to be done. The underlying task they’re trying to complete.

• Common actions. What they’ll do most often. If you have product analytics, lead with those numbers. If not, your best assumptions.

Notes:

• There is no GitHub repo selector, but after connecting GitHub you can provide Claude Design with a GitHub URL.

• I specified a GitHub repo for a new feature because my agents maintain a full strategic context in the repo.

This isn’t just prompt engineering. It’s instrumenting business context for the agent beyond the current objective. For more, see the Intent Engineering Framework for AI Agents and my Opus 4.7 guide.

Step 3: Answer the Questions > Continue

If you forgot about the context, don’t worry. Claude Design interviews you before taking action:

Step 4: Review and refine in the canvas

5–10 minutes for the first generation. Once the prototype exists, switch to a faster model in chat. Iteration drops to seconds. An example result:

Once the prototype exists, PMs can run small fixes like copy edits, button placement, or empty-state polish without pulling in a designer for every adjustment.

Four refinement tools:

• Chat. Refine via natural language (”make the empty state more inviting”).

• Comments. Figma-style threaded notes. Anyone you share it with can drop them.

• Sketch. Draw directly on the prototype. Useful when “move that there” is faster than typing.

• Edit. Applying changes directly in the system. I would use it primarily for text adjustments:

  

Each prototype can have multiple variants on the same canvas. They are called tweaks. Just ask in the Chat. Claude Design adds them to the Tweaks panel. For example, here I asked for an Anthropic variant:

Step 5: Export and handoff

The Claude Code handoff is what changes the workflow the most. Your prototype isn’t a deliverable engineers re-implement. It’s a starting point they continue from.

I’ll come back to working with the trio and the deeper context inputs for modifying existing features in the paid section.

I built and shipped products for 10+ years. I talk to PMs every week. Next, a set of suggested workflows for your team based on my work in accredia.io:

• How to collaborate in the Product Trio.

• How to test assumptions and when you can just ship.

• What to do about Jira/Linear tickets.

• What this means for the future or product jobs. 👇

Read more

The same workflow cost me €1,184.95 (~$1,389) a month ago:

No model swap, no skipped sessions.

Between March 23 and April 23, some users on Max burned weekly quotas in 1-2 days. Anthropic shipped 3 bug fixes (v2.1.116+) and reset all subscriber limits. Full writeup in their April 23 postmortem.

Four root causes are still on your side (I’ve been researching and testing that for the last 2 weeks):

1. Cache misses

2. Context bloat

3. Wrong model or effort

4. Wrong input format

Our Sponsor: Nimbalyst

This is a paid placement, but I only run sponsors I've actually tested. I’ve been working with Nimbalyst for 10+ hours.

It’s a visual workspace for Claude Code and Codex. If the VS Code interface has intimidated you, you should try it.

I loved the markdown files that actually render without plugins, and navigating between linked documents. VS Code is missing this.

Big surprise: sessions as cards on a Kanban board. Backlog, planning, implementing, done. Claude doesn’t have this.

Plus session tracking, all the context window techniques we’ve been discussing, and a native iOS app (their custom remote control). Works with your Claude Pro/Max/Team subscription, not just API keys.

Free for individual use. Worth twenty minutes if you’ve been Claude-Code-curious:

Download Free

1. Cache Misses

The prompt cache is the single biggest lever in Claude Code. Most people never look at it.

The math:

• Cache read: 0.1× the input price

• Cache write (5-min TTL): 1.25×

• Cache write (1-hour TTL): 2×

• Cache refresh on hit: free (charged at the read price)

Every hit on a cached prefix resets its TTL at no extra cost. So a long session with steady tool use stays warm indefinitely as long as the prefix doesn’t change.

Thariq spelled out the rules in “Lessons from Building Claude Code.” The two that move the needle:

• Lock your tools at session start. Adding or removing a tool mid-session invalidates the cached prefix and forces a full re-read. Never add or remove tools mid-session.

• Lock your model at session start. Switching models mid-session blows the cache for the same reason.

~90% is healthy on the 5-min default. On the 1-hour TTL it climbs to ~97-99%, but that one is API-only and isn’t priced into Pro / Max / Team subscriptions.

What to Do:

• Protect the prefix. Don’t add MCP servers mid-session, don’t /model mid-session.

• Watch the hit rate. See § Watch the Number below.

• Consider the 1h cache for long sessions on the API. Write costs more (2× vs 1.25×), but the higher hit rate pays it back.

2. Context Bloat

For Opus 4.7, 1M context is the default. That’s expensive. Long sessions sprawl, and auto-compact fires later than it should. Disable it and fall back to 200K. 200K is enough for almost any task.

On 200K, auto-compact fires at ~155K (~80%), the behavior Boris Cherny described for the previous Opus. The trick is to compact before you hit the auto-trigger. Once it fires, it pushes you over and warms a fresh prefix. Compact early instead.

The settings I run:

{
  "env": {
    "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1",
    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "80"
  }
}

That disables 1M context and pins the auto-compact threshold at 80%.

2.1 Five Session Moves

• /compact at 50% or after every task. Don’t wait for auto.

• /clear between unrelated work. New session = fresh prefix.

• /rewind when a turn went sideways. Cheaper than re-prompting around the bad context.

• Subagents for anything that doesn’t need the parent’s reasoning.

2.2 Subagents Are the Underused Move

Anything that’s bulk-mechanical, scoped research, or parallelizable should run in a subagent. The parent context stays clean and you parallelize across cheaper models.

A CLAUDE.md task-delegation block I keep in every project:

## Subagents v1.0

Spawn subagents to isolate context, parallelize independent work, or offload bulk mechanical tasks. Don't spawn when the parent needs the reasoning, when synthesis requires holding things together, or when spawn overhead dominates.

Pick the cheapest model that can do the subtask well:
- Haiku: bulk mechanical work, no judgment
- Sonnet: scoped research, code exploration, in-scope synthesis
- Opus: subtasks needing real planning or tradeoffs

If a subagent realizes it needs a higher tier than itself, return to the parent.

Parent owns final output and cross-spawn synthesis. User instructions override.

2.3 Skills Can Also Be Invoked as Agents

Add agent: true and model: to the frontmatter and the skill runs in its own subagent context with its own model. For example:

---
name: tldr-pdf
description: Extract a 200-word TL;DR from a PDF without loading the full text into the parent context
agent: true
model: sonnet
---

You receive a path to a PDF.

1. Run `pdftotext "$1" -` to extract the text.
2. Read the output.
3. Return only:
   - 5-bullet TL;DR
   - 3 quotes worth keeping
   - Any URLs cited

Never return the full text. Never expand beyond the structure above.

The parent gets back 200 words. The full PDF never touches its context.

2.4 A Few More Techniques that Pay for Themselves on Long Sessions

• Load lean. Disable unused MCP servers, tools, skills, and plugins. Move rules out of CLAUDE.md and into skills, custom tools, or referenced .MD files (progressive disclosure).

• Spec prompts. Write requests like a spec: file paths, components, expected I/O, constraints. Vague requests burn turns and tokens.

• Skip the search. When you know the file, tag it @ docs/design.md or @ research.md. Claude doesn’t need to grep for what you can hand it directly.

• rtk-ai/rtk. CLI proxy that strips redundant whitespace and compresses tool output. 60-90% according to the authors. ~20-30% token reduction in my workflow.

  

• juliusbrussee/caveman. Drops conversational filler from responses without affecting the model’s actual reasoning. Highest savings on chats.

  

Subscribe now

3. Wrong Model or Effort

Three separate dials. All burn tokens fast if you leave them on the wrong setting.

3.1 Effort

Default reasoning burns ~2× the tokens of medium for most tasks. Set it on the prompt that needs the headroom, not the whole session.

markdown

/effort low       # quick fixes, mechanical tasks
/effort medium    # most prompts (huge savings vs default)
/effort high      # demanding reasoning 
/effort xhigh     # default for agentic coding (4.7)
/effort max       # diminishing returns; rarely worth the ~2× xhigh cost

Per prompt, not per task or session.

3.2 Route in (CLAUDE.md)

Pick the session model at start. You can’t switch mid-session without nuking the cache (§1). Two options:

• Sonnet session. Cheaper, but no Opus available. Good when you know the work is in-scope for Sonnet.

• Opus session + delegate. Pay for Opus on the parent (planning, tradeoffs), delegate the rest. My default for mixed work.

Then spell out delegation in CLAUDE.md: Haiku for mechanical work, Sonnet for scoped research, Opus for tradeoffs. Opus 4.7 delegates less than 4.6, so you have to ask. See § 2 (Task Delegation) for the full block.

3.3 Route Out

If you’re hitting Pro / Max / Team limits but want to keep the Claude Code interface, route to OpenRouter or another provider. GLM-5.1 ≈ Opus at ~1/12× the cost.

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "{YOUR-API-KEY}",
    "ANTHROPIC_API_KEY": ""
    },
  "model": "z-ai/glm-5.1"
}

Subscribe now

4. Wrong Input Format

Some inputs are token-expensive by default. Three swaps cover most of it.

4.1 Screenshots and Chrome Scraping → agent-browser

vercel-labs/agent-browser browses pages via the accessibility tree instead of rendering and screenshotting. ~90% fewer tokens than “Claude in Chrome” when you’re scraping or doing research from web pages.

npm install -g agent-browser
agent-browser install  # Download Chrome from Chrome for Testing (first time only)

4.2 PDFs → pdftotext, Not Claude’s PDF Reader

The Read tool loads PDFs as images, which is expensive. Tell Claude to use ‘pdftotext’ instead of ‘Read’ (works for PDFs on local drive, but not attached to the chat - the latter works in Claude Desktop only).

The CLAUDE.md fragment that codifies defaults from 4.1 and 4.2:

## Preferred Tools

### Data Fetching

1. **WebFetch**: free, text-only, works on public pages that don't block bots.
2. **agent-browser CLI**: free, local Rust CLI + Chrome via CDP. For dynamic pages or auth walls that WebFetch can't handle. Returns the accessibility tree with element refs (@e1, @e2). ~82% fewer tokens than screenshot-based tools. Install: `npm i -g agent-browser && agent-browser install`. Use `snapshot` for AI-friendly DOM state, element refs for interaction.
3. **Notice recurring fetch patterns and propose wrapping them as dedicated tools.** When the same fetch/parse logic comes up more than once, suggest wrapping it as a named tool (e.g. a skill file or a .py script that calls `agent-browser` with the snapshot and extraction steps baked in for that source). Add the entry to `## Dedicated Tools` below and reference it by name on future calls.

### PDF Files

Use 'pdftotext', not the 'Read' tool. Use 'Read' only when the user directly asks to analyze images or charts inside the document. Read loads PDFs as images.

## Dedicated Tools

<!-- List project-specific tools here. For each, link to its skill or script file (e.g. `tools/reddit_fetch.py`). The orchestration logic lives in those files, not here. -->

4.3 Large Repos → Code Graph, Not Raw File Reads

tirth8205/code-review-graph builds a persistent map of your codebase (a knowledge graph). Claude reads only what matters. Claimed 6.8× fewer tokens on reviews, up to 49× on daily coding tasks. I implemented it in accredia.io. Worth noting: it does reduce tokens on specific tasks, not all tokens.

AI coding tools re-read your entire codebase on every task. code-review-graph fixes that. It builds a structural map of your code, tracks changes incrementally, and gives your AI assistant precise context via MCP so it reads only what matters.

5. Watch the Number

Three dashboards, depending on your tier:

5.1 Historical (Pro / Max / Team)

phuryn/claude-usage: Long-term breakdown by session, day, week, and all-time. Use it to find where the spend went.

5.2 Real-Time

Gronsten/claude-usage-monitor: Current 5-hour window + active session tokens, with color thresholds. Use it to know how close you are to your cap right now.

5.3 API: Anthropic’s Own Cache Dashboard (API users)

At platform.claude.com/usage/cache, API only, separate from Pro / Max / Team subscriptions monitoring.

If you can’t see the cache hit rate, you can’t fix it.

🔒 6. An Upgraded Sub-Agents Instructions for Cowork and Claude Code

In §2.2, I shared a Subagents v1.0 block that significantly reduced my tokens in Claude Code, especially with Opus 4.7.

After running it across dozens of sessions, two failure modes kept showing up:

• Subagents with no strategic context returned compliant-but-useless data, forcing the parent to re-spawn with a better brief and pay for the work twice.

• Unverified data silently propagated into the parent agent.

Those two issues were common in Claude, unrelated to tokens.

The block below fixes them by adding the strategic-context layer. Works across Cowork and Claude Code 👇

Read more

GPT-5, Grok, Gemini, open-weight models via OpenRouter, a local model on your laptop, or your enterprise gateway (Bedrock, Vertex, Foundry).

Anthropic shipped it quietly. No announcement. No blog post. Just technical docs. I discovered it by accident. 20+ hours later, still zero official word.

1. What It Actually Is

Built for enterprises and individuals. Same config panel, same admin controls.

If your organization uses Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway to access Claude, you can deploy Claude Cowork to run on the same infrastructure.

This is a research preview. The official docs cover three paths:

• regulated industries

• companies running Claude through their own gateway

• individuals on pilot/evaluation setups

Any individual can install it today.

Every admin control (per-user token caps, MCP allowlist, OpenTelemetry, block auto-updates, remove built-in tools) ships on all three paths.

OpenRouter counts as an LLM gateway. Anthropic doesn’t list it in the docs, but I tested that it works. Confirmed by the OpenRouter CEO:

Brief summary:

Foundry: during this research preview, Claude on Foundry still runs on Anthropic’s infrastructure. Bedrock and Vertex are the paths with full provider-side data residency.

2. Who This Is For

Two audiences. Same config, different endpoint.

Individuals:

• Hitting Max plan weekly limits

• Want to try Cowork without paying $100 or $200 a month

• Running a local model on code you can’t send to any API

Enterprise:

• Already on Bedrock, Vertex, or Foundry. Keep the harness inside your existing compliance boundary

• Security approves your cloud provider but not Anthropic direct

• Need team-wide admin controls (token caps, MCP allowlist, OpenTelemetry)

Side note: Find this helpful? Here are some other Claude posts you may have missed:

• Claude Cowork: The Ultimate Guide for PMs

• The Guide to Claude Code for PMs

• What I Learned Building a Self-Improving Agentic System with Claude

• The Claude Dispatch Guide: 48 Hours Running AI Agents From My Phone

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• The Ultimate Guide to Claude Opus 4.7

Subscribe and upgrade your account for the full experience:

Subscribe now

3. Enable & Configure

3.1 Connect to OpenRouter

No proxy needed. Point Claude Desktop straight at OpenRouter.

1. Menu → Developer → Configure Third-Party Inference

   

2. Set:

   1. Connection: Gateway

   2. Gateway base URL: https://openrouter.ai/api

   3. Gateway API key: your OpenRouter key

   4. Gateway auth scheme: x-api-key

      

   5. In the Sandbox & workspace configure "Allowed egress hosts" so that your agents can access the web. For example (all sites):

      

3. Click: Apply locally → Relaunch now

4. Log out, then Continue with Gateway:

   

5. You’ll see “Setting up Claude’s workspace...” You can start chatting:

   

Select an OpenRouter model. The free one that works for me: tencent/hy3-preview:free

Local models work the same way through an OpenAI-compatible proxy (LiteLLM, Ollama’s OpenAI endpoint). I’ll cover local setup in a separate post.

3.2 Import Anthropic skills

OpenRouter setups ship with Customize → Skills empty. Install the official Claude Desktop skills (docx, pdf, pptx, xlsx, skill-creator) manually.

1. Download the skills repo as .zip: https://github.com/anthropics/skills/tree/main/skills

2. Extract skills-main.zip, go inside

3. Zip the skill folders you want individually (e.g., docx folder → docx.zip)

4. In Claude Desktop: Customize → Skills → Create skill → Upload a skill. Upload each .zip

Only import the ones you need. Skills take context window space even when not fully loaded.

3.3 Import Anthropic plugins

Same pattern. Two repos worth pulling from:

• Knowledge-work plugins (marketing, product-management, legal, finance): https://github.com/anthropics/knowledge-work-plugins

• Code tab plugins: https://github.com/anthropics/claude-plugins-official

Steps:

1. Download the repo as .zip

2. Extract, go inside

3. Zip the plugin folders you want (e.g., product-management → product-management.zip)

4. In Claude Desktop: Customize → Personal plugins → + → Create plugin → Upload plugin

Cap it at 2–3 plugins. Often 0 is right.

3.4 Configure MCP servers

MCP servers are local. Add them under Settings → Developer.

They write to a dedicated claude_desktop_config.json file (if you don’t see that option see 4. Troubleshooting).

You can find servers at github.com/modelcontextprotocol/servers (official).

Example: Atlassian (Jira + Confluence) via the community mcp-atlassian server:

{
  "mcpServers": {
    "atlassian": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://your-domain.atlassian.net",
        "JIRA_USERNAME": "your-email@example.com",
        "JIRA_API_TOKEN": "your_api_token"
      }
    }
  }
}

3.5 Search

OpenRouter doesn’t support Anthropic’s native web search. Three ways around it:

1. Replace it with an MCP. Add WebSearch to disabledBuiltinTools so that the agent is not confused and install the Brave MCP server (2,000 free requests/month, or $3 per 1,000).

Add this MCP:

{
  "mcpServers": {
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": { "BRAVE_API_KEY": "YOUR_API_KEY_HERE" }
    }
  }
}

2. Switch provider to Vertex AI or Microsoft Foundry. Both support native web search. Amazon Bedrock doesn’t yet.

3. Wait. OpenRouter could route Anthropic’s web_search tool to Perplexity or similar - not shipped yet.

Side Note: On May 9, we’re launching Hands-On Claude Code Certification. In 4 weeks you will learn everything to ship full agentic products — UI, agentic harness, evals, guardrails, and ops — with Claude Code. Real apps, not demos.

Secure your spot (40% off)

Most students expense this through their companies.

4. Troubleshooting

Can’t see “Configure Third-Party Inference” in Menu → Developer

Update Claude Desktop and restart. Then enable developer mode: Help → Troubleshooting → Enable Developer Mode.

Users on corporate/Team plans have reported the setting is still missing even with developer mode on. It may be plan-gated or A/B rolled.

Can’t see “Local MCP servers” in Cowork on 3P

Update Claude Desktop and restart. Then enable developer mode: Help → Troubleshooting → Enable Developer Mode.

Connectors show as “Unavailable”

Not a bug. Third-party inference means running without Anthropic’s infrastructure. Connectors depend on that layer. Use an MCP server instead (See 3.4).

Tool calling is flaky on non-Claude models

Models vary. Some handle MCP calls cleanly; others break on multi-step agentic flows. The best I’ve tested: https://www.productcompass.pm/i/193559427/api-pay-per-token-choose-your-model

Code tab settings don’t match Cowork settings

Acknowledged in Anthropic’s docs: some Cowork on 3P config keys don’t propagate identically to Code-tab sessions yet.

5. What This Signals

Look at what ships in Configure Third-Party Inference:

• Max tokens per window (per-user soft cap)

• Allow user-added MCP servers

• OpenTelemetry collector endpoint

• Block auto-updates

• Remove built-in tools from Cowork

None of those matter to a solo user. They’re admin controls. Paired with Bedrock, Vertex, and Foundry support, Anthropic’s official framing is explicit:

Cowork on 3P is designed for organizations whose security, regulatory, or contractual requirements prevent them from sending data to Anthropic’s first-party infrastructure.

Claude Desktop is becoming a managed agent platform. The harness (Code, Cowork, skills, plugins, MCP, sub-agents) is what Anthropic wants to be the default, regardless of which model sits behind it.

The individual path is documented, not an accident. On my Max plan, the full config panel shows up. Anthropic's docs don't explicitly say end users get this; the install section just tells you to "enter the values supplied by your administrator." But on a personal install, with no administrator in the picture, those fields sit there for you to set.

Docs:

• Use Claude Cowork with third-party platforms (support)

• Cowork on 3P: overview

• Cowork on 3P: installation

Download and install Claude Desktop. Start with a free OpenRouter model. No $200/mo subscription required.

We’ve covered the Claude ecosystem in the previous posts and recorded meetings available to the premium members.

Subscribe now

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

I’m uploading two new recordings, Building Agents with Claude Code and Context Window Optimization, tomorrow.

Take care,
Paweł

Anthropic shipped Claude Opus 4.7 on April 16. The official migration guide puts it plainly: 4.7 “takes the instructions literally” and “will not silently generalize.”

It's not a uniform upgrade. Wins on coding, creative writing, and structured work. Losses on instruction following in vague prompts, multi-turn, and long-context retrieval. The benchmarks show a trade, not a regression. I sort real regressions from preference artifacts and cost mechanics in § 6.

Boris Cherny, Claude Code lead at Anthropic, posted on release day: "It took a few days for me to learn how to work with it effectively."

Why Read This, and Why Now

Reddit calls 4.7 a regression. Arena shows 4.6 winning on instruction following. Anthropic's migration guide says it's working as designed. Boris confirms it's more agentic and precise.

The takes don’t agree because they’re measuring different workflows.

By the end you’ll know:

• The ten moves to make your 4.6 prompts work on 4.7

• Where 4.7’s cost really goes, and the ten highest-ROI levers

• What Cowork and Dispatch users lose vs the Code, and what I use on mobile instead

• How to decide between 4.6 and 4.7 for your own workflow

• You don’t need more instructions. You need better intent.

I’ve had 16+ hours with 4.7 so far. What follows is what changed, what to do about it, and resources section at the end.

Subscribe now

1. What’s New in Opus 4.7

4.6 filled the gaps when your instruction was unclear. 4.7 takes you at your word.

For PMs: if your 4.6 workflow relied on the model “figuring out what you meant,” expect 4.7 to ask more questions, or to do less, or to do exactly what you asked for (which is not what you wanted).

2. Intent: The Universal Unlock

This is the principle: 4.7 rewards clear intent. Everything else in this post is a tactic.

Not longer prompts, not more rules, not a bigger CLAUDE.md. Intent splits into two layers:

• Strategic context is durable: what you’re building, who it’s for, what’s off-limits, what good looks like. Write it once. Put it in CLAUDE.md. It loads every session, progressive-disclosure style, so you’re not paying to reintroduce the project on turn one.

• Per-task intent is variable: what specifically do I want Claude to do right now. You still write this every turn. The gain from CLAUDE.md is that you stop retyping the strategic context on top of it.

The full version (seven components, how they compose) is in The Intent Engineering Framework for AI Agents, published three months before 4.7 shipped:

This is perfectly aligned with Karpathy’s Claude coding post, too:

“Leverage. LLMs are exceptionally good at looping until they meet specific goals and this is where most of the “feel the AGI” magic is to be found. Don’t tell it what to do, give it success criteria and watch it go (...) Change your approach from imperative to declarative to get the agents looping longer and gain leverage.”

Anthropic and OpenAI convergence

Anthropic moved Opus 4.7 toward more literal instruction following. OpenAI updated their December 2025 Model Spec to say “consider not just the literal wording but the underlying intent.”

They’re converging from opposite directions. Anthropic is adding precision to its intent-first model. OpenAI is adding intent inference to its precision-first model. The same skill (engineering intent clearly) is becoming the unlock on both sides.

And Anthropic is already encoding it

Managed Agents (research preview) bakes success criteria and outcomes into the framework itself. I recently covered it here:

The skill of engineering clear intent is what transfers across vendors and models. That’s why it has the longest shelf life right now.

Subscribe now

Side Note: On May 9, we’re launching Hands-On Claude Code Certification. In 4 weeks you will learn everything to ship full agentic products — UI, agentic harness, evals, guardrails, and ops — with Claude Code. Real apps, not demos.

Secure your spot (40% off)

Most students expense this through their companies.

3. The 10 Claude Opus 4.7 Migration Moves

3.1 Front-load intent in CLAUDE.md

You don’t have to retype the strategic context every session. Put it in CLAUDE.md once. Every future session starts with the context already loaded. You still write per-task intent each turn, but you stop paying the “remember what we’re building” tax.

Delegate information the agent doesn’t have to read every session to other files, like strategy.md below:

3.2 Default to Extra high (xhigh)

New effort level between high and max. Anthropic’s own recommendation for coding and agentic work.

max is prone to overthinking. Most “4.7 feels slow” reports trace back to people running max by reflex. Use max only when the problem actually needs deep reasoning.

3.3 Toggle effort mid-task

Effort is per-call, not per-session. max for the hard subproblem. Drop back to high for the rest.

3.4 Regression-test old prompts

New tokenizer. 1.0 to 1.35× more tokens per input. Your 4.6 workflows cost more on 4.7 before you’ve changed a line.

The offset to know about: Anthropic raised rate limits alongside the 4.7 launch:

My perspective: what matters most is cost per correct output token. Test it for your specific product before switching the model.

3.5 Batch questions. Stop drip-feeding.

If you have three questions, ask all three in one message.

On 4.6, clarifying across 3-4 turns worked. On 4.7, each turn adds reasoning overhead on top of literal interpretations from earlier turns.

Treat clarification as an exception, not a workflow.

3.6 Show what you want

Positive examples beat negative rules. According to Anthropic:

• “Like this: ” followed by short examples works.

• “Don’t do this: ” rarely lands and burns tokens trying.

If your prompt has more than three “don’t” or “never” lines, flip them. What does the ideal output look like? Show two examples and cut the rules.

3.7 Delete old progress scaffolding

“Summarize every 3 tool calls.” “Give me a status update before moving on.” “Explain your plan, then execute.” Delete these.

4.7 emits high-quality progress updates natively in long agentic traces:

3.8 Tell it to fan out explicitly

4.7 spawns fewer subagents by default and makes fewer tool calls per task. For parallel exploration, you now have to ask.

Phrasings that work: “spawn subagents in the same turn to investigate X, Y, Z.” Autonomy went up. Default delegation went down.

I also added separate instructions for Dispatch in DISPATCH.md. This file is referenced from CLAUDE.md:

Later, I explain why I started using Dispatch less often.

3.9 Review plans, not diffs

Two different primitives. Don’t confuse them.

• Plan mode (Shift+Tab twice in the Claude Code CLI): inline, surfaces the plan before any code exists in the current session. Use for any change that touches more than one file:

• /ultraplan (CLI only, doesn’t work in VS Code extension): cloud-based plan drafting from the CLI, review in the browser. Plan runs in a remote session while your terminal stays free:

Why this matters more on 4.7: because 4.7 takes intent literally, a small misread in the plan becomes a large misread in the diff. Reviewing a 10-line plan for intent drift takes 30 seconds. Reviewing a 200-line diff for the same drift takes 15 minutes.

My take:

Intent drift compounds. Catch it in the plan.

3.10 Adaptive thinking only

Fixed thinking budgets are gone. Use thinking: {type: 'adaptive'} plus the effort parameter. Old API calls with budget_tokens return HTTP 400. Find and replace before flipping the model flag:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    messages=[
        {
            "role": "user",
            "content": "Explain why the sum of two even numbers is always even.",
        }
    ],
)

If you’re not an engineer, you don’t need to memorize the syntax. Just give your agent this documentation: https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking.md (remove “.md” for a human-friendly view).

Everything above is the mental model. Below, the execution: 10 highest-ROI moves for 4.7 that actually move the bill, my remote setup, and Cowork/Dispatch gotchas 👇

4. Cost Control on Opus 4.7

$20/month is enough to poke at Claude. It’s not enough to run agents. And 4.7 is more expensive than 4.6 by default. New tokenizer (1.0–1.35× tokens per input), adaptive thinking with generous budgets, high-res vision at 3× tokens.

Ten highest-ROI moves (can cut tokens significantly; in my setup, 60–80%):

Read more

Everyone's covering agents helping you build or do knowledge work. The pattern nobody's explaining: the same primitives are the production runtime.

What you’ll learn:

• The Claude Code primitives that double as a production runtime

• When to pick the Anthropic Agent SDK

• The architecture — one function call replaces an n8n-style workflow

• A full working demo: source code, build prompt, hosting notes

• The gotchas that silently break things

• How to host your Claude Code agents in production

1. The Missing Pattern — Agent as A Callable Component

Two narratives dominate right now:

• Agents as products. Claude Code, Lovable, Cursor. You use them to code or to do your work.

• Agents as infrastructure. Claude Managed Agents, CrewAI, LangGraph.

The pattern sitting between those two is agent as a callable component inside your app.

How does it work?

Your web app handles routing, auth, CRUD, form validation. When a request needs reasoning, you call the agent — which runs in a sandbox with its own CLAUDE.md, skills, and MCP servers.

The part that surprised me: the same .claude/ folder I've been editing every day for months is the deployable unit. There is no translation layer between dev and prod. The CLAUDE.md that guides Claude Code in your terminal is the exact same CLAUDE.md format that runs in production.

Subscribe now

2. The Primitives You Already Use

Five key things. We've discussed most of them in the previous posts about Claude Code and Cowork:

• CLAUDE.md — the agent’s identity in markdown. Tone, rules, constraints. In dev it shapes how Claude Code behaves in your terminal. In prod it loads as the system prompt of your production agent. Edit the file, ship the behavior.

• Skills (.claude/skills/) — reusable behaviors, also markdown. Same file format in dev and prod. Same loader.

• MCPs (.claude/mcp.json) — servers that extend the agent’s tool surface. Your dev config probably talks to Chrome and your filesystem. Your production agent’s config talks to your search API and your database. Different servers, identical contract.

• Hooks — functions that fire on tool events. PreToolUse can block dangerous operations (reading .env, path traversal). PostToolUse can log everything the agent read so you can show it in the UI.

• Sub-agents (.claude/agents/<name>/) — each directory is a self-contained agent: its own CLAUDE.md, its own skills, its own MCP config, its own docs. Adding a second agent to your product is a new folder.

Everything is files. Everything is version-controlled. Everything diffs cleanly in a PR. If you've onboarded to Claude Code, you've already onboarded to the production stack.

In case you wondered, here’s a bigger picture:

Subscribe now

3. Why This Matters in Production

Here’s how it stacks up against the alternatives:

Four things fall out of this that I didn't expect going into the spike:

• Nothing new to learn. The CLAUDE.md you wrote in dev is the CLAUDE.md that ships. Your muscle memory is already the production runtime.

• You can skip Claude Managed Agents unless you actively need a hosted runtime. For request-response agents inside an app you already host, the SDK is a smaller dependency than a whole platform.

• Full observability. Hooks give you live per-response metadata — cost, duration, files read — for your UI. OTEL exports full traces to Langfuse or any OTLP backend when you need it.

• Same loop, dev → prod. The config you tested in Claude Code is the config running in production. If it worked in your terminal, it works in your app. No mental translation.

For PMs: this is what lets you prototype and ship agent features without becoming a bottleneck. Changing the agent's behavior is editing a markdown file — not a sprint, not a code review, not a redeploy cycle. You iterate on AI behavior at the speed you iterate on a Notion doc.

Now the part most people skip — how you actually wire it up.

4. The Architecture — One Function Call Replaces a Workflow

In n8n you wire it up node by node. A single agent has system prompt, LLM, model, tools, and memory.

A single Claude agent isn’t a workflow. Inside an app, you don’t need a node-by-node graph around it — simple orchestration and guardrails live in your hooks or your business logic.

In the SDK it's this:

for await (const msg of query({
  prompt: question,
  options: {
    cwd: './.claude/agents/knowledge-agent',
    settingSources: ['project'],
    allowedTools: ['Read', 'Glob', 'Grep'],
    maxTurns: 5,
    maxBudgetUsd: 0.15,
    model: 'claude-sonnet-4-6',
    hooks: { /* guardrails */ },
  },
})) {
  // stream text to the user, collect metadata
}

settingSources: ['project'] is the auto-loader. It reads the agent's CLAUDE.md, skills, and MCP config from agent’s working directory (cwd). Same behavior Claude Code has when it opens a session. You don't manually load anything.

The boundary is clean. Your app owns the request lifecycle, auth, storage. The agent owns reasoning, tool selection, iteration. One function sits on the seam. That's the entire orchestration layer.

Share

5. The Demo — Knowledge Chatbot

I built the smallest thing that shows the pattern: a web app with markdown files and a chatbot that answers questions using those files, with memory across turns.

The agent lives in its own directory:

Stack:

• Next.js 15 standalone (not serverless — the SDK spawns a full Claude Code runtime, not a lightweight API client).

• SQLite for conversation memory because this is a prototype. Postgres, Redis, a JSON file on disk — all fine.

Adding a second agent? New folder in .claude/agents/. Give it a CLAUDE.md. Point cwd at the new directory. Same structure every time.

Keep reading for:

• The prompt that scaffolds the app — paste into an empty repo, Claude Code builds the rest.

• Full source code — Knowledge Chatbot, streaming responses, per-message cost metadata.

• The lib/agent.ts wrapper with the TypeScript pitfalls the SDK docs skip

• The postbuild trick that stops production from inheriting your repo’s CLAUDE.md.

• The limitations I hit in the spike and the workarounds for each.

• How to easily host this in production.

Read more

I run Claude Code on a Max plan. 440 sessions last month, 18,000 turns. I built a dashboard to track what that actually costs: $1,588 in API-equivalent tokens. Covered by a $200 subscription.

Here’s the full breakdown — what April 4 killed, which API models actually work for agentic coding, and how to see exactly where your budget goes.

What You’ll Learn

• What April 4 actually killed — which tools lost subscription access and why Anthropic pulled the plug

• The full cost landscape — subscriptions and API models in one table, ranked by the metric that actually predicts agentic performance

• Why SWE-bench is misleading — it didn’t match my experience. Agentic Index did.

• OpenRouter setup: two environment variables, 400+ models, done

• Token visibility: an open-source dashboard that shows exactly where your Claude Code tokens go

Subscribe now

1. The April 4 Policy Change: What Died, What Lives

April 4, 2026: Anthropic announced Claude subscriptions no longer work with third-party tools. If you were using Cline, Cursor, Windsurf, OpenClaw, or any non-Anthropic harness through your subscription — it stopped working.

What Still Works with Subscriptions

• Claude Code CLI — Anthropic’s official agentic coding tool

• Claude Code extension for VS Code — same mechanism

• Claude.ai — web and mobile interface, including agentic Code sessions

• Cowork — user-friendly agent inside Claude Desktop

• Dispatch — the orchestration layer for Cowork and code

What Died

• Cline — popular VS Code agent, relied on subscription auth

• Cursor — AI-native editor, subscription routing cut off

• Windsurf — Codeium’s editor, same story

• OpenClaw — open-source Claude Code alternative with 135,000+ instances

• Custom agents and automation — anything routing through subscription billing

For automation workflows (n8n, OpenClaw, custom agents): You’re on API billing now. The next section shows you exactly what that costs — and why it might actually be cheaper than you think.

—

OpenClaw footnote: A community workaround briefly routed OpenClaw through Claude Code’s MCP bridge. Anthropic closed it — one exact substring match to block OpenClaw’s system prompt.

2. The Full Cost Landscape

Many builders and PMs either overpay for a subscription they don’t fully use, or overpay for API models because they default to Sonnet. Here’s everything in one place.

Claude Subscriptions: Flat Cost, Predictable

Every tier requires discipline. Opus burns credits ~5x faster than Sonnet, so use Opus for hard problems and switch to Sonnet for straightforward tasks. Run /compact regularly. Without this, you’ll hit limits on any plan — including Max 20x.

How cheap is this compared to API? My Max 20x costs $200/month. The dashboard I built (Section 4) shows $1,588 in API-equivalent costs for Claude Code alone — and I use Code and Cowork roughly 50:50, so the real API bill would be far higher. The Claude subscription runs roughly 15-30x cheaper than paying per token for the same work.

Teams and Enterprise subscribers: If your company already provides Claude Teams or Enterprise, you have Claude Code access included. Check with your admin — you may not need a personal subscription at all.

API: Pay Per Token, Choose Your Model

OpenRouter gives you access to 400+ models. Most aren't worth your time for agentic coding. I tested dozens — the table below is what survived real multi-step Claude Code sessions, ranked by Agentic Index:

Why Agentic Index?

• SWE-Bench (Verified and Pro) tests isolated bug fixes — one issue, one patch, no iteration. It didn't match my experience.

• Agentic Index (from Aider's polyglot benchmark) measures what Claude Code actually does: read files, plan changes, apply diffs, run tools, recover from errors, iterate. It matched what I saw in practice.

Claude Subscription vs API

Subscription wins if you code with Claude Code daily. Opus is the best agentic model — and cost per token isn’t cost per correct token. A cheaper model that needs many iterations to fix its own errors costs more than Opus getting it right the first time. Cowork, Dispatch, and web-based Claude Code sessions also require a subscription.

API wins if your usage is moderate, spiky, or you’re running automation workflows. Opus and Sonnet via API are hard to justify when the subscription gives you flat-rate access — and budget models match or beat Sonnet’s agentic performance:

• GLM-5.1 — matches Opus 4.6 on agentic performance (67.0 vs 67.6) at 1/12x the input cost. Default for automation.

• GLM-5 — same family, cheaper. Matches Sonnet’s 4.6 agentic score at 1/4x the cost.

• MiniMax M2.7 — when cost matters most. 1/10x Sonnet’s 4.6 score. Still solid.

One Thing Missing: Token Visibility

The subscription model has one real frustration: you can't see where your tokens go. /usage exists but doesn't break down by model, project, or session — so when you hit limits unexpectedly, it's not obvious why.

Anthropic knows: there are open feature requests for per-prompt token breakdown and a real-time usage indicator. I built an open source solution — Section 4 covers it.

Subscribe now

3. OpenRouter Setup for Claude Code

Claude Code isn’t locked to Anthropic’s models. Switch ANTHROPIC_BASE_URL and it routes to any compatible API. Add a .claude/settings.local.json to your project root, for example:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "sk-or-v1-{your-OpenRouter-API-key}",
    "ANTHROPIC_API_KEY": ""
    },
  "model": "z-ai/glm-5.1"
}

Why OpenRouter over direct provider APIs?

One key, one endpoint, 400+ models. Switch between GLM-5, Qwen, Gemini, and GPT-5 by changing one variable—no juggling multiple API keys or base URLs.

Switching the API works for Claude Code CLI, but not for Claude Code Extension. In practice, this doesn’t make a huge difference, as you can still work with VS Code interface.

Step-by-step demo:

Side Note: Want to build with Claude? Join our AI Agents Claudathon — in 4 weeks you will learn everything to ship real agentic products with Claude Code. No experience required:

Learn more

P.S. This is not an external cohort. Just me and .

4. Claude Code Usage Dashboard: See Where Your Tokens Go for Free

I mentioned the visibility gap in Section 2 — /usage doesn’t break down by model, project, or session. You hit limits and have no idea why.

That frustrated me enough to build something.

I open-sourced a local dashboard that reads your Claude Code transcripts and shows you exactly where tokens go. No cloud, no telemetry — everything stays on your machine:

You can star it, fork it, and make it your own. GitHub (open source, MIT):

Claude Code Usage Dashboard

What It Shows

• Cost per day, broken down by model (Opus vs Sonnet vs Haiku)

• Sessions and turns over time

• Filter by model, filter by time range (7d / 30d / 90d)

• Top projects by tokens — see which codebase is eating your budget

• Auto-refreshes every 30 seconds at localhost:8080

My 30-Day Numbers

440 sessions. 18,000 turns. $1,588 in estimated API costs.

All covered by the Max subscription. For a fraction of the price.

First thing the dashboard caught: one day spiked to 700 million cached tokens. Not my usage — an Anthropic bug. Without the dashboard, I’d never have noticed.

Setup & Run on Windows

git clone https://github.com/phuryn/claude-usage
cd claude-usage
python cli.py dashboard

Setup & Run on MacOS, Linux

git clone https://github.com/phuryn/claude-usage
cd claude-usage
python3 cli.py dashboard

What It Measures

Claude Code Usage Dashboard works with any Claude subscription (Pro, Max, Team, Enterprise) running Claude Code — CLI, VS Code extension, and dispatched code sessions.

At the same time, Cowork and web code sessions are not included. We need to wait for Anthropic for a better solution.

5. Token-Saving Techniques (Works Everywhere)

Before switching models or tools, optimize what you’re already doing. These apply whether you’re on subscription or API.

Use /compact Aggressively

Context accumulates fast. Every file read, tool call, and response adds tokens. A 30-minute session easily hits 200K tokens, and you’re paying for all of it on every subsequent message.

Run /compact after major milestones. It preserves intent and drops noise.

Don’t Use Opus for Everything

Opus 4 costs 5x more than Sonnet ($15/$75 vs $3/$15 per M tokens). For most coding tasks, Sonnet is equivalent—and GLM-5.1 matches Opus on agentic tasks at 1/12th the cost.

If you struggle with available tokens, use Opus only for:

• Complex architectural reasoning when Sonnet keeps failing

• Long-context analysis where every detail matters

• Tasks with extreme ambiguity

Default to Sonnet or GLM. Escalate to Opus when the model fails.

Watch for MCP Tool Overhead

MCP tools can easily add ~20K tokens to every session just from tool definitions.

While by default they are loaded on demand in Opus and Sonnet, this may not work with custom LLMs. Remove MCP servers you don’t need by typing /mcp in Claude Code CLI.

Hint: This is where you can adjust default settings for Opus and Sonnet:

  {
    “env”: {
      “ENABLE_TOOL_SEARCH”: “true”
    }
  }

Code Graph MCP: Feed Claude Only What It Needs

Every time Claude Code reviews a change, it searches your codebase with grep and glob — smart, but not structural. It doesn’t know which functions call what.

code-review-graph adds that structural layer. It parses your codebase into an AST, stores it in SQLite, and tracks changes via git hooks. At review time, it traces the blast radius of your change and feeds Claude only the affected files.

The author’s benchmarks: 6.8x fewer tokens on code reviews, up to 49x on daily coding. On a 27,700-file monorepo, only 15 files were read.

I haven’t tested these numbers myself, I currently don’t work with such large codebases, but the architecture makes sense — especially for large codebases where the savings compound.

Agent-Browser: Browse Without Screenshots

If your agents need browser access, don’t use Chrome MCP with screenshots — each screenshot eats thousands of tokens for a single page view.

agent-browser by Vercel Labs takes a different approach: instead of screenshots, it returns an accessibility tree snapshot with element references (@e1, @e2, etc.). Agents interact via those refs — compact text, not images. The result: 82% fewer tokens than Playwright MCP, up to 93% reduction overall.

It’s also much more reliable than the standard web fetch:

No configuration needed. Works with Claude Code (tell it to use it in CLAUDE.md) and any MCP-compatible agent. Installation:

npm install -g agent-browser

Subscribe now

8. Closing

Subscribe for daily coding — stop watching the meter. Route automation to GLM-5.1 for Opus-level agentic performance at 1/12th the cost. Track every token with an open-source dashboard so you know exactly what you’re getting.

Anthropic’s April policy change forced automation users onto API billing. But it also clarified the landscape: subscriptions for Anthropic tools, APIs for everything else.

The one thing still missing: real token visibility from Anthropic. Until they ship it, the dashboard fills the gap. Clone it, see where your tokens go, and stop guessing:

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Next: prototyping for PMs (3 tools & templates). This will be a paid content.

Have a great week ahead,
Paweł

What You’ll Learn:

• A Knowledge Architecture block that turns Claude into a system that learns across sessions — not just a tool that forgets

• A Decision Journal block that logs every meaningful choice with full reasoning, so Claude (and your team) never re-debates settled decisions

• A Quality Gate block that gives Claude concrete evaluation criteria — because agents can’t objectively judge their own work

• A schedule suggestion that keeps the whole system from going stale

• The full integrated CLAUDE.md — all three blocks ready to paste

0. Memory Without Reflection

Claude remembers. It writes its own memories, reads your CLAUDE.md, follows your conventions. But it doesn’t reflect on what it knows.

It captured that your pricing test showed 40% churn. It captured that a competitor dropped their free tier. It captured that onboarding users churned less. Three separate observations in three separate sessions — and Claude never connected them.

Memory without reflection is just storage.

Claude now ships with built-in configuration — the .claude folder, settings files, rules. Boris Cherny, the creator of Claude Code, shared how his team uses CLAUDE.md internally — every correction becomes a rule, checked into git.

That’s a good foundation. But it’s a correction log. The system doesn’t promote patterns on its own. It doesn’t test its own hypotheses. It doesn’t evaluate whether its work meets project-specific standards.

The community has built impressive tooling on top of this. Some repositories catalog 135+ agents, 42 commands, and hundreds of plugins. Powerful systems for teams that want deep infrastructure.

Most builders need something they can paste in 90 seconds that makes Claude measurably better by next week.

Three blocks. Each one targets a different failure mode — learning, deciding, evaluating. Together, they turn memory into a system that reflects, connects, and compounds.

Subscribe now

1. Knowledge Architecture — The Learning Loop

The problem: Claude captures observations but never revisits them. Insights from last week's session don't inform this week's work. There's no mechanism to test whether a pattern holds, promote it when it does, or discard it when it doesn't.

The snippet:

Before starting a new task, review existing rules and hypotheses for this domain.
Apply rules by default. Check if any hypothesis can be tested with today's work.

At the end of each task, extract insights. Store them in domain folders, e.g.:
  /knowledge/pricing/         (or /onboarding/, /competitors/)
    knowledge.md  (facts and patterns)
    hypotheses.md (need more data)
    rules.md      (confirmed — apply by default)

Maintain a /knowledge/INDEX.md that routes to each domain folder.
Create the structure if it doesn't exist yet.
When a hypothesis gets confirmed 3+ times, promote it to a rule.
When a rule gets contradicted by new data, demote it back to hypothesis.

How it works: Before every task, Claude reads the existing knowledge — active retrieval, not passive storage. The value isn't in the files. It's in Claude checking them mid-session before making a recommendation.

After a month, I had a folder with 24 rules Claude applied automatically. I didn’t write those rules. They emerged from dozens of sessions. Claude was measurably better than day 1 — not because of better prompts, but because the system had been learning the whole time.

Want to build with Claude? Join our AI Agents Claudathon — ship real agentic products with Claude Code. No experience required. Limited to 60 students.

Learn more

2. Decision Journal — Reviewable Reasoning

The problem: Someone asks why you picked Postgres over DynamoDB. Or why you killed the freemium tier. Or why the onboarding flow skips the team invite step. Nobody remembers. So you spend 30 minutes re-debating a decision that was already made.

The snippet:

When about to make a decision that affects more than today's task,
first grep /decisions/ for prior decisions in that area. 
Follow them unless new information invalidates the reasoning.

If no prior decision exists — or you're replacing one — log it:

File: /decisions/YYYY-MM-DD-{topic}.md

Format:
  ## Decision: {what you decided}
  ## Context: {why this came up}
  ## Alternatives considered: {what else was on the table}
  ## Reasoning: {why this option won}
  ## Trade-offs accepted: {what you gave up}
  ## Supersedes: {link to prior decision, if replacing}

How it works: If you’ve worked with Architecture Decision Records, this will feel familiar — same principle, enforced by Claude instead of team discipline.

When decisions get replaced, the Supersedes field creates a traceable chain. suggested this addition and the retrieval-first ordering, and both made the journal sharper.

A month in, the patterns surprised me. The decisions I was most confident about had the worst hit rate. The ones where I forced myself to write out three alternatives before choosing were right 80% of the time.

Keep reading with a 7-day free trial.

What’s inside the paid section:

• The third block — Quality Gate — and why Claude can’t evaluate its own work without it

• A self-maintenance instruction that keeps the whole system from going stale

• How the three blocks reinforce each other (the compounding thesis)

• The full integrated CLAUDE.md — all three blocks + schedule suggestion, ready to paste

3. Quality Gate — Evaluation Criteria That Compound

The problem: Claude finishes a task and tells you it’s done. You ask if the work is good. Claude says yes — confidently, every time.

Anthropic’s own engineering team documented this: when asked to evaluate work they’ve produced, agents confidently praise it — even when the quality is mediocre. The agent that built the thing can’t objectively evaluate the thing.

Read more

Unless you’ve been living under a rock, you’ve noticed the PM role is expanding. At every company I’ve advised, I’ve watched PMs become increasingly responsible for driving business outcomes — not just shipping features.

AI accelerates this: as time spent on Jira, PRDs, and standups compresses, what remains is the work that actually moves revenue. Pricing and monetization sit at the center of that shift.

I experienced this firsthand at Ideals — the best company I ever worked for. We had current plans, newer plan versions, and historical plans where customers were being migrated over time. The logic of what each customer can do and see lived in the source code.

A single pricing change triggered changes across many systems, required close collaboration across multiple teams, and testing across all plan types and user roles. Everything worked, but each change was a company-level effort, not something a single team could handle.

The insight that stayed with me: what would really help is decoupling entitlements and features from the source code — separating what a customer can access from the implementation that enforces it. That’s the core principle this article teaches.

The vision: instead of pricing changes being organization-wide efforts, PMs can experiment with packaging as comfortably as they’d run any other product experiment — without generating work for other teams, without the QA burden. Pricing iteration at the speed of product iteration.

The thesis is simple: pricing should live in config, not code. Defined once, inherited everywhere — from the pricing page to the billing system to the feature gate in your code.

Subscribe now

I wrote this piece with Fynn Glover, founder & CEO of Schematic and author of the The Pricing Playbook for AI & SaaS — with contributors from Superhuman, Stripe, Cursor, Vercel, and Supabase. Fynn has worked with teams at Zep, Plotly, and Automox, and interviewed pricing leaders at Vercel, Notion, Calendly, and Salesloft. The framework, case studies, and pricing stories here are his — told in his voice.

Hey, Fynn here.

Vercel ships five to six pricing changes per month. Most companies ship one or two per year — and each one takes a quarter of engineering time.

Last year I sat in a pricing review where the team had a brilliant idea: move three features from Enterprise to Pro, add a usage cap on API calls, launch an add-on for analytics.

The strategy was sound. Data supported it. Everyone agreed.

Then engineering said: “That’s a quarter of work.”

I’ve seen this at dozens of companies I’ve worked with. The pricing strategy takes a week. The pricing change takes a quarter. By the time it ships, the market has moved.

This isn’t a strategy problem. It’s an architecture problem. And this post is the blueprint for fixing it.

What You’ll Learn

This is a deep dive into the architecture that separates companies shipping pricing changes in hours from those stuck in quarterly cycles:

1. The three failures that compound — when your pricing architecture is broken, and why AI makes the urgency real

2. The four pillars of monetization architecture — unified catalog, decoupled entitlements, real-time metering, and a control plane — with PM tests for whether yours is broken

3. Decoupled entitlements in practice — real production code showing what it looks like when pricing lives in config, not code

4. Three case studies — Zep (trial to production in 4 days), Plotly (two AI products, two quarters faster), Automox (pricing paralysis to 75% faster launches)

5. The monthly pricing meeting — 2 hours, 4 blocks, copy-paste ready — the operating system for making pricing a function, not a project

6. Build vs. buy matrix — and an honest “when you don’t need this” section

1. The Three Failures That Compound

When I ask founders where their monetization bottleneck is, they blame their billing tool or their CPQ (configure-price-quote tool). They’re pointing at the symptom, not the cause. In reality, they have a pricing architecture problem. It shows up in three ways:

The strategic failure. You’re leaving money on the table. Most companies review pricing once a year. Your product ships features monthly, costs change quarterly, competitors adjust continuously.

The operational failure. No owner, no cadence, no muscle. It looks like the “pricing committee” meeting — VPs of Product, Sales, Marketing, and Finance gather for a three-hour debate. Everyone has an opinion. No one has the autonomy to make a decision. The default answer is “let’s do nothing for now.” Justin Talerico, CEO of Automox, described delaying pricing and packaging work for two years — despite having a strong pricing analysis — because they couldn’t action the recommended changes in the product.

The architectural failure. Even when you have the right strategy and the will to act, your codebase won’t let you. R&D teams pour millions into “Monetization Plumbing” that delivers zero core product value. Jalal Iftikhar, who leads Business Technology at Notion, puts it sharply: “Usage-based billing systems are designed to consume events from products to then inform invoices. They’re not designed to enable the commercial tinkering on pricing & packaging that drives growth.”

At my last company, the monetization stack was a complex web of disconnected product catalogs, multiple billing & quoting systems, hard-coded entitlements, and homegrown metering — Stripe, NetSuite, Amplitude, Salesforce, Salesforce CPQ, a homegrown metering system nobody trusted, and Gainsight. Eight systems.

Count how many of these you recognize in your own stack. Most Series B+ companies are running some version of this — a half-dozen disconnected systems, each a different source of truth for a different team. Thousands of lines of hard-coded billing logic. Different teams thought they were managing monetization, but in reality, no one owned it. No one could own it.

One tier launch took six months. An add-on initiative was abandoned entirely.

The truth hiding inside most fast-growing companies: pricing agility = revenue agility, and hard-coded pricing and billing logic is the choke point.

Fix the architecture, and the other two failures become solvable. Making pricing a function — not a project — requires one owner, one cadence, one set of metrics. Later in this article, the monthly pricing meeting format gives you the exact operating system for this.

2. The Compounding Cost of Inaction

Even when the math is clear, most teams still can’t act. The board pushes to raise prices. The team knows the product is worth more than two years ago. But fear of churn paralyzes the decision.

I lay out a simple comparison in my book. Imagine a company at $10M ARR (annual recurring revenue) with 200 customers. Two paths:

• Path 1: Price Lift. Raise prices 20%. Even with 4% churn, the net result: $1.6M in new ARR.

• Path 2: The “Safe” Add-On. Launch a $10K/year add-on. Sell to 25% of your base. Result: $500K in new ARR. No churn — but one-third the impact.

The $1.1M gap isn’t a one-year number. That higher price becomes the new baseline. Every renewal, every expansion dollar compounds on top of it. At 7% annual growth, that initial 28% lift turns into roughly 39% uplift within five years.

Superhuman waited six years to raise from $30 to $40. One decision. 4% churn. 28% overnight lift. The compounding effect will reshape their revenue curve for years.

As Justin Gagnon, who leads Growth Engineering at Calendly, puts it: “Monetization should be a first-class citizen as early as humanly possible... If you don’t get it right early, you’re paying down your bad decisions late. And when you’re paying down bad monetization decisions, it’s way more expensive than paying down other bad decisions.”

This is why pricing inaction is the most expensive decision most companies make — and why the architecture that enables fast, confident pricing changes is the highest-leverage investment you’re not making.

Subscribe now

3. Why AI Changes the Equation

AI is making this worse — and if you’re a PM shipping AI features, you’re feeling it already. Traditional SaaS has deterministic costs: a user creates a project, you know what it costs to serve. AI workloads are probabilistic. A query might cost $0.001 or $0.50 depending on context length, model choice, and retry logic. Gross margins can swing from 90% to below 50%.

(Growth Unhinged) calls it the pricing reformation: with AI, undercharging can make customers unprofitable. The biggest players are experimenting in public, changing pricing monthly. The hybrid future — platform fees plus usage, seats plus credits, consumption plus pay-as-you-go — demands architecture that can handle it.

Shar Dara puts it plainly: “Billing was hard, and is hard still. Historically, traditional SaaS businesses were able to get away with updating pricing every year or so, but that just can’t cut it anymore. Pricing changes cannot be on the back burner with AI in the mix.”

The companies winning — Vercel, Clay, Supabase — treat pricing as a continuous function. Test Monday, measure Wednesday, roll back Friday. That speed is an architecture capability, not a strategy one.

4. The Four Pillars of Monetization Architecture

So what does a pricing architecture that actually works look like? The clearest framework I’ve seen comes from Shar Dara, who leads billing at Vercel, and Ben Papillon, Schematic’s CTO — presented at the Monetizing AI Summit.

Shar opened bluntly: “Traditional SaaS could update pricing once a year. In the AI era, that’s impossible. At Vercel, we average five to six pricing changes per month — new SKUs, add-ons, packaging tweaks. You need architecture that can keep up.”

Ben added: “If pricing agility is important, you need an architecture that lets you change how you price without rewriting your product.”

Together they mapped the four biggest blockers:

• multiple sources of truth (PLG (product-led growth) stack, SLG (sales-led growth) stack, CPQ (configure-price-quote) tools — each storing its own prices)

• SKU sprawl (too many product variants to track)

• hard-coded entitlements — access rules controlling what each customer can do — scattered through the code (if plan x... metastasizing everywhere)

• inconsistent UX across checkout and upgrade flows.

Their answer: a unified, four-layer architecture:

The diagram below shows how these pillars connect in practice — plan subscription, entitlement checking, and usage tracking all flowing through a central platform:

Pillar 1: Unified Product Catalog

A single schema describing every plan, feature, entitlement, and price. It’s the canonical source for billing, provisioning, analytics, and go-to-market (GTM). When product and billing share one catalog, new SKUs appear everywhere instantly.

Shar summed up the source-of-truth problem: “If you don’t define a single source of truth early, you end up with incidents every time you change price.”

PM test: Can marketing update the pricing page and have it reflected in what customers get — without an engineering ticket?

Pillar 2: Decoupled Entitlements

The heart of it. Entitlements are the rules that control what each customer can access in your product: Can this user use feature X? How many seats do they get? Can they create more projects? Every SaaS product enforces these rules — but most hardcode them, scattering access logic across the codebase.

In practice, feature access falls into three categories:

• Boolean features are the simplest — a customer either has access or they don’t. SSO, advanced reporting, a specific AI model. On or off, determined by plan.

• Trait-based features enforce allocation limits — the numbers on your pricing page. Seats, projects, teams. These define what a company has. When you check “Can this user create another project?” you’re checking a trait against a limit.

• Event-based features enforce consumption limits — API calls made, tokens consumed, storage used. These track what a company does. When you check “Has this user exceeded their monthly API limit?” you’re checking cumulative events against a cap.

Most teams hardcode all three types — and that’s where pricing changes become engineering projects.

The fix: decouple that logic from code. Store feature access rules centrally and query them at runtime.

Instead of this, repeated for every feature and plan:

if (planId == Plans.Enterprise) {
  enable_feature_x();
} else if (planId == Plans.Pro) {
  // ...
}

Your code becomes a single, clean call:

const { enabled } = useEntitlement("reports");
if (enabled) {
  showReportButton();
}

As Ben Papillon puts it: “Entitlements start as a pebble in your shoe and become cement around your feet. You can’t move.”

The architecture also eliminates a hidden performance cost. Traditional entitlement checks add 50-100ms latency per API call and create a single point of failure.

A streaming approach changes the game: entitlement state is streamed on startup and maintained continuously. Every check becomes a local memory read — latency disappears. If the entitlement service goes down, your app keeps running with last known state. For customers, this means instant feature access. For engineering, it means one less thing that can break at 2am.

Traditional entitlement checks (50-100ms latency) vs. Streaming approach (no latency)

PM test: Can a non-engineer move a feature from Pro to Enterprise — or change a seat limit — without a code deploy?

Pillar 3: Real-Time Metering

AI workloads generate probabilistic consumption. Real-time metering gives customers transparency and finance predictability.

This is critical because, as Marcos Rivera of Pricing I/O describes: “The ‘oh shit’ moment everyone’s worried about is that huge, unpredictable bill. It’s nerve-wracking to go into an agreement and not know how much you’re going to use. Real CFOs don’t buy that way.”

Your architecture must solve this anxiety. That means three things:

• Event ingestion at scale. Every billable action — API calls, tokens consumed, compute minutes — gets tracked the moment it happens. Not batched overnight. Not reconciled at month-end. Real-time.

• Usage tied to billing periods. Metering without context is just a counter. Good metering knows that a customer’s “month” runs from their signup date (say, March 15 to April 14), not the calendar month. It tracks consumption against their specific allocation and resets automatically.

• Exposure to both sides. Customers see usage against their limit — before the surprise invoice. Sales sees a customer approaching their cap — before they churn. Finance sees margin data in real time — before the quarterly surprise. Same data, different views, one truth.

Tools like Schematic, Metronome, and Orb handle event ingestion, period-aware aggregation, and real-time usage APIs out of the box. Building this in-house is a common source of “metering debt” that quietly eats engineering quarters.

PM test: Can a customer see usage against their limit before the surprise invoice? Can sales see a customer approaching their cap before they churn?

Pillar 4: A Control Plane for Product Teams

Let non-engineers manage monetization. This is the layer that turns the other three pillars from an engineering tool into a business capability.

Here’s what it looks like in practice: your head of growth wants to test whether doubling the free tier’s API limit increases conversion. Without a control plane, that’s an engineering ticket, a sprint planning discussion, a code change, a deploy, and a rollback plan. Two weeks minimum. With a control plane, they log into a dashboard, change the limit from 1,000 to 2,000, and it’s live. If conversions drop, they revert in 30 seconds.

The same applies to sales. An enterprise prospect wants a custom package — 500 seats, unlimited projects, a higher API cap. Instead of filing a ticket and waiting for eng to create a custom plan, sales configures it directly and sends the proposal the same day.

A good control plane provides: plan and SKU creation, limit and tier adjustments, entitlement overrides for specific customers, experiment management, and full audit logs so everyone knows what changed, when, and why.

PM test: Can you launch a pricing experiment this week — not “get approval,” actually launch?

—

These four pillars aren’t independent — they’re layers. The catalog defines what exists. Entitlements control who gets what. Metering tracks how much they use. The control plane lets your team manage all three without engineering. Break one layer and the others compensate poorly. Build all four and pricing becomes a continuous function.

5. Decoupled Entitlements in Practice

To see what this looks like in practice, here’s a real example using Schematic’s React SDK — a single component that handles entitlement checking, loading states, usage limits, and feature gating. The pattern is the same regardless of which entitlement platform you use: replace hundreds of lines of plan-checking logic with a single hook:

This is real production code. Centralized entitlement checks work like feature flags, but for billing logic. You can display UI conditionally based on usage and limits, and surface usage and allocation data to end users — all from a single hook.

The entitlements system supports overrides, grants, scheduled access, and revocation — all managed by Product, Finance, and GTM teams through the control plane, with full audit logs:

This simple pattern replaces hundreds of lines of brittle logic. It also allows business users to change packaging without touching code.

Subscribe now

6. Before and After Decoupling Entitlements

7. When You Don’t Need This

One plan, no usage component — Stripe + hardcoded checks are fine.

Pure per-seat — skip metering. Start with entitlements + catalog.

Under 10 people — config file + Slack = your control plane.

Pre-PMF — fix entitlements (Pillar 2) because that’s debt regardless. Don’t build the full stack until pricing is worth iterating on.

Heuristic: if pricing changed fewer than twice last year, you have a strategy problem before an architecture problem.

8. How to Build Monetization Architecture: A 5-Step Roadmap

Step 1: The Entitlements Audit (Weeks 1-2)

Search your codebase for if (plan == ...) and count what you find. That number is your pricing debt. Map which features are gated, how they’re gated, and how many places the logic is duplicated.

Step 2: Extract to a Centralized Service (Weeks 3-4)

Replace hardcoded checks with a single entitlement service your app queries at runtime. Start with Pillar 2 because it’s engineering debt blocking you now — the product catalog (Pillar 1) is a design problem you can solve in parallel. This is where dedicated entitlement platforms come in — tools like Schematic that treat access rules as infrastructure rather than application code.

Step 3: Unify the Product Catalog (Pillar 1)

Single source of truth for plans, features, and prices — independent of Stripe. When product and billing share one schema, new SKUs appear everywhere instantly.

Step 4: Add Metering (Pillar 3)

Only if you have a usage component. Connect events to your catalog so usage flows into billing automatically.

Step 5: Build the Control Plane (Pillar 4)

This is where compounding happens. Non-engineers can now create plans, adjust limits, and run experiments without engineering tickets. Test Monday, measure Wednesday, roll back Friday.

9. Case Studies

Zep — Trial to Production in 4 Days

Zep builds long-term memory for LLMs. Usage unpredictable, metered billing not optional.

Before: lost revenue from untracked usage, frustrated sales team, engineering pulled into billing plumbing.

Timeline:

• Day 1: Trial start. Connected Stripe, modeled plans/entitlements.

• Day 4: Live in production.

• Day 7: Annual plan conversion.

• Day 30: All plans on Schematic.

Results: free-to-paid conversions from limit enforcement, proactive sales outreach, engineers back on core product.

Daniel Chalef (founder): “We were able to integrate Schematic into our workflow within a couple of days.”

Plotly — Two AI Products, Two Quarters Faster

Plotly saw the same pattern. When the team decided to launch two AI-powered products, the old approach would have meant parallel billing pipelines, separate entitlement systems, and months of integration work.

With their product catalog and entitlements already modeled centrally, the launch sequence was additive: define the new features, set the usage limits, configure the tiers, and ship.

Both AI products launched two quarters ahead of the previous timeline — not because the team worked faster, but because the architecture didn’t fight them.

Automox — From Pricing Paralysis to 75% Faster Launches

Automox — a mid-market IT management platform backed by Insight Partners and Koch — spent four years deferring pricing changes. Not because they lacked data. They had pricing studies and clear packaging recommendations ready to go. The problem was purely architectural.

Their monetization logic was hardcoded across the application, split between two separate billing systems — one for e-commerce, one for sales-led motions — with entitlements buried in config files. The result: redundant plans, inconsistent customer states, and a three-month minimum lead time for any pricing tier change. Two full-time engineers were consumed just keeping the plumbing running.

Co-founder Jay Prassl called it “pricing and packaging sclerosis.” The CMO put it more bluntly: even when they had data-driven packaging recommendations, they couldn’t act on them. The architecture had become a veto on the business.

The cascade was textbook. Monetization initiatives — new tiers, add-ons, custom configurations — piled up in the backlog. Customers on older plans faced inconsistent feature access and billing visibility issues, driving support load and churn risk. Revenue sat on the table because the systems wouldn’t let anyone pick it up.

After migrating to Schematic, Automox cut time-to-launch for new pricing tiers by 75% and freed two full-time engineers from maintenance work — turning monetization from a blocked backlog item into something they could actually iterate on. Their growth team could now launch, package, meter, and monitor features from one place without constantly involving engineering.

Brian Wleklinski, Senior Manager of Growth & Digital: “Schematic has transformed how we manage our pricing and packaging. The ability to iterate quickly and provide our customers with a seamless experience has been invaluable.”

10. The Monthly Pricing Meeting

This is the section I’d print out and bring to your next leadership meeting. It’s the operating system for the ownership problem. Two hours, once a month, four blocks:

Block 1: Customer Data (30 min). Usage trends, billing data, approaching-limit customers. High usage + low ARPU (average revenue per user) = expansion candidates. Low usage + high ARPU = churn risk.

Block 2: Learnings Scan (30 min). What sales, CS, and finance are hearing. Win/loss patterns. Feature requests tied to pricing friction.

Block 3: Product → Pricing Roadmap Sync (30 min). What’s shipping in the next 30-90 days? Which tier should it live in? Does it shift the value metric? Does it need to be an add-on? Rule: no feature ships without a monetization stance. This prevents “free value leakage.”

Block 4: Conclusions and Decisions (30 min). This meeting only creates leverage if it creates action. Choose 1-3 actions for the next 30 days. Each action must have: an owner, a hypothesis, a timeline, and expected impact.

Key distinction — two speeds: Global changes (new pricing page, tier restructure) are infrequent and high-stakes. Local changes (adjust a limit, test an add-on, run a promotion) should happen continuously. Most of your monthly meeting actions should be local experiments.

Attendees: CEO/CPO, Sales, CS, Finance/RevOps, Marketing, Growth.

Outputs you leave with: A synchronized product + pricing roadmap. A unified view of revenue opportunities and risks. 1-3 local experiments with owners and timelines. A continuously updated pricing backlog.

How to Measure Success

Pricing-change velocity: “should change” to “it’s live.” Target: under 1 week.

Billing uptime: 99.999%.

Billing support tickets: The canary. If you can’t hit those numbers, you don’t have an asset — you have a liability.

Subscribe now

11. Build vs. Buy Monetization Architecture

12. Closing

Most founders think about pricing strategy. Almost none think about pricing architecture. But here’s what I keep seeing: your architecture determines your strategy. If your systems can’t move, your pricing can’t move, and your revenue stays stuck.

Kurt Smith, the CEO of Fexa, once said something I find both true and haunting: “Think about all the creative pricing & packaging conversations in SaaS & AI companies that have simply stopped happening, because people have accepted that even if they had good ideas, their systems would make testing those ideas impossible.”

Your architecture doesn’t have to be the reason good pricing ideas die.

You’ve been running the entitlements audit in your head while reading this. Now do it for real. Block 30 minutes this week, search for if (plan ==, and count what you find. That number is your starting point. This article is the blueprint to pay it off.

— Fynn

Thanks for Reading The Product Compass

Hey, Paweł here again. It’s amazing to learn and grow together.

If this surfaced pricing debt you've been ignoring, start here: https://schematichq.com/book (free download)

And consider subscribing, if you haven’t already:

Subscribe now

Have a great week ahead!

— Paweł

I mapped every release since February 1st to a shipping calendar — dates, features, team attribution. Not by reading changelogs. By going through the feeds of the people actually shipping.

What stands out isn't any single feature. It's the velocity across every surface at once:

→ Developer tools (Claude Code) — 28 releases
→ Desktop automation (Cowork) — 15 releases
→ API and infrastructure — 18 releases
→ Models and core platform — 13 releases

No team is waiting for the other. They're all shipping in parallel:

For PMs, this creates a compounding gap. Every week you don’t explore Dispatch, Scheduled Tasks, or Computer Use is a week someone else does. The PM who builds a self-improving CLAUDE.md system today has an automation layer that gets better with every release. The PM who waits builds from scratch each time.

This isn't about picking the "best AI tool." It's about recognizing when one platform's shipping velocity makes the decision for you.

My Claude Guides

If you want to go deeper on any of these surfaces, I’ve written complete guides for PMs:

• Claude Cowork Guide for PMs — the desktop agent that works with your files, apps, and connectors

• Claude Code: The Complete PM Guide — the CLI/IDE agent for technical work

• The Self-Improving Claude AI System — how to build a knowledge system that compounds across sessions

• The Claude Dispatch Guide for PMs — the always-on persistent agent that runs while you’re away

Subscribe now

Timeline & Everything You Might Have Missed

Feb 3 – Feb 9

CC Session Sharing: Share Claude Code sessions with teammates for collaborative debugging and pair programming.

Cowork Slack MCP on Paid Plans: Access Slack messages, channels, and search directly from Cowork on all paid plans.

Cowork GSuite Connectors: Connect Gmail, Google Calendar, and Google Drive to Cowork for cross-app workflows.

CC /insights Command: Get AI-generated analysis of your codebase’s architecture, patterns, and dependencies.

CC Agent Teams: Spawn multiple Claude Code agents that work in parallel on different parts of a codebase.

CC /debug Skill: Auto-diagnose failing tests and runtime errors with a dedicated debugging workflow.

Opus 4.6: New flagship model with improved reasoning, coding, and instruction-following across all Claude surfaces.

CC /rewind: Press ESC twice to summarize and compress your conversation context instead of losing it.

CC Fast Mode: Optimized response mode that trades depth for speed on routine coding tasks.

Fast Opus 4.6: Early preview of Opus 4.6 running 2.5x faster than the standard version.

Feb 10 – Feb 16

Cowork for Windows: Cowork desktop app now available on Windows alongside the existing Mac version.

CC --dangerously-skip-permissions: Run Claude Code with auto-approved tool use for fully autonomous, unattended workflows.

CC Contribution Metrics: Track how much code Claude wrote versus you across your project’s history.

Free Plan Expansion: Free users get file uploads, connectors, and skills in Cowork.

Cowork Folder Instructions: Drop a CLAUDE.md file into any folder to give Cowork persistent, project-specific context.

CC Slack App (Plan Mode): Use Claude Code’s plan mode directly from Slack to scope technical work before executing.

CC Desktop Local Plugins: Install and run local MCP-based plugins on the Claude Code desktop app.

CC Multi-Repo: Work across multiple repositories in a single Claude Code web session.

CC SSH Support: Connect the Claude Code desktop app to remote development machines over SSH.

Subscribe now

Feb 17 – Feb 23

Sonnet 4.6: New mid-tier model balancing speed and quality, available across all Claude surfaces.

CC Sonnet 4.6 Support: Sonnet 4.6 available as a selectable model option in Claude Code with early benchmark results.

CC Figma MCP: Push Claude Code outputs directly into Figma for design-development handoff.

Claude in PowerPoint: Create and edit PowerPoint slides directly within the Claude interface on Pro plans.

CC Security (Research Preview): Automated security scanning that identifies vulnerabilities in your codebase before they ship.

CC Desktop Preview Apps + CI/PRs: Preview running applications and handle CI/CD and pull request workflows from the desktop app.

CC Worktrees: Built-in git worktree support so agents can work on parallel branches without switching context.

Feb 24 – Mar 2

CC Remote Control: Control Claude Code sessions from your phone — review, approve, and guide agents on the go.

Enterprise Customize + Marketplaces: Enterprise admins can customize Claude behavior and create private plugin marketplaces for their org.

Cowork Scheduled Tasks: Schedule recurring Cowork tasks that execute automatically on a cadence you define.

CC Auto-Memory: Claude Code automatically remembers your preferences, codebase patterns, and project context across sessions.

CC Claude for Open Source: Free Claude Code access for qualifying open source project maintainers.

CC /simplify + /batch: Refactor complex code into simpler patterns (/simplify) or run the same operation across many files at once (/batch).

CC AskUserQuestion Snippets: Claude Code shows formatted markdown previews with code snippets when asking you clarifying questions.

Memory on Free Plan: Persistent memory across conversations now available to all free-tier Claude users.

Mar 3 – Mar 9

Voice Mode: Talk to Claude Code using push-to-talk voice input instead of typing commands.

CC HTTP Hooks: Fire HTTP webhooks on Claude Code events — connect sessions to Slack, CI pipelines, or any external system.

CC Local Scheduled Tasks: Schedule recurring tasks that run automatically on your machine while your computer is awake.

Enterprise Marketplace: Enterprise customers get a curated marketplace of approved plugins and integrations for their org.

CC /loop: Set Claude Code to continuously iterate on a task — building, testing, and fixing in a loop until your tests pass.

CC Auto Mode: Claude Code automatically selects the right execution approach without requiring manual mode switching.

CC Code Review (Multi-Agent): Multiple Claude agents analyze your pull request in parallel, each reviewing different aspects of the code.

Mar 10 – Mar 16

CC /btw: Send Claude a side note mid-task without interrupting its current work — corrections, context, or new info.

CC /effort: Control how deeply Claude thinks — from quick one-shot responses to extended multi-step reasoning.

Cowork Excel + PowerPoint Sync: Edit Excel spreadsheets and PowerPoint decks in Cowork with cross-file synchronization.

Interactive Charts: Claude can now build interactive charts, diagrams, and visualizations directly in chat. HTML-based, editable, available on all plans.

Rich Text Output: Claude no longer defaults to plain text — responses now include interactive charts, formatted tables, and rich media.

CC Setup Scripts: Add a setup script that runs automatically when Claude Code initializes in your project directory.

Voice Mode on Desktop + Cowork: Push-to-talk voice input now available on the Claude desktop app and in Cowork sessions.

1M Context Window GA: One-million-token context window generally available across all paid Claude plans.

CC Opus 1M Default: Opus 4.6 with 1M context is now the default model in Claude Code.

CC Session Spawning: Spawn new local Claude Code sessions directly from the mobile Remote Control app.

CC /color: Customize your Claude Code terminal with color themes and visual preferences.

CC Review Manual Trigger: Type @claude review in any PR comment to trigger a multi-agent code review on demand.

CC MCP Elicitation: MCP servers can now ask Claude Code for additional context during tool execution instead of failing silently.

2x Usage: Double usage limits during off-peak hours for all paid plan subscribers.

Subscribe now

Mar 17 – Mar 23

Cowork Dispatch: A persistent, always-on Claude conversation that runs on your computer — continues working even when you close the app.

CC Output Tokens 64K: Maximum output token limit increased to 64K for longer generated code and responses.

Opus 1M on Desktop: Opus 4.6 with 1M context now available on the desktop app for Max, Teams, and Enterprise users.

Dispatch + CC Sessions: Dispatch can now launch and manage full Claude Code sessions alongside its standard Cowork tasks.

CC Shell in SKILL.md: Embed live shell command outputs directly in skill files using !command syntax for dynamic context.

Claude.ai Speed Boost: Claude.ai and desktop apps load significantly faster after migrating from SSR to Vite + TanStack Router.

CC VSCode Remote: Use Remote Control to manage Claude Code sessions running inside VS Code from your phone.

CC Skills over Remote Control: Run skills and slash commands from your phone via Remote Control — full command access on mobile.

CC Channels (Telegram + Discord): Connect Claude Code to Telegram and Discord — interact with your coding agent from messaging apps.

CC Cloud Scheduled Tasks: Schedule recurring Claude Code tasks that run in the cloud — no local machine required.

Projects in Cowork: Organize Cowork conversations into named projects for better context separation and management.

CC DOM Element Selection: Select DOM elements directly from a running application to reference them in Claude Code conversations.

CC Effort in Skills: Set effort levels directly inside skill and slash command definitions to control reasoning depth per task.

CC /loop 7 Days: Loop sessions now run for up to 7 days instead of the previous 3-day limit.

CC /init v2: Redesigned project initialization that interviews you about your codebase before generating CLAUDE.md configuration.

CC /schedule Cloud: Schedule cloud-based tasks directly from the /schedule command — tasks run on Anthropic’s infrastructure.

Computer Use: Claude can now control your computer directly — mouse clicks, keyboard input, and screen reading for end-to-end automation.

CC Channels Permission Prompts: Channels now support permission prompts so you can approve sensitive actions from Telegram or Discord.

Mar 24 – Mar 30

CC Channels for Teams + Enterprise: Channels (Telegram, Discord integration) now available for Teams and Enterprise plans.

And the week continues.

[Edited] Here we go, not included in the infographic:

CC Auto Mode (Research Preview): Claude autonomously handles permission prompts during coding. A pre-execution classifier reviews every tool call, blocking destructive operations and prompt injection. Enable with `claude --enable-auto-mode`.

P.S. Glad Claude Team noticed this. Noah is the legend:

Subscribe now

Have a great rest of the week,
Paweł

Dispatch is the newest surface — and the one most likely to change how you work as a PM. Not because it’s the most powerful, but because it turns every gap in your day into a window for directing real work. Dog walks, coffee, the passenger seat, standing at the sidelines of a bounce house — all become productive without being “always on.”

I tested this for 48 hours straight, building real PM workflows from my phone. What you’re reading is everything I found — the workflows that actually work, the friction points nobody warns you about, and the architectural insight that matters more than any single feature Anthropic ships.

What You’ll Learn

• What Dispatch actually is — and the difference from “Claude chat on your phone”

• How to set up and start your first Dispatch session

• The real 48-hour timeline — how async direction reshapes your day

• Every gotcha I hit, with tested workarounds

• When to use Dispatch vs. Web Sessions vs. Channels vs. Code

• Why the knowledge layer matters more than any single surface

• The single highest-leverage investment for PMs building with AI

If you haven't read the earlier parts of this series, they help but aren't required — this post stands alone:

• Claude Cowork Guide — the desktop agent Dispatch controls remotely

• Claude Code: The Complete PM Guide — how to start

• The Self-Improving Claude System — the knowledge architecture that makes all of this compound

Subscribe now

1. What Dispatch Is (And Isn’t)

Dispatch isn’t “Claude chat on your phone.” You already have that.

Dispatch is an orchestrator. From a single conversation on your phone, you spawn and manage multiple Cowork task sessions running simultaneously on your desktop. Each session runs independently — its own context, its own file access, its own connectors.

Your phone is the command chair. Your desktop does the heavy lifting.

Think of the difference between texting someone a request and sitting in a control room with multiple screens. Each screen is a task session running on your desktop. Your phone directs all of them from one conversation thread.

For PMs: This maps to something you already do — running multiple workstreams simultaneously. One analyst pulling competitor data. Another drafting the stakeholder email. A third organizing research notes. Dispatch is that, except the analysts are AI sessions on your desktop and the command chair is in your pocket.

Every Cowork connector you've configured — Gmail, Notion, Slack, all of them — works through Dispatch because Dispatch delegates to Cowork.

Subscribe now

2. How to Set Up Claude Dispatch

Step 1: Set up Cowork on your desktop with the connectors you use — Gmail, Notion, Slack, whatever your stack is. Everything must be configured on desktop first. Then, keep your desktop awake and Claude app running.

Step 2: Open the Claude mobile app. You’ll see the Dispatch tab. Start a conversation and tell it to run a Cowork task.

Step 3: Start small. One task (e.g., “summarize unanswered emails from the last week”). See the output. Then try running two tasks from the same conversation to feel the parallel workflow.

Step 4: To work with files, grant folder access — describe the folder naturally (”go to workspace/editor”) or use a shortcut you’ve defined. Start with the folder that has your CLAUDE.md and knowledge files.

Step 5: Set up your workarounds early:

• If your workspace syncs via Google Drive/Dropbox/iCloud, check that files appear on your phone — this eliminates the file transfer problem entirely

• Define folder shortcuts (”editor mode,” “workspace”) so you describe folders naturally instead of typing paths

3. Real PM Workflows With Claude Dispatch (48-Hour Test)

Dispatch didn't fill my dead time. It changed how I structured my day. I went to the jump arena with my kid because I could direct work async from the sidelines. The model isn't "grind during gaps." It's "design your day differently because the work runs without you sitting in front of it."

Here's what that looked like:

Read more

5.2 million impressions on X. 35,000 likes. 43,000 bookmarks. 7.2% engagement rate. In three months. Most of that growth happened within the last 6 weeks.

Not from writing more. Not from better prompts. From building a system that compounds.

[Edited] After publishing this article:

I'm going to show you what that system looks like, how it evolved, and why the architecture matters more than the content it produces. You can drop the whole structure into Claude and use it directly, or treat it as inspiration to build your own.

I'll use content creation as the case study — but the pattern works for customer research, competitive intelligence, market analysis — any domain where knowledge compounds.

This is Part 3 of my Claude for PMs series. New to the tools? Start with Part 1: Cowork and Part 2: Claude Code.

In this post, we discuss:

1. How Agentic Systems Learn from Real-World Data

2. How a Claude Knowledge System Compounds Over Time

3. Architecture: File-Based Knowledge Graph

4. 2x Usage: The Best Time to Start with Claude

5. What We’ll Learn Next

6. How This AI System Evolved in 3 Phases

7. Building Custom AI Tools with Claude Code

8. Cross-Surface Workflow: Claude Code, Cowork, and Web

9. Hypothesis Tracking: How the System Stays Honest

10. How to Build Your Own Claude Knowledge System

11. Why Self-Improving AI Systems Win

1. How Agentic Systems Learn from Real-World Data

The workflow is simple:

Pull data → organize knowledge → let the system learn → compound over time.

X (Twitter) content is where I tested it. But the same architecture works for:

• Customer interviews — After 50 interviews, the system knows your product’s pain points better than your Confluence page.

• Competitive monitoring — Competitor moves instead of tweets. Pricing changes instead of LinkedIn posts. Patterns across weeks you’d miss manually.

• Market intelligence — Pull from APIs, browser scraping, manual input. Let the system self-correct as the market shifts.

AI handles the repetitive work — the research, the drafting, the data pulling.

What it can't do is decide what matters. That's your job. This system doesn't replace your judgment. It gives your judgment better inputs, faster, and those inputs compound over time.

2. How a Claude Knowledge System Compounds Over Time

The more you use Claude, the more it improves. Structure emerges. Knowledge files build up. It starts feeling less like using a tool and more like building a system that gets better every time you touch it.

I didn’t start with a master plan. I started by pasting screenshots into Cowork, asking “what makes this post work?” Raw, unstructured. Just curiosity.

But Claude started noticing patterns I missed. It flagged that negation hooks outperform positive hooks on LinkedIn. It noticed that data experiments get 3x more bookmarks than opinion posts. It spotted that my builder-teacher posts consistently outperform my analyst takes.

Over weeks, the system grew. Claude suggested reorganizing the files into a knowledge hierarchy. Then it suggested building a Python script to fetch tweet data cheaper. Then it started proposing edits to its own knowledge base.

Now the system has 26 content templates, 13 active hypotheses being tested with real data, 50+ catalogued false beliefs (things conventional wisdom says hurt but data shows don’t), and 7 topic lanes with energy tracking — all maintained by Claude, all improving with each use.

But "maintained by Claude" doesn't mean I stepped back. Here's what the collaboration actually looks like — I asked Claude to summarize who contributed what during a real session:

I decide every editorial call — what to post, what to kill, what angle to take, which facts need checking twice. Claude handles research, verification, structural options, and pattern-matching against the knowledge base.

AI compresses execution. The writing, the code, the analysis. What it can’t compress: knowing what to build. Knowing what to cut. Taste. Judgment.

The dev who writes code all day gets compressed. The dev who decides what code should exist becomes more valuable than ever. Same split applies to PMs. Same split applies to content. This is 10+ iterations per post. Not “write me a post about X.”

Share

3. Architecture: File-Based Knowledge Graph

What we built with Claude is a file-based knowledge graph with progressive disclosure. This is where I ended up after months — not where I started. You can drop this structure into Claude and use it as-is, or treat it as inspiration. Paste it in and Claude understands immediately what goes where.

Here’s what my repo looks like today:

Project Structure:

• CLAUDE.md is the brain. It defines the rules, the voice, the workflow. Everything Claude needs to know about how to operate.

• knowledge/INDEX.md is the router. It reads this first, then drills into only the folder that’s relevant to the current task.

• Each subfolder is a knowledge domain:

  • craft/ holds writing techniques.

  • voice/ holds 9 archetypes for matching tone to content.

  • platforms/ holds platform-specific rules, templates, and hooks.

  • posts/ holds performance data from analyzed content.

  • hypotheses/ holds what I’m testing next.

And here's how it flows:

Progressive disclosure means Claude doesn’t load everything. Context windows are finite — even at 1 million tokens, loading everything wastes attention. The system only loads what’s relevant to this specific task.

How to adjust this as a PM: Replace craft/ with discovery/. Replace voice/ with stakeholders/. Replace platforms/ with channels/. Same architecture, different labels.

4. 2x Usage: The Best Time to Start with Claude

Claude is offering double usage limits through March 27. Weekdays outside peak hours, all day on weekends. Automatic across Web, Code, Cowork, and mobile.

It's the best time to start building with Claude.

Subscribe now

5. What We’ll Learn Next

Here’s what’s behind the paywall — and why each piece matters:

• How Claude builds tools for you — Claude Code can call any API and wrap it into a reusable script. No MCP needed. I’ll show you how it works and when to say yes. (If you’ve ever wanted to pull data from an API but didn’t want to write code — this is how.)

• Automating Chrome without the 30-second waits — Claude Code controls your real browser through MCP. Direct DOM access, not screenshots. Setup takes 2 minutes. (If you’ve tried AI browser tools and hated the speed — this is different.)

• From generic prompts to a PM knowledge system — How to structure CLAUDE.md so it actually compounds: learning mode, hypothesis tracking, false beliefs. The principles and key snippets — not my full file, but everything you need to build your own. (If your Claude sessions start from scratch every time — this fixes it.)

• How the system stays honest — Hypothesis tracking that kills bad ideas with data. False beliefs that fight conventional wisdom. And one CLAUDE.md instruction that makes Claude propose improvements on its own. (If you want a system that challenges its own assumptions — this is how.)

• The three phases — How this evolved from pasting screenshots into Cowork to a system that learns. Where to start, what to expect at each stage. (If you’re starting from zero — this is your roadmap.)

• The cross-surface workflow — Same system from Claude Code, Cowork, and web. The tool doesn't matter — the shared context does. (If you've tried Claude in one surface and wondered how to connect them — this is it.)

Read more

The other 30% sounds more technical than it is. This guide walks you through the new interface and shows you what it unlocks.

(Haven't tried Cowork yet? Start with my Cowork guide for PMs. It'll make the transition smoother.)

What Is Claude Code?

Cowork and Claude Code share the same brain. The difference is where they live and what they can touch.

Cowork runs inside Claude Desktop — in a sandboxed VM. It works with files in your selected folder, connects to your apps, and handles knowledge work safely. Optimized for knowledge work — documents, research, and deliverables.

Code runs in VS Code (or the terminal). Same file access, but no sandbox — it runs bash commands directly, manages git, and gives you an Explorer sidebar to navigate your project visually. Optimized for codebases, prototyping, and engineering workflows.

The name is misleading. “Claude Code” sounds like it’s only for developers. It’s not. At Anthropic’s latest hackathon, an attorney, a cardiologist, and a roads worker won the Claude Code hackathon:

They won because they understood their problems deeply — and Code removed the friction between the idea and the build.

Why Bother with Claude Code?

Cowork is fantastic for knowledge work — email drafts, file creation, research, presentations. But you'll hit moments where it's not enough.

• You want to prototype. Cowork creates documents. Code creates working software. PRD to working demo in a single session. That’s what Anthropic PMs already do — they prototype in Claude Code instead of writing specs and waiting for engineering. Plan Mode lets you review before Claude changes anything.

• You want context that compounds. Cowork sessions start fresh (we discussed how to fix that). Code now has Auto Memory — it saves your patterns, preferences, and decisions across sessions.

• You’re working with engineers. Code speaks git natively. Prototype a feature, push to a branch, create a PR.

You can achieve some of the above in Cowork by installing developer plugins and Desktop Commander and adding custom instructions, but Cowork was not designed for those jobs.

If you only need email drafts, research results, and presentations, you can stay in Cowork. But if you’ve ever thought “I wish I could just build this myself” — Code is the bridge.

In this post, we discuss:

1. The Transition to Claude Code: Step by Step

2. What Genuinely Changes

3. Claude Code - Three Extra Tips

4. PM Power Moves

5. Honest Caveats — Where Cowork Is Still Better

6. Going Further — When You’re Ready

7. What’s Next

Subscribe now

1. The Transition to Claude Code: Step by Step

Step 1: Install VS Code

Download VS Code and install it. That’s it — no terminal commands, no configuration files. It’s a free editor that works on Windows, Mac, and Linux.

Step 2: Install the Claude Code Extension

Open VS Code, go to Extensions (Ctrl+Shift+X), search for “Claude Code” and install it.

Important: If you have GitHub Copilot Chat extension enabled, disable it. Having both active may create confusion when you start — two AI assistants competing for the same sidebar. Claude Code is the one you want.

Step 3: Connect Your Anthropic Account

You have two options:

• Subscription (most likely): You probably already have Claude Pro or Max. Claude Code will prompt you to sign in on first use — it opens a browser window, you log in with your claude.ai account, approve the connection, and you’re done. Your subscription usage applies.

• API key (pay-per-use): Go to console.anthropic.com → API Keys → Create Key. Then in VS Code: Command Palette (Ctrl+Shift+P) → “Claude Code: Set API Key” → paste it. You’re billed per token instead of a flat subscription.

Your web connectors (Gmail, Slack, Notion, etc.) carry over automatically from Cowork — they’re tied to your account, not to a specific app.

Step 4: Open Your Cowork Folder

File > Open Folder > navigate to the folder you’ve been using with Cowork.

Your CLAUDE.md is already there. The same instructions you wrote for Cowork work in Code. Claude reads them at the start of every session, just like before.

Step 5: Orient Yourself: What You’re Looking At

For comparison, this is what we saw in Cowork:

Here's what you see in VS Code:

Here’s what you see:

• Left panel: Explorer. Your files and folders — always visible, always navigable. This is what makes Code feel different from Cowork.

• Right panel: Claude Code extension. This is where you talk to Claude.

• Middle panel: A dedicated Claude Code CLI window. It's there when you want more control, e.g., configure local MCP servers. Don't start with it — the extension UI is easier.

• Bottom panel: System Terminal. You can close it for now.

Share

2. What Genuinely Changes

Once you're set up, most things feel familiar. Here's what actually surprised me.

Your Web Connectors Just Work

Whatever you connected in Cowork — Gmail, Slack, Notion — works here too. No reconfiguration. They're tied to your Anthropic account, not to the app. To see them, use the "/" menu:

Auto Memory Replaces Our Workaround

Remember how we set up cross-session memory in Cowork with Desktop Commander? That was a workaround.

Code has Auto Memory built in (it was just released). Claude automatically saves patterns, preferences, and decisions to a MEMORY.md file per workspace. It persists across sessions — no setup needed.

You can manage it with /memory and ask Claude to remember or forget specific things.

The progression:

• Chat has memory per Projects

• We set it up manually in Cowork

• Code has the easiest version

Plan Mode — Think Before You Act

Hit Shift+Tab and Claude switches to Plan Mode. It analyzes your request, proposes an approach, and waits for approval before touching anything.

For PMs, this is how you explore a codebase safely. This is similar to what you may know from Lovable.

Message Queuing — Stack Requests

You can type your next request while Claude is still working on the current one. It queues them and works through them in order.

Sounds small. In practice, it means you can dump a sequence of tasks — “fix the header, then update the copy on the pricing page, then run the tests” — and walk away (Lovable has it, too).

Context Window — You Can See It Now

Claude Code extension shows your context usage when you’re above 50%:

Type /context to visualize it:

The same method works in Claude Code CLI:

This matters because Claude's thinking quality degrades as the context fills up. When it climbs past 50%, use /compact to compress the conversation. In Cowork, you're flying blind on this.

Effort Control

In Chat, you toggle extended thinking on and off. In Cowork, it's adaptive. In Code, it's adaptive by default — but you get direct control via /effort. Higher for complex analysis, lower for quick edits:

File References with @

Type @ to reference any file from your workspace. Genuinely better than in Cowork for engineering workflows — you get autocomplete across the entire project:

3. Claude Code - Three Extra Tips

Explorer View — Your Project Structure, Always Visible

Cowork can also work with files in a folder (especially with Desktop Commander). But in Code, the project structure is always visible in the sidebar — and Claude can efficiently search across it with built-in tools:

The difference isn’t “can it read files” — both can. It’s that Code makes your project structure a first-class citizen.

For knowledge work, I find Cowork's in-context file panel more natural:

But when you're working with a codebase, there are moments the built-in explorer isn't enough and you need a full hierarchical view.

How to Visualize and Edit .md Files

I recommend you install "Markdown Preview Enhanced" extension. After clicking Cmd+Shift+V or Ctrl+Shift+V you're able to use the WYSIWYG editor: