gh-pms

Github PMS Plugin

GitHub Issues as a project-management system for Claude Code.

A Claude Code plugin marketplace that turns GitHub Issues into the source of truth for your project: plans, features, bugs, evidence-gated lifecycle, PR-driven review. Inspired by Orchestra MCP and Studio PMS, backed by GitHub's first-class primitives — Issue Types, Projects v2, Milestones, sub-issues, and relationships — not just labels.

Why

Most teams use GitHub Issues as a dumb backlog. gh-pms adds the structure that real project management needs:

• Plans = Milestones with due dates and native progress bars
• Features / Bugs use GitHub's native Issue Types when available, fall back to labels otherwise
• Status tracked in a Projects v2 board's Status field (when configured) or status:* labels
• Sub-issues for plan → feature breakdown, dependency relationships (depends on, blocks, related to, duplicate of)
• Evidence-gated lifecycle — 5 gates with required ## Sections (file paths, test results, self-review)
• WIP limits, cooldowns, kind-specific skips (bugs auto-skip the docs gate)
• PR-driven review — Closes #N keyword + AskUserQuestion approval + gh pr merge closes the loop

Everything lives natively in GitHub. Open the Issues, Milestones, or Projects tab and you see exactly where the project is.

What's new in v0.8

See CHANGELOG.md for the full list. Highlights:

• gh-test-plan skill — generate testcase sub-issues from acceptance criteria (#17, PR #31)
• gh-search skill — ad-hoc issue queries beyond gh-status (#16, PR #30)
• gh-bulk skill — safe batch label / close / reassign / set-severity (#15, PR #29)

See CHANGELOG.md for the full v0.8.0 entry.

From v0.7: (previous release)

See CHANGELOG.md for the full list. Highlights:

• gh-metrics skill — time-in-status, gate failure rate, throughput (#13, PR #27)
• Optional AI reviewer on Gate 4 (sub-agent code review before user approval) (#12, PR #26)
• Wire Effort field end-to-end (gh-feature input + gh-status velocity) (#11, PR #25)

See CHANGELOG.md for the full v0.7.0 entry.

From v0.6: (previous release)

See CHANGELOG.md for the full list. Highlights:

• gh-triage skill — accept/reject/dedupe the type:request inbox (#8, PR #23)
• CI gate on Gate 4 — refuse review-ready when checks are red (#7, PR #22)
• Per-repo config in .github/gh-pms.yaml (#6, PR #21)

See CHANGELOG.md for the full v0.6.0 entry.

From v0.5: (previous release)

Two skills that close adoption gaps the v0.4 release made obvious — sessions starting blind to the issue tracker, and releases requiring a manual edit-bump-tag dance.

• gh-context ✨ — compact session-start summary of WIP, pipeline, milestones, recent closes, deferred requests. Auto-runs via the new SessionStart hook so the agent picks up where the last session left off (#9).
• gh-release ✨ — bundle PRs merged since the last tag into a structured CHANGELOG entry, bump plugin.json, refresh the README banner, tag, and (optionally) create a GitHub release in one shot. Idempotent; refuses without an anchor (#5).

See CHANGELOG.md for the full list.

From v0.4: severity first-class

Severity is now a first-class dimension on every issue kind, not just bugs. A P0 feature blocking a launch is meaningfully different from a polish item — that signal was previously lost. Closes #2.

• Canonical scale — workflows/default.yaml#severities is now the single source of truth (default: medium + four values, each mapped to a severity:* label and a Project v2 Severity field option). Per-repo severity scales become a config-only change.
• gh-feature ✨ — accepts an optional severity on every kind (not just hotfix). Applied as label + Project field. Hotfixes still default to critical.
• gh-task — sub-issue tasks inherit the parent feature's severity by default; override when the task is meaningfully more or less urgent. Checkbox tasks inherit implicitly.
• gh-bug — references the canonical scale instead of defining its own. Same defaults, no behavior change.
• gh-status — within each Status bucket, issues are sorted Critical → Low so urgent items surface first regardless of kind.
• Templates — feature.md, chore.md, testcase.md gain a ## Severity section. plan.md / prd.md stay exempt (they aggregate child severities).

Backwards compatible — existing issues without a severity:* label remain valid, and skills called without severity get medium.

From v0.3: gh-push skill + branching policy

The "every feature must end with a linked PR" rule is baked into the lifecycle: