القائمة
Create pull requests. Use when opening a GitHub PR, drafting a PR title/body, preparing a pull request description, or reviewing a branch before PR creation.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Coordinate parallel ticket workers as an event-driven control plane through repos worktrees, Pi sessions, delegated pull-request review, squash merges, and filesystem tracker frontiers. Use when orchestrating implementation tickets rather than implementing or reviewing one ticket directly.
Implement one ticket handed off by the orchestrator and open a PR for review.
Manage work in the local Tickets filesystem tracker. Use when the user asks to inspect, search, create, claim, update, move, rename, complete, or lint a Tickets project or ticket.
Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
Provides comprehensive code review guidance. Helps catch bugs, improve code quality, and give constructive feedback. Use when: reviewing pull requests, conducting PR reviews, code review, reviewing code changes, establishing review standards, mentoring developers, architecture reviews, security audits, checking code quality, finding bugs, giving feedback on code.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
| name | creating-prs |
| description | Create pull requests. Use when opening a GitHub PR, drafting a PR title/body, preparing a pull request description, or reviewing a branch before PR creation. |
A good PR feels native to its repo and gives a familiar reviewer the missing context they need to trust the change.
Read the repo convention. Inspect the PR template and a few recent PR titles and descriptions. Done when you know the expected title shape, whether Jira tickets are required, whether ticket links appear in the body, and which template sections are actually used.
Find the ticket. If repo convention expects Jira tickets, derive the ticket key from the branch or commits using the ABC-123 shape. If the repo expects one and you cannot find it, ask the user for it before drafting the PR. Done when the title can start with the ticket key or you know this repo does not require one.
Understand the change. Review the branch diff and commits as the source of truth. Done when you can describe the user-visible behavior, workflow, constraint, or system capability that changed, plus the motivation/context a codebase-familiar reviewer would not infer from the diff alone.
Draft a native title. Mirror recent PRs. When Jira tickets are expected, use TICKET-123: Imperative summary. Done when the title is short, imperative, repo-native, and includes the ticket key when required.
Draft the body from the template. Follow the repo PR template, pruning irrelevant sections instead of padding them. Done when every retained section has useful content and no removed section would help the reviewer.
State verification as change-specific evidence. Verification is the evidence that this PR's behavior is covered, not a log of commands run. Prefer evidence that exercises the system boundary a reviewer cares about: Playwright, API, integration, contract, or other end-to-end-ish coverage. Unit tests are the lowest form of PR verification; cite them only when this change genuinely cannot be covered at a higher boundary, and say what behavior they prove. If no meaningful coverage was added, explain the honest confidence boundary: why coverage was not possible or not relevant, and what remains unproven. Only include manual validation steps when a reviewer truly needs them. Done when the section answers “what evidence proves this change works?” without mentioning routine local commands.
npm test, or unit-test command names in the PR body. They are not verification evidence for reviewers.