메뉴
Creates GitHub pull requests with repository templates, concise reviewer-focused descriptions, and Linear issue state updates. Use when the user asks to open, create, raise, or publish a PR for a GitHub-backed codebase, especially when branches are Linear issue-prefixed.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Review the changes since a fixed point along three independent axes — Standards (does the code follow this repo's documented conventions and avoid known smells?), Spec (does it do what the issue/PRD asked?), and Architecture (does the change belong in the system and raise its evolvability — working with the grain of the existing seams, domain model, and layers to leave the architecture cheaper to change next — rather than lowering it?). Runs three parallel sub-agents that never share context and reports them side by side. The strongest architectural opportunity gets a concrete follow-up the operator can run. Use when the user wants to review a branch, a PR, or work-in-progress changes, or asks to "review since X".
Hand work to another agent through the mailbox — send to a named existing peer, or, when no name is given and the context calls for it, create 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.
Pure-filesystem inter-agent mailbox so any agent session can send a handoff document to another and pick up replies. Use when you need to set up your mailbox, send or reply to another agent, check for or wait on incoming messages, resolve another agent by name, take over / claim an existing mailbox identity (e.g. "take over Alice's mailbox"), or prune stale mailboxes from the registry. The fabric beneath the spawn, handback, and dispatch skills.
Return your work to the parent agent that spawned you by producing a handoff and sending it back through the mailbox. Use when you are a spawned/child session that has finished (or reached a checkpoint on) a side-quest and the operator wants the findings returned to the originating session.
Handoff the current conversation and open a new Claude instance in a fresh tmux window to continue the work. Use when the user wants to spin up a new agent session from the current one.
Generate a markdown changelog for the changes between a fixed point and HEAD, enriched with issue-tracker context. Use when asked for a changelog, release notes, or a summary of merged work over a range or time window. Pass through whatever the user names as the base (SHA, branch, tag, main, HEAD~5, or a date window); detect the issue tracker from the repo's environment; follow Keep a Changelog headings; update an existing CHANGELOG.md in place when one is present.
| name | create-pr |
| description | Creates GitHub pull requests with repository templates, concise reviewer-focused descriptions, and Linear issue state updates. Use when the user asks to open, create, raise, 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:
gh pr create.Code Review using the Linear MCP.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 URL to the PR that was created.
After a non-draft PR is created successfully:
Code Review.Never move Linear for draft PRs. Never update Linear before the GitHub PR exists.
Branch issue keys are only recognized in the form ABC-123-branch-name, where the key is at the start of the branch name.