メニュー
Process GitHub issues end-to-end with TDD and parallel work. Use when asked to work on an issue, fix issue #N, pick issues to tackle, or batch-process several.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/laurigates/claude-plugins --skill git-issueコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| created | "2025-12-16T00:00:00.000Z" |
| modified | "2026-06-15T00:00:00.000Z" |
| reviewed | "2026-06-15T00:00:00.000Z" |
| allowed-tools | Bash(git status *), Bash(git diff *), Bash(git log *), Bash(git add *), Bash(git commit *), Bash(git push *), Bash(git switch *), Bash(git pull *), Bash(git stash *), Bash(gh issue *), Bash(gh pr *), Bash(gh repo *), Bash(gh label *), Bash(gh api *), Bash(pre-commit *), Read, Edit, Write, Grep, Glob, TodoWrite, AskUserQuestion, Task, mcp__github__create_pull_request, mcp__github__issue_read, mcp__github__list_issues |
| description | Process GitHub issues end-to-end with TDD and parallel work. Use when asked to work on an issue, fix issue #N, pick issues to tackle, or batch-process several. |
| args | [issues... (number | #N | URL)] [--auto] [--filter <label>] [--limit <n>] [--parallel] [--labels <l1,l2>] |
| argument-hint | [issues... (number | #N | URL)] [--auto] [--filter <label>] [--limit <n>] [--parallel] [--labels <l1,l2>] |
| disable-model-invocation | true |
| name | git-issue |
| Use this skill when... | Use X instead when... |
|---|---|
| Implementing a fix for one or more open issues with TDD and PR creation | Performing administrative ops (transfer, pin, lock, bulk edit) on issues (/git:issue-manage) |
| Picking issues from the backlog to work on, optionally in parallel | Periodically grooming open issues and PRs to close stale or completed ones (/git:triage) |
| Going from an issue number to a merged-ready PR end-to-end | Hierarchical sub-issue planning and tracking (/git:issue-hierarchy) |
git remote -vgit branch --show-currentgit status --porcelain=v2Open issues, open PRs, and available labels are fetched during execution (requires a configured git remote).
Parse these parameters from the command:
| Parameter | Description |
|---|---|
<issues...> | One or more issues as bare numbers, #N, or full GitHub issue URLs (https://github.com/<owner>/<repo>/issues/<N>), in any space- or comma-separated mix (see Step 0) |
--auto | Claude selects and prioritizes issues |
--filter <label> | Filter issues by label |
--limit <n> | Maximum number of issues to process |
--parallel | Process parallel groups simultaneously using Task agents |
--labels <label1,label2> | Apply labels to created PRs (defaults to issue's labels) |
Process GitHub issues using a TDD workflow with the main-branch development pattern.
Before counting tokens or detecting mode, normalize every non-flag token in
$ARGUMENTS into a (number, repo) pair. Accept these forms, in any space- or
comma-separated mix:
| Input form | Extract |
|---|---|
123 | number 123, repo = current remote |
#123 | number 123, repo = current remote |
https://github.com/<owner>/<repo>/issues/123 | number 123, repo = <owner>/<repo> |
.../issues/123#issuecomment-... | number 123 (drop the #... fragment), repo = <owner>/<repo> |
Rules:
#; strip a URL
#... fragment after the number./issues/<digits> URL shape (require trailing digits — a
/pull/<N>, /discussions/<N>, or bare /issues list URL is not a
ref). Leave --flag tokens and their values (e.g. --filter bug,enhancement)
untouched — never split a flag's comma-separated value into refs.<owner>/<repo> differs from the current remote (Context
git remote -v), record it as cross-repo and carry -R <owner>/<repo>
on every gh call for that issue (gh issue view <N> -R …,
gh api repos/<owner>/<repo>/…, gh pr edit … -R …). PR creation for a
cross-repo issue needs a branch in that repo — if the current checkout is not
that repo, surface it with AskUserQuestion rather than pushing to the wrong
remote.Use AskUserQuestion to prompt:
questions:
- header: "Issues"
question: "How would you like to select issues to work on?"
options:
- label: "Let me choose specific issues"
description: "Show issue list for manual selection"
- label: "Claude decides priority"
description: "Analyze issues and recommend which to tackle"
- label: "Filter by label"
description: "Select issues with a specific label"
For "Let me choose specific issues":
gh issue list --state open --json number,title,labels,assigneesmultiSelect: trueFor "Claude decides priority":
For "Filter by label":
/git:issue 123)Process directly with standard TDD workflow.
/git:issue 123 456 789)/git:issue --auto)Before processing multiple issues, analyze for:
Before sequencing or scoring, ask GitHub which issues are blocked by other open work via the native dependencies API:
gh api repos/$OWNER/$REPO/issues/$N/dependencies/blocked_by \
--jq '.[] | select(.state == "open") | .number'
If the list is non-empty:
#N is blocked by #X, #Y.Also fetch dependencies/blocking to understand downstream impact —
finishing an issue that blocks others may be higher leverage than finishing
an independent issue of the same size.
Identify issues that cannot be worked on simultaneously:
| Conflict Type | Detection Method |
|---|---|
| File overlap | Issues referencing same files/components |
| Logical conflicts | Opposing requirements (add vs remove) |
| Dependency chains | dependencies/blocked_by returns an open issue |
| Sub-issue ordering | Parent's sub_issues not yet complete |
Score each issue's implementability:
| Factor | Weight | Criteria |
|---|---|---|
| Clear requirements | 30% | Has acceptance criteria, specific details |
| Scope definition | 25% | Bounded scope, identifiable files |
| No conflicts | 20% | No overlapping work with other issues |
| Test strategy clear | 15% | TDD approach is obvious |
| Labels/priority | 10% | Has priority labels, milestone |
Threshold: 70%
If confidence < 70%, prompt user:
questions:
- header: "Low confidence"
question: "Issue #N has unclear requirements. How should I proceed?"
options:
- label: "Attempt anyway"
description: "Make best-effort attempt based on available info"
- label: "Ask for clarification"
description: "Request more details on the issue"
- label: "Skip this issue"
description: "Move to next issue in queue"
Identify issues that can be worked simultaneously:
Parallelizable when:
dependencies/blocked_byOutput format:
Parallel Groups:
Group 1: #123, #125 (both touch auth module - sequential)
Group 2: #124 (standalone - can run in parallel)
Group 3: #126, #127 (both touch UI - sequential)
Recommended: Run Groups 1, 2, 3 in parallel (3 agents)
git switch main && git pullgh issue view $N --json title,body,state,assignees,labelsRED phase: Write failing tests first
GREEN phase: Implement fix
REFACTOR phase: Improve code quality
git add -u and git add <new-files><type>: <description>
<optional body explaining the change>
Fixes #N
git push origin main:fix/issue-$NUse mcp__github__create_pull_request with:
head: fix/issue-$Nbase: maintitle: From issue title with fix: prefixbody: Include Fixes #$N to auto-linkAfter PR creation, apply labels:
gh pr edit <pr-number> --add-label "<labels>"
When --parallel is specified:
Agent tool with subagent_type: "general-purpose", prompt: "Process issue #N with TDD workflow..."
Issue reference at BOTTOM:
<type>: <description>
<optional body explaining the change>
Fixes #123
Multiple issues in single commit:
fix: resolve authentication and session handling
- Add token refresh logic
- Fix session timeout detection
Fixes #123
Fixes #125
# All work stays on main
git switch main && git pull
# ... make changes, commit on main ...
git push origin main:fix/issue-$N # Push to remote feature branch
# Create PR: head=fix/issue-$N, base=main
# Continue on main for next issue
After processing, report:
| Metric | Details |
|---|---|
| Issues processed | List of issue numbers |
| PRs created | PR numbers with links |
| Conflicts detected | Issues that were sequentialized |
| Issues skipped | Low confidence or user choice |
When a follow-up request continues an issue whose branch already has a PR, invoke
/git:pr-sync-check before adding commits. A pr_merged verdict means the PR
already landed — start a fresh branch off the updated default rather than building
on the merged branch; a behind verdict means a teammate / agent / CI auto-fix
pushed under you, so reconcile first. See .claude/rules/pr-branch-sync.md.