Use this skill when creating a git branch for a Linear or GitHub issue, writing a PR description, opening a pull request, or linking a PR to its tracked issue. Trigger phrases "create a branch", "new branch for this issue", "branch for
Use this skill when integrating, reading, or updating a project's conventions.md file — the document that captures house style for issue titles, labels, branch naming, PR descriptions, handoff phrasing, and review etiquette. Trigger phrases "set conventions", "load conventions", "where are the conventions", "what are our conventions", "add a convention", "edit conventions.md", "/pm-conventions", "the conventions say", "our team uses <X> format", "project conventions", "project title format". Also use proactively when another pm-* skill (pm-issues, pm-review, pm-improve, pm-branches, pm-handoff, pm-agent, pm-projects, pm-project-review) is about to write or evaluate text and a conventions file exists at `<repo>/.claude/pm/conventions.md` — the conventions must be loaded and applied before the skill writes anything user-facing.
Use this skill when the user asks to "find duplicate issues", "clean up duplicates", "what dupes are in the backlog", "/pm-dedup", or after a /pm-status briefing flags likely-dup clusters. Runs the `duplicates` lens against the team cache, has the agent judge each cluster, then offers merge / relate / close per cluster. Powered by the shared dedup engine in `hooks/lib/dedup.js`.
Use this skill when the user wants to report a bug, an unexpected result, or an improvement idea about the project-manager plugin ITSELF (or one of its pm-* skills) to the functional-claude maintainers — or when the agent has just hit a project-manager failure (a pm-* CLI error, a wrong/empty briefing, a crash, a clearly-incorrect result) and should offer to report it. Trigger phrases "report a bug in pm-review / pm-notes / any pm-* skill", "this plugin is broken", "pm gave the wrong answer", "send feedback about project-manager", "tell the functional-claude team", "/pm-feedback", "file a plugin issue". The defining cue is that the target of the complaint is the plugin or a named pm-* skill, not the user's own product. Assembles a README-shaped report (plugin + version, repro, expected vs actual, safe environment), scrubs every credential via the tested `hooks/lib/feedback-report.js` guard, previews it, then delivers — email to the Linear intake address (via resend-cli), GitHub issue fallback, or copy-paste d
Use this skill when the user wants to hand off work to another person or to the next stage of the lifecycle. Trigger phrases "hand this off to", "give this to", "I'm OOO", "passing this to", "covering for", "ready for release", "ready for QA", "ready for review", "release notes", "deploy handoff", "write a handoff", "/pm-handoff". Produces recipient-facing briefs with four required blocks (summary, what's done + how to use it, what's NOT done + next steps, open questions). Routes through configured channels (Linear, GitHub, markdown, chat/email).
Distinct from `pm-review` (which *scores* whether an issue has the right structural shape), this skill *adds* project-specific context to an existing Linear or GitHub issue — relevant files, recent commits, owning modules, best-practice references, prior-art / related issues, and clarifying questions the author should answer before work starts. Use it when you want to give an issue more material to work from, not when you want to grade it. Trigger phrases "improve this issue", "enrich issue <ID>", "add context to this issue", "what's missing from this issue", "any relevant code for this issue", "research this issue", "qna this issue", "/pm-improve". Also use proactively after `pm-review` flags structural gaps that hint at missing context. Produces a draft enrichment; with `--apply`, posts it as a comment on the issue. Safe to re-run as repo state drifts — the marker mechanic replaces rather than stacks.
Use this skill when creating, updating, or closing **an issue** (a bug, feature, task, or spike) in Linear or GitHub; when the user describes a specific untracked **issue** that should be filed; when drafting issue content; or when the user says "create an issue", "log this issue in Linear", "add this issue to Linear", "open a github issue", "file an issue", "create issue
Track a SINGLE running parent issue, epic, or project commit-by-commit — a focused phase ledger of which child issues are done, in progress, and next, with each child's shipping commit aligned to its phase. Use whenever the user is working a parent/epic/project and asks "where am I on this", "what's left on <ID>", "show progress on this epic", "what's next here", "pick up where I left off", "resume <ID>", or wants commits mapped to phases. Also use to re-orient when resuming work on a tracked parent in a fresh session. This is DEPTH on one parent — distinct from pm-status (whole-backlog breadth) and pm-report (stakeholder documents). When the user names or implies a specific parent/epic/project and wants its internal progress, prefer pm-ledger even if they say the word "status".