You Oversee. Claude Operates: Inside pm-*, My 23-Skill AI PM System

Ask anyone what a project manager does and they'll describe the visible ten percent: running standups, talking to clients, unblocking the team. What they won't describe is the iceberg underneath — turning a ninety-minute call into minutes nobody disputes, reconciling what was promised in the SOW against what's actually in the sprint, chasing status for a report, updating the risk register, drafting the email that explains a slip without burning trust. None of it is strategy. All of it is mandatory. And across multiple concurrent client projects, it quietly eats the hours that strategy was supposed to get.

I run several client projects in parallel at BetaCraft, and that administrative layer was my bottleneck. I'd already solved a version of this problem for development with the vibe-* framework — structured Claude Code skills with durable, written-down context. The obvious question followed: if a spec-driven harness could make an AI a reliable engineer, could the same approach make it a reliable PM operator? That question became pm-*: 23 skills that handle the full PM lifecycle, published at aakashdhar.me/pm-skills.

The framework rests on one division of labour, and it is strict. Claude does the operations: reading transcripts, drafting documents, cross-checking scope, compiling dashboards, scanning for risk signals. I do the judgement: decisions, approvals, and anything that leaves the building. In practice my side of the system collapses to four things — feed it the inputs (transcripts, SOWs, updates), review what it produces, make the calls it surfaces, and hit send. Everything else is Claude's job.

Two rules keep this safe in real client work. First, strict factual grounding: documents like meeting minutes are built only from what is actually in the source material — no inferred decisions, no "probably meant." If it wasn't said, it isn't minuted. Second, nothing client-facing ships without a human: every email, every formal document, every dashboard goes out under my review and my name. The agent drafts; I fire. That single checkpoint is what makes the rest of the autonomy acceptable.

Like vibe-*, each skill is a structured workflow with a natural-language trigger, and they compose across the whole lifecycle of a client engagement — from the moment a project lands to the day a phase closes out. Rather than walk through all 23, here's the shape of the territory:

One Workspace Per Project

Structurally, pm-* runs as a polyrepo workspace: every client project gets its own folder of durable records — the SOW, the decision log, minutes, risks, status — and every skill reads from and writes to that record. It's the same "spec before code" principle from vibe-*, translated: record before action. The agent never operates from memory of a chat; it operates from the project's files.

Project documents are only half the battle; the other half is the connections between them. A decision in March explains a scope change in May. A risk flagged in one meeting resurfaces in another under a different name. pm-* adds a knowledge layer on top of the document store — compiled from the project record itself — so that when Claude drafts a status update or scans for risk, it isn't just reading the latest file, it's traversing the project's history: which decisions touched this feature, what the client was told, what changed since.

The honest engineering note: this layer earns its keep on long-running, document-heavy projects and is deliberately optional on small ones. Maintaining a graph nobody queries is its own kind of overhead, and the framework is opinionated about not paying costs that don't buy anything — a lesson learned the practical way, by building it, measuring it, and keeping it only where it pays.

The number that sells the system internally is the weekly overhead: roughly twenty minutes of my attention per project for the entire administrative layer — reviewing generated minutes, approving the dashboard refresh, editing a drafted email or two. The work still happens; it just stopped happening through me. What that bought back is exactly what the iceberg was sinking: time for the judgement-heavy work — client relationships, sequencing calls, the trade-off conversations no agent should be making.

The side effects mattered as much as the headline. Minutes went out the same day as the meeting instead of "by Friday." The decision log went from a thing I reconstructed under pressure to a thing that simply exists. And because the whole record lives in files, any colleague — or any fresh Claude session — can pick up a project cold. The system was packaged for BetaCraft-wide use for precisely that reason: it isn't my memory, it's the project's.

vibe-* and pm-* are the same idea pointed at two different jobs: give the agent durable written context, encode the workflows as triggerable skills instead of folklore, put a review gate before anything irreversible, and let the documents do the remembering. Code delivery and project delivery turn out to respond to the identical treatment — which suggests the pattern isn't about software or PM at all. Any role with a repeatable operational layer and a judgement layer can be split the same way. The craft is in drawing the line honestly, and then defending it.

The full system — skills, structure, workflow, and a live demo dashboard — is documented at aakashdhar.me/pm-skills.