◆ Open source · MIT

Product Manager OS.

Run a product from discovery to sunset: gated templates, PM canon cards, and AI skills that work without AI. I built it as a document system first and an AI system second. Every template works with a text editor and a pencil, and every prompt in it is a file you can read, diff and fork.

  • 6
    stages, six gates
  • 73
    fill-in templates
  • 11
    PM canon cards
  • 10
    domain cards
◆ The problem

A PM's tools are scattered, and judgment lives nowhere.

Discovery lives in one product, specs in another, delivery in a tracker. The templates a PM actually uses arrive as screenshots of somebody else's Notion, the advice arrives as a thread, and neither one tells you what has to be true before the next stage opens.

The strongest open systems each own one segment. One owns spec to code, one owns discovery, one owns agentic build. None of them chains discovery through requirements, architecture, delivery and post-launch verification in a single system, and none carries a regulated overlay, a canon layer with named attribution, tiered model routing or a consistency gate across the whole tree.

The AI era made this worse rather than better. A model will happily produce a confident PRD from thin evidence, and there is no structure in the default workflow that stops it. This repository is my answer: the whole loop in one place, with gates that can fail, and with the model demoted from author to accelerant.

◆ The operating loop

Six stages. Six gates. A gate that cannot fail is a ceremony.

One product runs through six stages. A stage opens when the previous gate is signed and closes when its own gate is signed. Gates are documents, not meetings: a gate passes when its checklist is filled in and signed, and a gate with an unknown on it does not pass.

  1. DiscoverGate 1Problem worth solving
  2. DefineGate 2Requirements signed off
  3. DesignGate 3Architecture and risks reviewed
  4. BuildGate 4Acceptance criteria met
  5. DeliverGate 5Release readiness green
  6. OperateGate 6Outcomes verified
Gate 6 loops back to Discoverpersist · pivot · sunset
  • Planning

    Roadmap and OKRs feed every stage. Reviewed on their own cadence, not at a gate.

  • AI overlay

    Eval specs, guardrails and red-team review, active whenever the product itself contains a model.

  • Regulated overlay

    Activates when a financial or data regulator governs the product. Hooks in at Gate 2 and Gate 5.

The loop is defined in os/OPERATING-LOOP.md and the gate checklists in os/STAGE-GATES.md. The three tracks above run across every stage rather than inside one of them.
◆ What it is

Six layers, and dependencies that point one way.

Templates cite knowledge cards. Skills cite templates. System prompts cite skills and templates by exact repo path. Routing serves all of them. Nothing in the knowledge, role, domain or template layer depends on an AI layer existing, which is what makes the first usage method below possible.

  • os/
    Operating loop

    The six stages, the six gates, which document a decision deserves, and where filled artifacts live. The Conductor protocol that runs the loop as an interview sits here too.

  • knowledge/
    Knowledge, roles, domains

    Eleven canon cards with named attribution, plus eighteen indexed methods, each stating its trap and when to skip it. Two sub-layers sit beside them: roles, an eight-rung PM ladder, and domains, ten domain cards from ecommerce to a fintech pointer.

  • templates/
    Templates

    73 fill-in documents across discovery, definition, architecture, execution, delivery, operate, planning and AI. Every one carries its stage, its knowledge card and its exit gate in the header.

  • skills/, agents/
    Skills and agents

    Seven skills, including a product-analyst research skill and a feedback-synthesis skill, and five agent instruction files. Each skill is a readable procedure with two frontmatter fields, no vendor account required.

  • learn/
    Learning paths

    Three stepped paths over fictional products, foundations, transitioning into PM, and senior sharpening, each ending at a real gate checklist, plus a tutor skill that scores a filled artifact the way the Conductor cross-examines an answer.

  • system/, routing/
    Prompts and routing

    A boot prompt and role prompts that assume no file access, plus an OmniRoute config that sends extraction, drafting and judgment work to three different model tiers.

◆ How it works

Say "start." The Conductor interviews before it writes.

The fastest way in is a conversation. The Conductor, the interviewer defined in os/CONDUCTOR.md, runs the six stages above as a sequence of interviews rather than a blank template. It asks one question at a time, and a vague answer gets cross-examined, at most twice, against an evidence ladder that runs from observed behavior down to team belief, then is either accepted as offered or parked with an owner and a date. A stage does not open until the previous gate passes on evidence, and the Conductor never signs it, a named human does.

  • One question at a time, with a recommended default so agreeing costs one word
  • A vague answer gets cross-examined against an evidence ladder, capped at two pushes
  • Each gate has to pass on evidence before the next stage opens, and a human signs it, never the Conductor
  • Every accepted answer lands in STATE.md immediately, so any session can say resume and pick up where it stopped

Four ways to run it, with or without the interview.

Bare templates, no model

Clone the repository, copy the template you need, fill it in with any editor. The gates are checklists a human works through. Nothing in the knowledge or template layer depends on an AI layer existing.

Any chat model

Paste the boot prompt into ChatGPT, Gemini, Claude or a free model. It installs the loop, the gate discipline, the evidence rules and the team of roles, and it assumes no file access. When it needs a file it asks for it by exact repo path.

Agent CLIs

Claude Code reads CLAUDE.md, Codex and other runtimes read AGENTS.md, and both pick up the procedures in skills/ and the instruction files in agents/. Say start for the conducted interview above, or ask for the artifact you need directly.

API driven with OmniRoute

Point the routing config at an OmniRoute instance and each stage of a pipeline calls its own tier: extraction on a cheap tier, drafting on a coding tier, judgment on a frontier reasoning tier.

The boot prompt is model agnostic on purpose. It assumes no file access, carries a manifest of every file in the repository so it asks by exact path instead of inventing one, and it installs the same gate discipline whether the session is running on a frontier model or a free one.

◆ The regulated module

Where this came from, and why it is pinned.

The OS grew out of an earlier repository of mine, a PRD system for AI features that ship under a financial or data regulator. That system is imported here in full as modules/regulated/: a section-zero regulatory overlay, eval-set acceptance criteria, guardrails with named owners, and its own review gate. It activates at Gate 2, before requirements freeze, and again at Gate 5, before release.

The citation-bearing files inside the module are byte-exact copies, pinned by hash in the quality gate and never edited here. A fix happens in the source repository and is re-copied. That is deliberate: a compliance artifact that quietly drifts from its source is worse than no artifact, because it still looks maintained.

This is also the reason the wider repo does not assume a US software company. Discovery and compliance templates ask for markets, jurisdictions and locales as first-class fields, and the planning material treats a regulator's calendar as something that outranks a prioritization score.

Read the regulated AI PRD module →

◆ Who it is for

Built for the PM who has to sign the gate.

PMs who own a product end to end

Discovery through post-launch verification in one place, instead of a discovery tool, a spec tool, a tracker and judgment stored nowhere.

Teams shipping under a regulator

Markets, jurisdictions and locales are first-class fields in the discovery and compliance templates, and the regulated overlay is a module rather than an afterthought.

Anyone using a model for product work

Every prompt is a file you can read, diff and fork. There is no wrapper, no account and no hosted prompt you cannot inspect.

People who want the structure without the AI

If the model is free tier, offline or wrong, the artifacts and the gates still function. That is a design rule in the repo, not a hope.

What it is not
  • Not a replacement for talking to customers. The discovery templates demand interview evidence; they do not generate it.
  • Not an autopilot. Gates are signed by people with the standing to stop a stage.
  • Not a claim that a model's output is evidence. Thin input produces confident, thin output, and the gates exist to catch that.
  • Not legal or regulatory advice. The regulated module names the questions and where the primary text sits, never the answer for your entity.
◆ Contributing

Small and specific beats large and sweeping.

Issues and pull requests are open, and I merge everything personally. A new template needs a real problem statement in the pull request, fill-in fields with guidance, and an exit gate at the bottom. A knowledge card needs the framework in your own words with a named attribution line, never reproduced book text. Skills follow the two-field frontmatter convention, and a skill that needs a paid tool to work will not be merged.

One rule governs everything else: any factual claim carries a public source, and unsourced numbers are removed on sight. Template field names and file paths stay stable within a major version, so a copy you filled in last quarter keeps matching the template it came from.

Clone it, fork it, or tell me where it breaks.