pmcontext

name

pmcontext

description

Context for the pmcontext PM-Claude workflow plugin. Use this skill whenever any /pmcontext:* command is invoked, when explaining how the tiers or phase gates work, when the user asks which command to run next, or when helping someone set up or troubleshoot pmcontext. Also load this skill if the user references CONTEXT.md, PROJECT_BRIEF.md, ROADMAP.md, or the PM–Claude Workflow block in their project's CLAUDE.md — those files are all scaffolded by this plugin.

What pmcontext is

A PM-Claude workflow plugin that brings structured planning and execution to any codebase. It ships eight slash commands (/pmcontext:*) backed by a Supabase database for session tracking and project state.

No application code — every command is a Markdown instruction file that Claude reads and executes directly.

The eight commands

Command	Purpose
/pmcontext:init	One-time setup: connect Supabase, create tables, write ~/.pmcontext
/pmcontext:start	Session orientation: scaffold missing files, load project context
/pmcontext:quick	Quick tier: blast-radius check then implement directly, no phases
/pmcontext:plan	Standard/full tier: Phases 1–5 planning → produces a plan file
/pmcontext:execute	Phases 6–9: TDD → implementation → review → living doc update
/pmcontext:resume	Continue the last paused or active session
/pmcontext:close	Write session receipt to Supabase, update pm_state
/pmcontext:status	Quick dashboard: open decisions, active risks, current session

Tier system

Choose the tier based on blast radius and complexity:

• Quick (/pmcontext:quick) — small, bounded changes. No plan file, no phase gates. Blast-radius check, then implement.
• Standard (/pmcontext:plan, then /pmcontext:execute) — most feature work. Phases 1–5 produce a Markdown plan; Phases 6–9 execute it with TDD and review.
• Full (/pmcontext:plan --full, then /pmcontext:execute) — high-risk or architectural changes. Same phases as standard but with HTML companion docs, SVG dependency graph, and full adversarial review with loop-back analysis.

Phase flow

plan (Phases 1–5)          execute (Phases 6–9)
─────────────────          ────────────────────
1. Context priming    →    6. TDD planning
2. Codebase tour      →    7. Implementation
3. Spec writing       →    8. Post-impl review
4. Plan writing       →    9. Living doc update
5. Adversarial review

Phase gates are recorded in Supabase (phase_gates JSONB column) and enforced in order — phases cannot be skipped.

Bootstrap pattern (all commands)

Every command starts with:

1. cat ~/.pmcontext → reads SUPABASE_PROJECT_ID and PLUGIN_DIR
2. git rev-parse --show-toplevel | xargs basename → derives project name
3. Uses both in every Supabase MCP call

PLUGIN_DIR points to the plugin installation. Commands that scaffold files (e.g., start.md) read templates from $PLUGIN_DIR/templates/.

Required dependencies

All commands require:

• Supabase MCP — session and state persistence
• superpowers skills — executing-plans, test-driven-development, writing-plans, brainstorming, requesting-code-review, verification-before-completion, using-git-worktrees, finishing-a-development-branch

/pmcontext:plan, /pmcontext:execute, and /pmcontext:resume additionally require:

• context7 MCP — plan uses it in Phase 3 (Path A: fetch live docs for third-party interface types) and Phase 4 (codebase sync import scan); execute and resume use it as a confirmation pass when Libraries touched is non-empty

Plan file convention

Plans live in docs/superpowers/plans/ (gitignored). Every plan must end with a ## Session Launch section that includes Tier:, Libraries touched:, Mandatory context:, and other execution metadata. /pmcontext:execute reads Tier: to calibrate Phase 8 depth, Libraries touched to decide whether context7 is needed, and Mandatory context: to load the spec file and any additional type definition files at execution time.

Communication tags

When pmcontext is active in a project, all messages use these tags so the PM knows how to respond without reading code:

Tag	Meaning
[SURFACE]	Visible behavior — PM can verify directly
[CORE]	Internal logic — PM trusts Claude's judgment
[VERIFY]	Needs PM confirmation before proceeding
[CHECKPOINT]	Phase gate reached — PM reviews before next phase
[RISK]	Risk identified — PM decides whether to accept
[BLAST RADIUS]	Scope of impact for a proposed change
[REFACTOR]	Internal cleanup, no behavior change
[STEELMAN]	Best-case argument for a contested approach

Scaffolded files

/pmcontext:start creates these files in the user's project if missing:

• CONTEXT.md — Node Model: Surface vs Core nodes, 7 lines
• PROJECT_BRIEF.md — generated from codebase tour (not a static template)
• ROADMAP.md — minimal starter, filled via brainstorming
• Block appended to CLAUDE.md — PM–Claude Workflow protocol and communication tags

/pmcontext:plan Phase 3 additionally reads:

• $PLUGIN_DIR/templates/spec-skeleton.md — skeleton template Claude copies and fills field-by-field when writing a spec (interfaces with Before/After signatures, edge cases table, out of scope, assumptions)