菜单
Analyze the current git diff, draft a pull request title and description, and generate a pull_request.md file for manual copy-paste. Stops before opening the PR on GitHub. Use when you want to fill in the PR description yourself without creating the PR.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Investigate a developer-reported bug from a bug description, identify and rank likely root causes with evidence quality, write BUG_INVESTIGATION.md with ranked problems, detailed solutions, and Implemented?/Worked? status columns, then iteratively apply one selected fix at a time until the user confirms one worked or every proposed fix has failed. Use when invoked as /bugkiller or when asked to investigate and fix a bug through a ranked hypothesis document.
Open a pull request following the full PR workflow: resolve the base branch, check size limits (split into independent SRP-based branches if over the MAX limit), handle uncommitted changes, build the PR description from the template, run the pre-submit checklist, and open the PR with gh pr create. Use when asked to open a PR, create a pull request, or submit work for review.
Read review comments on a GitHub Pull Request, filter actionable feedback, analyze each comment, propose a solution, and walk the user through an interactive resolution flow. Use when asked to fix, address, or resolve PR review comments.
Fetch a remote and merge its branch into the current branch, resolving conflicts without breaking code. Use when asked to merge a remote branch like `upstream/main`.
Refactor tests using Behavior Driven Development principles and improve them to be readable, meaningful, and real-world focused, avoiding unnecessary mocks. Requires an explicit `BASE_REF` to diff against. Use when asked to write, rewrite, or improve tests focusing on real user journeys and scenarios.
Analyze the current branch diff against an explicit `BASE_REF` and generate a `SMOKE_TEST.md` file with branch-specific manual testing steps. Include prerequisite data setup using `rails c` when the change depends on database state, or API requests when the repo is frontend-only but still needs seeded backend data. Use when asked for a smoke test guide, manual QA checklist, or step-by-step branch testing instructions for a feature or bugfix.
| name | filler |
| description | Analyze the current git diff, draft a pull request title and description, and generate a pull_request.md file for manual copy-paste. Stops before opening the PR on GitHub. Use when you want to fill in the PR description yourself without creating the PR. |
Purpose: Analyze the current branch diff and generate a
pull_request.mdfile ready to copy-paste into a PR. Stops before creating the PR on GitHub.
| Parameter | Required | Default | Description |
|---|---|---|---|
BASE_REF | Yes | — | The base ref to diff against. Pass as the first argument: /filler upstream/master, /filler origin/main. |
If the user does not provide a base ref, stop and ask for one.
Read the diff and commit log against BASE_REF:
git diff "$BASE_REF"
git log "$BASE_REF"..HEAD --reverse --format="### %s%n%n%b"
Extract: summary, modules affected, change type, breaking changes, and visual changes.
Extract ticket from the branch name using regex (DIGIT|digit|DPMS|dpms)-?(\d+). Normalise to uppercase with hyphen (e.g. DIGIT-3131).
If not found, ask the developer. If skipped, omit the ticket from the title and remove the # Ticket 🎫 section entirely.
TICKET Description (e.g. DIGIT-3131 Add payment retry logic)Use the project's .github/pull_request_template.md if it exists. Otherwise fall back to the template in this skill's references/pull_request_template.md.
Fill in every section. Enhance with markdown features (code fences, tables, <details> blocks, mermaid charts (horizontally is better), etc.) where helpful.
Write numbered steps for a tester (not the developer): preconditions, concrete actions, expected results. Cover happy path first, then edge cases and regression checks.
pull_request.mdCreate pull_request.md at the repository root.
The first line of it should contain the suggested PR title.
All the next lines of it should contain the PR body using the pull_request_template.md pattern. Start with the first template section (e.g. # Description ✍️). Include the # Ticket 🎫 section only if a ticket was resolved.
IMPORTANT) Do not commit this file.
After writing the file, display the PR title, PR description and the full contents of pull_request.md so the user can review and copy-paste them into their PR.