An AI Operating System for a PM Job
51 Claude Code Skills, Nightly Automation, and a Quality Gate
As founding technical PM at an AI edtech infrastructure company, I built the system that ran my own job. A library of 51 Claude Code skills encoded how the company actually works — how tickets get scoped, how PRDs get written, how status gets reported — so the standards executed themselves instead of living in my head. On top of it: nightly automation that assembled tomorrow's status before I opened my laptop, and a human-in-the-loop gate that graded every outbound write before it landed.
The Problem
I joined a company running four concurrent customer launches with overwhelming inbound demand and a small shared engineering bench. The failure mode of that environment is well known: standards erode under load, status goes stale, and the PM becomes a passthrough who relays information without adding judgment. Writing the standards down in a doc doesn't fix it, because nobody reads docs at 6pm on a launch week.
Research & Discovery
The system's design came from observing my own failure modes first: two specific misses in the first six weeks (a triage doc that went stale, and client feedback I caught a day late) defined exactly which lane needed automation
Skills were written after being corrected, not before. Each correction from the founder became a written rule, which is why the library reflects how the company actually operated rather than how a generic PM playbook says it should
Strategy
Standards as Code
51 skills encoding how work actually gets scoped, written, and reported — executed identically every time rather than reconstructed from memory.
Context Layer
94 memory files holding glossary, norms, and every correction received, so the same mistake isn't made twice.
Push, Not Pull
A nightly job assembles tomorrow's status before the day starts, instead of requiring me to go ask four systems what happened.
Fail-Open Gate
Every outbound write graded against a rubric and held for approval — but writes proceed normally if the gate is down, so it never blocks real work.
Key Decisions
Made the quality gate fail-open rather than fail-closed. If the grading server isn't running, writes proceed normally. A safety system that blocks work when it breaks gets disabled within a week, and a disabled gate protects nothing
Kept the whole system files-first rather than building it inside the company's own tools. During the volatile early weeks the information architecture changed constantly, and restructuring with mv and grep beat migrating a schema every time
Made the agent read-only against the ticket tracker after an early scare. It drafts tickets for me to file myself. The cost is a few minutes of copying; the benefit is that no automated system can corrupt the team's shared source of truth
Kept my private daily brief entirely local with no sync to the company workspace. Mirroring unfiltered working notes into a space where leadership browses is a bell you can't un-ring, and I hadn't yet learned the etiquette
Results & Impact
51
Claude Code Skills
94
Context Memory Files
7pm
Nightly Status Job
- Authored 51 Claude Code skills encoding the company's operating standards — scoping and minimum-feasible-version discipline, PRD drafting, ticket structure, meeting notes, launch readiness, and status reporting — so each one executed identically every time instead of depending on my attention that day
- Built a 94-file memory layer holding company context an agent needs to be useful: product glossary, delivery norms, communication standards, and every correction I'd received, so mistakes were made once rather than repeatedly
- Shipped a nightly automation job that pulled the last 72 hours of ticket activity across every active launch, bucketed it into completed / blockers / open questions / next steps, and wrote it to a private page before the morning standup
- Built the WWYD Gate: a pre-write hook that intercepts every agent write to the ticket tracker, docs, and chat, grades the payload against a written quality rubric, and holds it in a review dashboard for approval or rejection with a fix prompt returned to the terminal