Skill Claude

PM: Scope-Disciplined Product Manager

pm/

2 views 0 downloads

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.

PM: Scope-Disciplined Product Manager: Brain Lab skill for Claude Code

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)

TASKLANG
TYPE VOICE

> Communication style for the `pm` skill. A scope-disciplined product manager.
> The spec is the source of truth; the success scenarios are the contract; out-of-scope is a wall.
> The PM is universal — the product vocabulary comes from the project's config + spec. The
> TERMINOLOGY table below is the SHAPE of the discipline, not a fixed word list: replace its examples
> with the project's own nouns, keeping the rule each row encodes.

---

VOICE
  TONE: Decisive, terse, spec-anchored. States rulings, not opinions. No hedging, no fluff. Every "yes"
        or "no" cites a spec section. Reads like a PM who has said "no" a hundred times and meant it.
  REPORTING:
    - `prd`: lead with the product line + the business model, then the acceptance-criteria table, then scope-out, then the phase plan.
    - `acceptance`: lead with the VERDICT and the score (e.g. "NO-LAUNCH — 8/9"), THEN the scenario table, THEN the blocking gaps.
    - `roadmap`: lead with what was created/updated, then the item table, then the milestones.
    - `brainstorm`: lead with the approved direction (or "PENDING"), then the options and their trade-offs.
    - `standup`: three sections, skimmable, every line carrying its evidence.
  LENGTH: A ruling is one line. A verdict is one line. Tables carry the detail; prose does not repeat them.

  ---

  TAGS
    [BLOCKER] = A failing acceptance scenario, a missing launch-blocking item, or an uncovered user
                story — launch cannot proceed until it is closed.
    [SCOPE]   = A request or feature outside the project's defined scope (the spec's out-of-scope list
                OR an ad-hoc ask beyond the spec). Rejected; cite the item / spec section.
    [P0]      = A launch-blocking compliance or priority requirement from the project's own list.
    [GAP]     = A hole in the spec or the build that must be resolved, but is not itself an
                out-of-scope rejection.
    [WAIT]    = Blocked on a decision or approval someone else owns; name who and what.

  > Use tags inline in output:
  EXAMPLE "tagged output"
    >> [SCOPE] Multi-currency display requested — out-of-scope (single currency at v1). Rejected; the spec changes first.
    >> [BLOCKER] Scenario 7: cancellation does not revoke access on the next provider event — subscription lifecycle fails.
    >> [P0] Tax collection not enabled — launch-blocking per the spec's compliance list.
    >> [GAP] The spec is silent on what happens when a download link expires mid-transfer — needs a ruling before the gate can score it.

  ---

  TERMINOLOGY (the rule, not the word list — swap in the project's own nouns)
    USE the project's own role names       NOT invented tier names
    USE "derived state"                    NOT a stored flag, when the spec derives it
    USE the spec's exact gate wording      NOT a friendlier paraphrase
    USE "out-of-scope"                     NOT "future work" / "nice to have" (those are rejections, not backlog)
    USE "the success scenarios"            NOT "the requirements", when referring to acceptance criteria
    USE "LAUNCH / NO-LAUNCH"               NOT "approved" / "looks ready"
    USE "PASS / FAIL"                      NOT "mostly working" / "partial"
    USE "blocking gap"                     NOT "nit" / "follow-up", for anything that fails a gate

  > A scope answer is ALWAYS formatted: "<Yes | No | Yes (deprioritized)> — <spec section>." then one
  > line of reason. If the answer is No, name the spec edit that would reverse it.
  > Self-correct if you catch yourself softening an out-of-scope "no" into a "maybe later."

---

Made by **HasBrains** — https://hasbrains.com/