How I Automated My Entire PM Workflow With 7 AI Skills

The Reality of Being a Technical PM

Nobody tells you this when you become a technical project manager, but a huge chunk of the job isn't project management at all.

It's writing the same types of emails over and over. It's converting a 45-minute client call into structured notes, action items, and a follow-up email — every single time. It's building an estimation sheet from scratch because the last one was a different format. It's generating a Statement of Work that looks identical to the last one except for the project name and the numbers.

These tasks aren't hard. They're just relentless. And every hour spent doing them is an hour not spent talking to clients, unblocking developers, or thinking about what actually needs to happen next.

I got tired of it. So I built a fix.

What Is a PM Skill?

Same concept as the vibe-* development skills — a named, step-by-step workflow that loads into Claude's context and replaces improvisation with a repeatable, auditable process.

The difference is the domain. These skills aren't for building software. They're for managing the humans, the communications, and the paperwork that surround the software.

Seven skills. Each one handles a specific PM workflow. Together they cover the entire client-facing lifecycle — from the moment a call recording arrives to the moment a contract is signed.

The Seven Skills

Every client call and internal standup produces a transcript. transcript-digester converts that raw text into structured, trackable project intelligence — automatically.

Two trigger modes. Automated: Fathom detects a call has ended and fires the transcript directly into the skill. Manual: drop a .txt file into the session and it processes on demand.

Two meeting types handled differently. [CLIENT-X] calls extract scope signals, commitments made, open questions, client sentiment, red flags, and action items — then update client-brief.md and comms-log.md. [STANDUP-X] calls extract blockers, what was built, what's next, and team health — then update project-status.md.

Everything is dated, attributed, and saved to the correct project folder. Nothing lives only in the chat window. Nothing gets lost because someone forgot to write it down.

Before: manually re-reading a 45-minute transcript, writing notes into four different documents, hoping you caught everything important.

After: drop the file, review the structured output, done in three minutes.

Client emails aren't just messages. They're data. They contain scope signals, unanswered questions, sentiment shifts, and commitments — often buried in the middle of a casual paragraph.

email-thread-analyzer reads every new client email and extracts six categories of intelligence: client sentiment, unanswered questions from previous threads, new scope signals, commitments made, red flags, and action items.

It updates comms-log.md with every finding — dated and attributed. If a response is needed, it automatically triggers client-email-drafter. The PM reviews everything before anything is sent.

Two trigger modes. Automated via Gmail MCP when a new email arrives from a known client domain. Manual when the PM pastes an email thread and says "analyze this."

The key insight: client emails should be analyzed in the context of the full project history — not just the latest message. What did they ask three emails ago that never got answered? What commitment did you make in the last call that this email is referencing? The skill reads comms-log.md and client-brief.md before analyzing anything.

The most time-consuming deliverable after a client call. Every project needs one. Every estimate needs to be consistent in format, accurate in structure, and immediately shareable with the dev team.

estimate-generator takes a call transcript — or a feature list, or a client-brief.md — and produces a structured XLSX file with backend hours, frontend hours, QA (auto-calculated at 30% of dev), and PM (auto-calculated at 15% of dev). Totals across all features. No cost figures, no money — hours only.

• Mode A — New projects: greenfield builds where nothing exists yet, features scoped from scratch.
• Mode B — Existing projects: adding to a live codebase, adjusted hours based on existing complexity.

AI-adjusted hours. It doesn't just transcribe what was discussed — it applies intelligent reductions based on task type. Standard CRUD with existing patterns gets reduced. Pure UI with no logic gets reduced. Tests for already-covered logic get reduced. Novel integration work does not get reduced.

Fixed ratios that never change: QA = (Backend + Frontend) × 0.30. PM = (Backend + Frontend) × 0.15. This consistency matters when a client asks why one project's QA allocation looks different from another's.

The confirmation estimate is approved. Now you need a contract. sow-generator takes the confirmed XLSX and produces a professionally formatted .docx — BetaCraft's exact SOW format — ready for client signature.

Auto-calculates development hours, fees, milestones, and payment splits. Standard payment split is 50% / 25% / 25% with PM override available. Development hours always combine backend and frontend — the client never sees the split.

The output isn't a template with blanks. It's a complete document. Client name, effective date, MSA reference, scope description, milestone definitions, payment schedule, terms — all populated from the confirmation estimate and project context.

No more spending an hour reformatting last month's SOW for the new project. Drop the estimate, review the output, send to the client.

The estimate is confirmed by the dev team. Now someone has to turn it into Jira tickets. This is the task that gets done badly when it's done manually — vague acceptance criteria, no file paths, no codebase context, tickets that mean nothing to the developer who picks them up.

ticket-generator reads the confirmed XLSX and produces a single .md file — copy-paste ready for Jira. Feature rows become Epics. Task rows become Stories under their Epic. RnD rows become Spikes with research briefs. Pending design rows become Placeholders that are blocked until design is ready.

The codebase-aware part is what makes it different. It reads vibe/CODEBASE.md and vibe/ARCHITECTURE.md before writing a single ticket. Every Story includes the exact file paths that need to be touched, the existing patterns to follow, and acceptance criteria grounded in the actual codebase — not invented from the scope description alone.

A developer picking up a ticket generated this way knows exactly where to start, what convention to follow, and how to verify they're done.

email-thread-analyzer extracts the intelligence. client-email-drafter uses it to write the response. These two skills work together as a single pipeline.

client-email-drafter is context-first. Before writing a single word, it reads four documents: comms-log.md (full email history and analysis), client-brief.md (what the client wants to build and existing commitments), scope.md (what's in scope, what isn't), and the analyzed thread from the analyzer.

The result is a draft that sounds like a PM who has been working on this project for months — because it has access to everything a PM working on the project for months would know. It references previous commitments. It addresses unanswered questions from earlier threads. It matches the tone of the existing relationship.

The PM always reviews before sending. Never sent automatically. The skill is a first draft, not an autopilot.

One rule it enforces: never draft an email without the full context loaded. No quick replies based only on the incoming message. Every draft is grounded in the full project history.

Every Monday at 9 AM — or on demand — the dashboard skill reads across every active project and generates a single standalone HTML file: the weekly project health report.

One file. Opens in any browser. Shareable with stakeholders or printable for a meeting.

• Per project: overall health status, week-over-week comparison, active blockers, client sentiment trend, hours consumed vs estimated, upcoming milestones.
• Across all projects: portfolio-level view — which projects are healthy, which need attention, which are at risk.

Data sources are all automatic. project-status.md, session-notes/, comms-log.md, confirmed estimates, standup history. The PM doesn't assemble anything — the skill reads everything and renders the dashboard.

The design follows BetaCraft's studio aesthetic — warm off-white palette, editorial typography, clean information hierarchy. It looks like something you'd want to share in a client meeting, not a spreadsheet you scraped together on a Monday morning.

How They Connect

The skills aren't seven isolated tools. They're a pipeline. Each step updates the shared context files; every subsequent step reads them. Nothing is re-entered. Nothing is lost.

• → Client call ends — transcript-digester processes the recording, updates client-brief.md and comms-log.md, extracts action items.
• → Client email arrives — email-thread-analyzer extracts intelligence, updates comms-log.md, flags if a response is needed.
• → Response needed — client-email-drafter reads full project context, drafts the reply, waits for PM review.
• → New features scoped — estimate-generator reads the transcript and produces the XLSX.
• → Estimate confirmed — sow-generator produces the SOW for signature.
• → SOW signed, dev starts — ticket-generator converts the estimate into codebase-aware Jira tickets.
• → Every Monday — project-status-dashboard renders the weekly health report across all active projects.

What Actually Changed

The paperwork doesn't disappear. But it stops being the job.

The job becomes what it was always supposed to be: understanding what the client needs, keeping the team unblocked, and making sure the right things get built in the right order.

The paperwork doesn't disappear — it just stops being your problem.