Menu
Use when the user says: "create PR" or "open pull request". Reviews branch changes and creates a PR on GitHub or Azure DevOps.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
'Use this when the users says: "review existing feature","make this change"
Use when the user says: "extract learnings", "save this for next time", "remember this pattern", "consolidate memories", "dream", "clean up memories".
Use when the user asks about Claude token usage, wants to see how much they are spending on Claude, understand cache hit rates, review Claude Code workflow patterns, or get cost optimization recommendations.
Use when the user asks to recall, search, or continue past conversations. Triggers on "what did we discuss", "continue where we left off", "remember when", "as I mentioned", "you suggested", "we decided", "search my conversations", "find the conversation where", "what did we work on". Also triggers on implicit signals like past-tense references ("the bug we fixed"), possessives without context ("my project"), or assumptive questions ("do you remember").
Generate a commit message
Manage conversations and task context
| name | mine.create-pr |
| description | Use when the user says: "create PR" or "open pull request". Reviews branch changes and creates a PR on GitHub or Azure DevOps. |
| user-invocable | true |
git branch --show-currentgit-default-branchgit remote get-url origin 2>/dev/nullgit-branch-loggit-branch-diff-statBased on the above changes:
git-platform. If output is unknown, inform the user the platform is unsupported and stop. If github, use gh CLI. If ado, use az CLI.git status to ensure no "Your branch is ahead" or "not yet pushed" messages)gh pr list --head <branch-name>az repos pr list --source-branch <branch-name> --status activegit loggit diff [base-branch]...HEAD to see all code changes### H3 header followed by bullet points. Order sections from most to least impactful. Bullets should explain why a change was made, not just what changed — include motivation, tradeoffs, or decisions worth preserving for future readers. Exception: if the PR includes changes to ./design/ (ADRs, design docs, decision records), don't re-explain that reasoning in the PR body — just reference the document (e.g., "see design/adr-012-auth-approach.md"). Duplicating it risks going stale or conflicting. Collect small, standalone changes (one-liners that don't warrant their own section) into one or two ungrouped sections:
### Notable Changes (top) — small but important changes worth seeing first### Housekeeping (bottom) — minor cleanup, dependency bumps, typo fixes, etc.### Notable Changes
- Important small change and why it matters
### Feature name or area
- What changed and why this approach was chosen over alternatives
- Any tradeoff or decision future readers should know about
### Another significant area
- Change detail with motivation
### Housekeeping
- Bump dependency X to v2
- Fix typo in README
N):
N-description (e.g., 123-fix-null)issue-N or issue/Nfix/N-description, feat/N-description, chore/N-description, etc.git log output for GitHub closing keywords followed by an issue number (e.g., Fixes #123, Closes #123, Resolves #123). Do NOT match generic references like refs #123 — those do not close issues.Closes #N
Closes #N line per issue.get-skill-tmpdir mine-pr to create a temp directory, then write the PR body to <dir>/body.md and use that path in subsequent commandsgh-pr-create --draft --title "..." --body-file <tmpfile>
az repos pr create --draft true --title "..." --description "<body content>" --source-branch <branch> --target-branch <default-branch>
--description "$(cat <tmpfile>)" — command substitution is broken in the Bash tool eval wrapper.CHANGELOG.md using the ancestor-walk algorithm: walk upward from the current working directory one level at a time toward the repo root, checking each directory for CHANGELOG.md — the first one found is the nearest. If none found by walking up, run git ls-files '*CHANGELOG.md' and pick the result with the shortest relative path from CWD. If no CHANGELOG.md exists anywhere, suggest the user add one. Once located:
# (e.g., (#123)) — links to the PR(!123)) — links to the PR (# would link to a work item instead)gh pr view --json baseRefName --jq '.baseRefName'ado-pr show --json | jq -r '.targetRefName' | sed 's|refs/heads/||'git diff origin/<base>...HEAD -- <changelog-path> to identify lines added in this branch- ) that does not already contain a PR reference ((#...) or (!...)), append (#<PR_NUMBER>) for GitHub or (!<PR_NUMBER>) for Azure DevOps to the end of the linechangelog: add PR #<NUMBER> for GitHub or changelog: add PR !<NUMBER> for Azure DevOpsCHANGELOG.md exists, suggest to the user that they add one to track notable changes per releasegh pr readyaz repos pr update --id <PR_ID> --draft falsedesign/specs/ exists in the repo and spec-helper is available (command -v spec-helper), run spec-helper archive --dry-run --json. If any entries have status: "would_archive", tell the user: "These specs are ready to archive: [list]. Run spec-helper archive --all to clean up tasks/ directories before merging." If none qualify, design/specs/ doesn't exist, or spec-helper isn't installed, skip silently. Run this check before composing the final response in step 11.You have the capability to call multiple tools in a single response. You should gather all necessary context first (steps 1-6), then create the PR in a single action. Do not create multiple PRs.
Important:
--body-file (GitHub) to avoid command substitutionAzure DevOps notes:
https://dev.azure.com/{org}/{project}/_git/{repo})--auto-complete or --delete-source-branch flags — just create the PRaz repos pr create command returns JSON; extract the PR URL from the response