A control plane for product work, built around durable policy, file-backed workstreams, resumable cmux sessions, and a planner that decides what deserves attention before the day gets noisy.
CONTEXT.mdNot a chatbot and not just a pile of prompts. More like a lightweight operating model for AI-assisted PM work.
The durable rules live with the system, not in scattered local prompt files. That makes the operating model versioned, reviewable, and easier to debug when the setup drifts.
Local runtime config still matters, but it acts like an adapter layer. Machine-specific setup stays local without quietly redefining the shared system.
The first workspace is a Chief of Staff agent that reviews notes, routines, and open workstreams, then writes a launch plan for the day. It decides what should be open before execution begins.
Each workstream lives in its own folder with a living CONTEXT.md and, when needed, live source snapshots. The important state is stored on disk, so an interrupted session can resume cleanly without depending on chat history.
The broader system uses a slim active runtime and promotes specialists when they are needed. That keeps routing fast without losing the depth of a bigger skill library.
The loop includes explicit sync and closeout steps, so the system can recover after the day gets messy and tomorrow starts from a handoff instead of guesswork.
The important shift was not just adding more skills. It was making ownership obvious.
The repo owns the durable behavior: what the system should do, what it should not do, and which workflows belong where.
AGENTS.md defines the stable rulesMachine-specific setup stays local. This layer connects your laptop, shell, and installed tools to the shared operating model without redefining it.
The current day lives in files, not terminal history. That is what makes the system resumable after interruptions, crashes, and long gaps.
today-plan.json and system/state/ show the current recommendationworkstreams/*/CONTEXT.md preserves thread-level continuityInstall the two tools first. After that, you can ask Amp to do the repo setup, create your first workstream, and launch start-day for you.
Install cmux, open it once, then turn on Automation access so the launcher can create and control workspaces.
Settings → AutomationSocket Control Mode to Full open accessInstall Amp CLI and make sure the amp command works in your shell. The AI PM OS uses Amp to run the Chief of Staff and each workspace session.
Open Amp in the folder where you want the repo to live, then use one prompt to clone the project and install the lightweight local dependencies.
Clone https://github.com/abhiroopb/ai-pm-os into this directory.
Install any missing local dependencies: jq and pyyaml.
When that's done, tell me the repo is ready.Start with one project. The point is to get a single durable thread running before you add more routines or automation.
Create workstreams/my-first-workstream from the templates.
Copy the starter CONTEXT.md and config.yaml into that folder.
Leave them ready for me to edit.Once Amp is inside the repo, have it do one dry run first. Then launch it for real. The planner will open, write the day plan, and spin up the recommended workspaces.
Run start-day --dry-run.
If the dry run looks good, run start-day.
Then tell me what opened and what needs attention first.You do not need calendar daemons, Slack automation, or a perfect setup on day one. Get one workstream running first, then tune the Chief of Staff prompt and add more routines later.
The public version is intentionally simple. Start with the local file workflow, then add more automation only after the core loop feels useful.
The whole system starts from one command, then fans out into a planner, a ranked queue, and live workspaces.
The launcher is just the beginning. The important part is how planning, ranking, and execution stay separated while sharing the same file-backed context.
start-day validates the environment and boots or reuses the CMUX workspace.
The Chief of Staff workspace reads notes, routines, and workstreams, then decides what deserves focus now.
The planner emits today-plan.json, then the public repo derives queue.json and now.json for a quick current-state view.
Workstreams like meeting prep, comms triage, or a product thread open in parallel instead of piling into one chat.
Each session reads and refreshes its own CONTEXT.md, so the thread survives crashes, interruptions, and long gaps.
An illustrative layout of the AI PM OS in CMUX: a left rail of active workstreams, a command-center surface, and a ranked queue of what should happen next.
Refine the next UX decision and prep the prompt for the design review thread.
Three follow-on threads are queued, each with its own startup prompt and durable context file.
Every workspace can crash and reopen without losing the narrative state because the thread lives in files, not terminal history.
Prep the agenda, surface unresolved decisions, and collect the last round of follow-ups before tomorrow morning.
Each meeting thread keeps its own prep notes, open questions, and expected follow-up in one place.
The routine reopens with the last brief, attendee context, and pending decisions already assembled.
Refine the next UX call, summarize trade-offs, and prepare the prompt for the cross-functional design review.
The workstream can move from review to follow-up without losing the narrative thread between sessions.
Open questions, rejected options, and the next recommendation all live next to the workstream files.
Clear urgent messages first, draft follow-ups, and route anything that needs durable tracking back into the system.
The routine keeps fast-response work separate from long-lived projects while still preserving context.
Unread threads, drafted responses, and unresolved asks can all survive a restart without rebuilding the queue.
start-day -> boots or reuses cmux -> opens Chief of Staff workspace -> Chief of Staff writes system/today-plan.json -> build-state-from-plan.py derives queue.json + now.json -> launcher opens recommended workstreams -> each workstream resumes from its own CONTEXT.md
If you want the philosophy, mechanics, and control-plane framing, start here.
The ownership model behind repo policy, thin home adapters, archive-backed specialists, and file-backed state.
Why I moved from a collection of useful AI skills to a full operating system for product work.
The technical walkthrough of the launcher, planner, state layer, and resumable workstreams.
Why the real leverage comes from orchestration, durable context, and system design around the model.
Why the system became much more dependable once the workflow covered the middle and the end of the day too.