An operating system for product work, built around a Chief of Staff agent, durable workstream context, resumable cmux sessions, and a start-of-day flow that decides what deserves attention before the day gets noisy.
CONTEXT.mdcmux workspacestoday-plan.json → stateNot a chatbot, not a pile of prompts. More like a lightweight operating model for AI-assisted PM work.
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. The important state is stored on disk, so an interrupted session can resume cleanly without depending on chat history.
Once the plan exists, the launcher opens the right cmux workspaces in parallel. Planning, project execution, meeting prep, and routine loops can stay separate instead of collapsing into one thread.
The open-source version is sanitized, tool-agnostic, and intentionally lighter than the internal system. It keeps the useful shape while stripping away private integrations and extra machinery.
Install 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 product framing, start here.
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.