菜单
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
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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
| name | pm-branches |
| description | 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 |
| version | 0.44.4 |
Enforce consistent branch naming and PR descriptions that trigger Linear's auto-close via PR link.
/pm-branches [<issue-id>] [<type>] [<short-description>]
Workflow-driven (no flags) — inputs are gathered from the branch/context:
<issue-id> (Linear ID e.g. ENG-42 or GitHub #42, required) — the tracked issue to branch for and Closes in the PR. If untracked, file it first via pm-issues.<type> (one of feat fix chore refactor docs test, optional) — branch-name prefix; defaults from the nature of the change.<short-description> (2-4 words, lowercase, hyphenated, optional) — the branch-name suffix.<issue-id>: <concise title>; body uses the PR description template and ends with Closes <issue-id>.git checkout -b, git push -u origin <branch>, and gh pr create.One PR closes one Linear issue. If extra work surfaces mid-PR:
pm-pivotFor larger features, use Linear's parent/sub-issue hierarchy. Parent issue needs no PR — it closes when all sub-issues close. Each sub-issue gets its own branch (feat/NTH-44-auth-middleware) and PR with Closes <SUB-ID>.
Target: ~200-400 lines changed. Under 200 is ideal. Over 500 warrants a check-in.
Before opening a PR, verify every changed file relates to the issue's acceptance criteria, there are no unrelated changes, and test changes match code changes.
Check in with the user after completing the core change, when the diff crosses ~300 lines, or when unexpected complexity appears. If the diff exceeds ~500 lines, suggest splitting into a shippable subset + follow-up issue.
Format: <type>/<LINEAR-ID>-<short-description>
type = feat, fix, chore, refactor, docs, testLINEAR-ID = the Linear issue identifier (e.g., ENG-42)short-description = 2-4 words, lowercase, hyphenatedExamples:
feat/ENG-42-auth-middleware-refactor
fix/ENG-45-pagination-off-by-one
chore/ENG-51-update-dependencies
git checkout -b feat/ENG-42-auth-middleware-refactor
Always confirm the Linear issue ID before creating the branch. If the work isn't tracked yet, use the pm-issues skill to create the issue first.
## Summary
[1-3 bullet points describing what changed and why]
## Changes
- [Specific change 1]
- [Specific change 2]
## Testing
- [ ] [How to verify this works]
- [ ] [Edge cases tested]
Closes ENG-42
Critical: The Closes <ID> line at the end of the PR description is what triggers Linear to auto-close the issue when the PR merges. Always include it. One PR, one Closes line.
When the user says "open a PR" or "push this up":
git push -u origin <branch>gh pr create \
--title "<LINEAR-ID>: <concise title>" \
--body "<description with Closes ENG-XX>"
ENG-42: Refactor auth middleware to support OAuth
The Linear ID at the front of the title makes it easy to scan in GitHub's PR list.
After creating the PR, confirm the Linear issue shows the PR as attached:
get_issue { id: "<issue_id>" } → check attachments or relations
If Linear doesn't pick it up automatically within a few minutes, the Closes keyword in the PR body is what matters — Linear scans it on merge.