菜单
Open, publish, or raise a GitHub pull request. Use when the user asks to create or publish a PR for a GitHub-backed codebase, especially when branches are Linear-issue-prefixed.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Return your work to the parent agent that spawned you. Use when you are a child session that has finished (or reached a checkpoint on) a side-quest and the operator wants the findings returned to the originating session.
Dispatch work to another agent through the mailbox to a named existing peer, or to a new agent wired to reply to you. Use when the operator says "dispatch to <name>" or "dispatch this to a new agent", optionally refining what to send.
Inter-agent mailbox for sending a handoff to another agent session and picking up replies. Use when you need to set up your mailbox, send or reply to another agent, check for or wait on incoming mail, take over an existing mailbox identity (e.g. "take over Alice's mailbox"), or prune stale mailboxes. The fabric beneath the spawn, handback, and dispatch skills.
Spawn a fresh agent session from the current one — hand the conversation off into a new tmux window that continues the work one-way, with no channel back. Use `dispatch` instead when the child must report back.
Generate chart images for markdown documents using the QuickChart API. Use when writing reports, READMEs, changelogs, dashboards, or any markdown output that needs an embedded chart, graph, sparkline, gauge, or data visualisation.
Compact the current conversation into a handoff document for another agent to pick up.
| name | open-pr |
| description | Open, publish, or raise a GitHub pull request. Use when the user asks to create or publish a PR for a GitHub-backed codebase, especially when branches are Linear-issue-prefixed. |
| license | MIT |
| metadata | {"author":"William Duyck","version":"1.0"} |
Use this skill for the full PR publishing path:
If gh is unavailable, stop and tell the user it is required. If the Linear MCP update fails, do not try another route; tell the user the tool failed.
Prefer the repository template over any generic structure. Fill existing headings in place, preserving order, checkboxes, prompts, and team-specific wording. Work best-practice content around the template instead of replacing it.
When there is no template, use this compact fallback:
## Summary
## Changes
## Risks / Gotchas
## Related Issues
Only add a testing or verification section when it gives reviewers useful context, such as non-obvious manual verification, intentionally uncovered behavior, or changes not covered by unit, feature, or end-to-end tests. If verification is unclear from context and git history, omit it unless the repo template requires it.
Write for reviewers:
Use Keep a Changelog-style categories as a thinking aid for key changes: Added, Changed, Deprecated, Removed, Fixed, and Security. Do not force these labels into a repo template unless they fit naturally.
Use gh pr create with an explicit title and body. Only create a draft when the operator explicitly asks for one.
After creation, give the user the PR URL.
After a non-draft PR is created successfully, and only then:
Code Review.Move Linear only for non-draft PRs. Branch issue keys are only recognized in the form ABC-123-branch-name, where the key is at the start of the branch name.