メニュー
Split a minor change from the current work into a separate worktree and open a PR without interrupting your flow. Requires Claude Code (uses EnterWorktree, ExitWorktree, AskUserQuestion).
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | quick-pr |
| version | 0.0.2 |
| category | productivity |
| description | Split a minor change from the current work into a separate worktree and open a PR without interrupting your flow. Requires Claude Code (uses EnterWorktree, ExitWorktree, AskUserQuestion). |
| argument-hint | [file-path or change description] |
Split an unrelated minor change (convention fix, typo, config tweak) from the current working tree into an independent PR — without leaving the current branch.
This is a Claude Code skill. It requires Claude Code built-in tools: EnterWorktree, ExitWorktree, and AskUserQuestion.
/write-pr instead)$ARGUMENTS
Argument interpretation:
src/config.py) — extract the current diff for that file and apply it in the worktree"fix typo in README") — make the edit directly in the worktreeFetch these tools via ToolSearch before use:
| Purpose | Tool |
|---|---|
| Enter isolated worktree | EnterWorktree |
| Exit/remove worktree | ExitWorktree |
| Ask the user | AskUserQuestion |
File path arg: Run git diff HEAD -- <file>, show the diff.
Description arg: Propose which files to modify and how.
Empty arg: Ask what to split out.
→ Use AskUserQuestion to confirm the scope before continuing.
Check the project's commit style: git log --oneline -10.
Propose up to 5 candidates for each:
fix/ chore/ docs/ feat/→ Use AskUserQuestion with the numbered options. User picks or writes their own.
git fetch origin
Detect the default branch as the recommended base:
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null
Fallback: check which of main, master, develop exists.
Gather recent remote branches as additional candidates:
git for-each-ref --sort=-committerdate refs/remotes/ \
--format='%(refname:short)' | grep -v HEAD | head -5
→ Use AskUserQuestion to pick the base branch. Present the detected default as the recommended option, followed by the recent branches. User can write their own. This base is reused as the PR target in Step 4.
Use EnterWorktree to create a worktree based on the chosen base branch. Then rename the branch:
git branch -m <chosen-branch-name>
File-based mode: Before entering the worktree, note the original worktree path. After entering, copy the changed file from the original path:
cp <original-worktree-path>/<file> <current-worktree-path>/<file>
Description-based mode: Make the edit directly in the worktree.
git add <changed-files>
git commit -m "<chosen-commit-message>"
→ Use AskUserQuestion to confirm push. On approval:
git push -u origin <branch-name>
Build the PR body inline (do not delegate to another skill):
Check templates in parallel:
.github/PULL_REQUEST_TEMPLATE.md.github/pull_request_template.mddocs/pull_request_template.mdPULL_REQUEST_TEMPLATE.md.github/PULL_REQUEST_TEMPLATE/ directoryTemplate exists: preserve structure exactly. Fill sections from the diff. Leave unfillable sections (Screenshots, Related Issues) with their original placeholders.
No template:
## Summary
<what and why — 1-3 sentences>
## Changes
<bullet list of key changes>
PR title: match gh pr list --state merged --limit 5 --json title 2>/dev/null. Fallback to git log --oneline -10. Default to Conventional Commits if unclear.
→ Use AskUserQuestion with the draft title + body + target branch (defaults to the base from Step 3). Do not run gh pr create until approved.
gh pr create --base <target-branch> --title "<title>" --body "<body>"
Show PR created: <URL>.
→ Use AskUserQuestion: "Remove the worktree?"
ExitWorktree with action: "remove", discard_changes: true
(safe — the commit is already on origin from Step 4)ExitWorktree with action: "keep"Decide how elaborate to build something (simple vs. robust) and return a concrete, PoC-shaped proposal at that level — not over- or under-engineered, but right-sized. Use whenever someone is building something and the investment level is unclear: "quick or proper?", "MVP vs. real product", "is this over-engineering?", "how should I approach X?", "quick script vs. robust system", "how much architecture?", "how much do I build here?". Fires even without "poc" or "right-size" — any time effort and complexity of what to build are being weighed.
Decide how elaborate to build something (simple vs. robust) and return a concrete, PoC-shaped proposal at that level — not over- or under-engineered, but right-sized. Use whenever someone is building something and the investment level is unclear: "quick or proper?", "MVP vs. real product", "is this over-engineering?", "how should I approach X?", "quick script vs. robust system", "how much architecture?", "how much do I build here?". Fires even without "poc" or "right-size" — any time effort and complexity of what to build are being weighed.
Trace git history of specific code — find when functions, patterns, or files were added, modified, or removed, and explain the intent behind each change.
Turn code changes into a single-file HTML code review report that pairs the diff with context a diff can't show — design decisions, rejected alternatives, tradeoffs, unfinished work — plus prioritized review points. Use when preparing for review after finishing a sizable change, refactor, or feature, or whenever the user asks for a review report, change report, or an HTML summary of their changes.
Turn code, specs, a PR, or the current conversation into a QA test-case list a non-developer can read and run, exported as CSV, a shareable HTML report, or both. Trigger when the user wants QA test cases, a test plan, a QA checklist, or a test-case CSV/HTML (e.g. "write test cases for this", "make a QA list"). Output uses behavior-and-scenario language, never code symbols like function names or file paths. Not for writing or running automated test code (pytest/jest), code review, or test-strategy docs.
Render an interactive HTML board for the user to pick among multiple comparable options side-by-side at once — engineering trade-offs, copy audits, action-item triage, architecture decisions, policy calls. Returns the picks (and optional hold/note flags) as a JSON file the agent can apply.