An evidence-to-decision workspace for technical PMs who need traceability across discovery, PRD and review. Every claim traces to evidence, every requirement to the discovery that justified it, and every stage advance to the named person who signed it. I built it as a document system first and an AI system second: every template works with a text editor, and every prompt in it is a file you can read, diff and fork.
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: spec to code, discovery, or agentic build. This repository chains discovery through requirements, architecture, delivery and post-launch verification in one tree, with a regulated overlay, a knowledge layer with named attribution and a consistency gate across all of it. How it compares to spec-kit, BMAD-METHOD, Product-Manager-Skills, ChatPRD and template packs, including where each of them is stronger, is written up and dated in docs/COMPARISON.md.
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.
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.
Roadmap and OKRs feed every stage. Reviewed on their own cadence, not at a gate.
Eval specs, guardrails and red-team review, active whenever the product itself contains a model.
Activates when a financial or data regulator governs the product. Hooks in at Gate 2 and Gate 5.
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.
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.
Eleven canon cards and fifteen design cards, each with named attribution and an honest limit. Two sub-layers sit beside them: roles, an eight-rung PM ladder with seven specializations, and domains, forty-seven industry cards, forty-one of them with a worked example.
Sixty-four runnable worksheets in nine groups, from discovery and prioritization to metrics, pricing and strategy. Each one carries its scales, formulas and arithmetic, so a method is something you fill in rather than something you quote.
108 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.
233 filled examples, including four end-to-end journeys. The canonical one carries a fictional expense-report copilot from an understood problem to a development-ready handoff at Gate 3, gaps and all.
A standard-library Python CLI: a local SQLite store, the Conductor interview, approvals bound to artifact content, phase status, and a development handoff for downstream agents. It needs no model and no network, and it ships in an unreleased 0.8.0 change set on main.
Twenty-nine skills and twelve agent instruction files, each a readable procedure with no vendor account required, plus four learning paths: foundations, transitioning into PM, senior sharpening and design.
A boot prompt that runs the same interview in any chat model and assumes no file access, plus model routing that is off by default: an OmniRoute config or a standard-library OpenRouter adapter.
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.
Clone the repository, copy the template you need, and fill it in with any editor, Obsidian included. The gates are checklists a human works through. tools/init_product.py builds a product workspace and checks its links with nothing beyond Python's standard library.
A local SQLite store, the Conductor interview, approvals bound to artifact content, phase status, and a development handoff that gives an implementing agent one file to read. No model, no account and no network required.
Claude Code reads CLAUDE.md, Codex and other runtimes read AGENTS.md, and a Claude Code plugin and a read-only desktop MCP adapter sit beside them. With no agent at hand, paste the boot prompt into any chat model and it runs the same interview.
Off by default. Route through a standard-library OpenRouter adapter, or keep the OmniRoute config that sends extraction, drafting and judgment to different tiers. The runtime never calls a provider unless you invoke it.
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 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.
Payments is the pilot segment the overlay and its fourteen financial-services domain cards were built against. That is where it has been exercised, not a claim of compliance for payments or for any other regulated industry.
Discovery through post-launch verification in one place, instead of a discovery tool, a spec tool, a tracker and judgment stored nowhere.
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.
Every prompt is a file you can read, diff and fork. There is no wrapper, no account and no hosted prompt you cannot inspect.
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.
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.