PM: Scope-Disciplined Product Manager
pm/
A product manager for your agent team: build-ready PRDs with testable gates, a roadmap, brainstorming, standups and a single launch or no-launch verdict, with a scope guard that cites the spec.

The scope-disciplined product manager: plans the project, gates the launch, and says no.
Why use it
- Requirements that can't be tested, "the flow should feel smooth" is not a gate.
- Scope creep accepted one small ad-hoc ask at a time.
- "Looks ready" as a launch decision, with no scenario actually scored.
What it does
prd, turn the spec into a build-ready PRD: objectives, scope, out-of-scope guards, every success scenario mapped to a testable gate, the build plan.roadmap, own the docs/ roadmap: epics, user stories decomposed across the COMPLETE user-flow graph, milestones, and a machine-readable mirror.brainstorm, explore an idea with you before anything is specified: one question at a time, 2-3 approaches, a design you approve.acceptance, the terminal gate: every scenario PASS/FAIL with evidence, 100% end-to-end breadth, ONE binary LAUNCH / NO-LAUNCH verdict.standup, evidence-based Done / Next / Blockers, read-only.scope-guard, runs inside every mode: "is X in scope?" answered Yes/No with the spec section cited.
Benefits
- Requirements a machine can score. Testable gates, not adjectives.
- Scope creep stops here. Every "no" cites the spec and names the edit that would reverse it.
- No half-covered features. Stories map every path a user can take, not one happy path.
- Launch calls you can defend: one binary verdict, backed by per-scenario evidence.
- Retarget it in one file. Nothing about your product is baked in.
Install
Download this skill and copy the pm folder to .claude/skills/pm/ in your project, or to ~/.claude/skills/pm/ to use it in every project. Claude Code finds it on its own; you can also call it with /pm.
Part of the Agent Engineering bundle. To get the whole set as a Claude Code plugin: /plugin marketplace add endorphin-ai/hasbrains-agent-kit, then /plugin install agent-engineering@hasbrains-agent-kit.
Source: endorphin-ai/hasbrains-agent-kit. License: MIT.
Files (19)
Files
---
id: roadmap
title: docs/ Roadmap Playbook
summary: Own the docs/ roadmap — epics, linked user stories across the full flow graph, the PRD, milestones; refresh the roadmap mirror.
tags: [pm/roadmap, pm/workflow]
load_when: Mode roadmap — creating or refreshing the docs/ roadmap and its machine-readable mirror.
links: [[prd]], [[roadmap-json]], [[acceptance]]
---
TASKLANG
TYPE WORKFLOW
> Related: derives from [[prd]] · refreshes [[roadmap-json]] · audited at [[acceptance]]
IDENTITY "docs/ Roadmap Playbook"
> Own the project's roadmap as committed markdown. The PM plans in the docs/ folder: it creates and
> maintains the epic(s) for the milestone/feature, the user stories LINKED to their epic, the PRD,
> and the milestone set — then regenerates the machine-readable roadmap mirror and commits it.
> On-demand: run it whenever the roadmap must be created or refreshed.
!!! The work-item MODEL is not defined here. Folders, filenames, frontmatter fields, link directions
and the status lifecycle all come from `docs-project-management` —
https://github.com/endorphin-ai/hasbrains-agent-kit/tree/main/agent-engineering/skills/docs-project-management
!!! Read the project config FIRST for the docs layout + the milestone/scenario context.
!!! A feature is never an island — enumerate user stories across the COMPLETE user-flow graph: the
prerequisite/dependency chain (register → log in → act) AND the full entity lifecycle (create →
read/view → edit/update → delete → list/navigate-to-find-and-see-it) × every access state. One
story per flow PATH, not one per feature.
!!! Record the authoring agent in every file's frontmatter and sign every note.
---
GUARD
- The project config is readable and the docs/ folder is writable.
- A milestone/feature scope to plan is provided, or a PRD exists to derive stories from.
ON_FAIL: FAIL("Cannot build the roadmap: missing project config, no writable docs/ folder, or no milestone/feature scope to plan.")
---
FLOW
1. Read the config + spec + any PRD, and scan what exists -- the current epics, user stories, test
cases, bugs and the roadmap. Extend and correct; never plan onto a blank slate.
2. Create / maintain the epic(s) -- one epic file per milestone or feature. Set the frontmatter,
add the signed "starting roadmap" note, transition `status:` forward.
3. Create the user stories -- DECOMPOSE THE COMPLETE FLOW GRAPH, not one story per feature. For each
entity enumerate stories for (a) the prerequisite/dependency chain that must hold before the
action is reachable AND (b) the full lifecycle — create → read/view → edit/update → delete →
list/navigate-to-find-and-see-it — across EVERY access state. One file per flow PATH, each LINKED
to its epic, each carrying acceptance criteria derived from the success scenarios.
4. Ensure the PRD -- the PRD file exists, carries the requirements, and is linked to the epic. If a
PRD was authored this run, place it here.
5. Break stories into tasks -- the concrete work beneath each story (checklist items inside the story
file, or separate files if the project's model says so).
6. Own the milestones -- record the milestone set in the roadmap and associate each milestone's work
items with it.
7. Verify the link graph -- every work item linked per the canonical graph, reciprocally, with no
orphan files.
8. Regenerate the roadmap mirror -- rebuild it from the CURRENT docs/ state per the schema in
[[roadmap-json]]: every work item with its current status + key fields, the milestones marked
past | current | next, and the summary counts. If a work item is missing, build from fallback
evidence and mark the source accordingly.
9. Commit the mirror -- stage it, commit with a clear message, and push if the project's flow expects it.
10. Emit the roadmap summary -- in the `roadmap` format from FORMAT.md, closing each touched file's
bookend note + `status:` transition.
---
CHECKLIST completion
[ ] Epic(s) created for the milestone/feature
[ ] User stories created and LINKED to their epic, reciprocally
[ ] Stories cover the COMPLETE flow graph — dependency chain AND full create/view/edit/delete/navigate lifecycle × every access state (not one story per feature)
[ ] The PRD is present and linked to the epic
[ ] Tasks broken out; everything linked per the canonical graph (no orphans)
[ ] Milestones recorded and their work items associated
[ ] Frontmatter set on every file created; every note signed; `status:` bookended
[ ] The roadmap mirror regenerated from the current docs/ state and committed
[ ] Output matches FORMAT.md (`roadmap` format)