claude-github-skills 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +142 -0
- package/bin/install.js +69 -0
- package/commands/gh/fix-pr.md +127 -0
- package/commands/gh/review-pr.md +137 -0
- package/commands/gh/setup.md +75 -0
- package/commands/gh/work.md +111 -0
- package/package.json +36 -0
package/README.md
ADDED
|
@@ -0,0 +1,142 @@
|
|
|
1
|
+
# claude-github-skills
|
|
2
|
+
|
|
3
|
+
GitHub-focused skills for Claude Code. Work on issues, review PRs, and fix review feedback — all scoped to a single project.
|
|
4
|
+
|
|
5
|
+
## Install
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
npx claude-github-skills@latest
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
This copies the skill commands to `~/.claude/commands/gh/` (global install). For project-local install:
|
|
12
|
+
|
|
13
|
+
```bash
|
|
14
|
+
npx claude-github-skills@latest --local
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
Project-local install copies commands to `.claude/commands/gh/` in your current working directory, so the skills are only available when working in that project.
|
|
18
|
+
|
|
19
|
+
## Prerequisites
|
|
20
|
+
|
|
21
|
+
- [Claude Code](https://claude.ai/code) installed
|
|
22
|
+
- [GitHub CLI (`gh`)](https://cli.github.com/) installed and authenticated (`gh auth login`)
|
|
23
|
+
- [Node.js](https://nodejs.org/) >= 18.0.0
|
|
24
|
+
|
|
25
|
+
## Quick Start
|
|
26
|
+
|
|
27
|
+
1. Install the skills: `npx claude-github-skills@latest`
|
|
28
|
+
2. Open your project in Claude Code
|
|
29
|
+
3. Run `/gh:setup` to scope the skills to your repository
|
|
30
|
+
4. Start using `/gh:work`, `/gh:review-pr`, or `/gh:fix-pr`
|
|
31
|
+
|
|
32
|
+
## Commands
|
|
33
|
+
|
|
34
|
+
### `/gh:setup` — Onboarding (run this first)
|
|
35
|
+
|
|
36
|
+
Detects your project's GitHub remote, confirms it with you, and writes the scope to `CLAUDE.md`. All other commands read this scope to know which repo to target.
|
|
37
|
+
|
|
38
|
+
```
|
|
39
|
+
/gh:setup
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
What it does:
|
|
43
|
+
1. Verifies `gh` CLI is authenticated (`gh auth status`)
|
|
44
|
+
2. Detects the GitHub remote from `git remote get-url origin` (supports both HTTPS and SSH URLs)
|
|
45
|
+
3. Confirms the detected `owner/repo` with you
|
|
46
|
+
4. Verifies the repository exists and is accessible
|
|
47
|
+
5. Writes a `<!-- gh-skills-start -->` configuration block to your project's `CLAUDE.md` (creates the file if it doesn't exist, preserves existing content if it does)
|
|
48
|
+
|
|
49
|
+
The configuration block scopes all `/gh:*` commands to that single repository, preventing accidental interaction with other repos.
|
|
50
|
+
|
|
51
|
+
### `/gh:work <issue#>` — Work on an issue
|
|
52
|
+
|
|
53
|
+
Fetches the issue, creates a feature branch, implements the solution, and opens a draft PR.
|
|
54
|
+
|
|
55
|
+
```
|
|
56
|
+
/gh:work 27
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
What it does:
|
|
60
|
+
1. Reads issue #27 (title, body, labels, assignees, comments, state)
|
|
61
|
+
2. Creates branch `feat/27-<slug>` (e.g., `feat/27-add-user-auth`) — if the branch already exists, it checks it out so you can resume work
|
|
62
|
+
3. Explores the codebase, summarizes a 3–5 bullet implementation plan, then implements
|
|
63
|
+
4. Makes focused, incremental commits — each referencing the issue (e.g., `Add auth middleware (#27)`)
|
|
64
|
+
5. Pushes and creates a draft PR with a summary, change list, and `Closes #27` link
|
|
65
|
+
|
|
66
|
+
### `/gh:review-pr <pr#>` — Review a PR
|
|
67
|
+
|
|
68
|
+
Performs a focused code review on the PR's changed files and posts comments directly on GitHub.
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
/gh:review-pr 42
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
What it does:
|
|
75
|
+
1. Fetches the PR diff, metadata, and existing reviews
|
|
76
|
+
2. Reads full changed files for context, but reviews only the diff — does not critique untouched code
|
|
77
|
+
3. Checks for: correctness, security, error handling, naming clarity, test coverage, and performance issues
|
|
78
|
+
4. Skips nitpicks already handled by linters (style, formatting, subjective naming)
|
|
79
|
+
5. Posts a review summary with key findings and inline comments on specific lines
|
|
80
|
+
6. Approves the PR if no issues are found
|
|
81
|
+
7. For PRs with 15+ changed files, prioritizes core logic, largest diffs, and new files
|
|
82
|
+
8. Optionally offers to run Playwright for visual regression checks on UI changes (only if Playwright is in the project)
|
|
83
|
+
|
|
84
|
+
### `/gh:fix-pr <pr#>` — Fix review feedback
|
|
85
|
+
|
|
86
|
+
Reads all review comments on a PR and addresses each one.
|
|
87
|
+
|
|
88
|
+
```
|
|
89
|
+
/gh:fix-pr 42
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
What it does:
|
|
93
|
+
1. Fetches all inline review comments, conversation comments, and review threads
|
|
94
|
+
2. Filters to unresolved, actionable comments — skips resolved threads, acknowledgments, and already-answered questions
|
|
95
|
+
3. Presents a numbered list of items to address (with file, line, and requested change)
|
|
96
|
+
4. Checks out the PR branch and fixes each item
|
|
97
|
+
5. Groups related fixes into logical commits with descriptive messages
|
|
98
|
+
6. Pushes the fixes
|
|
99
|
+
7. Replies to each addressed comment on GitHub with a link to the fixing commit (e.g., `Fixed in abc1234`)
|
|
100
|
+
8. Reports any skipped comments with reasons (disagreement, out of scope, needs discussion)
|
|
101
|
+
|
|
102
|
+
## How It Works
|
|
103
|
+
|
|
104
|
+
- **Project scoping**: All commands read `CLAUDE.md` for the `<!-- gh-skills-start -->` block to find the scoped `owner/repo`. They refuse to run without it — run `/gh:setup` first.
|
|
105
|
+
- **GitHub CLI only**: Uses `gh` CLI exclusively. No API tokens needed beyond what `gh auth` provides.
|
|
106
|
+
- **Respects your setup**: Works alongside your existing Claude Code skills, plugins, and `CLAUDE.md` conventions.
|
|
107
|
+
- **Namespaced**: Commands live under `/gh:*` to avoid collisions with other skills.
|
|
108
|
+
- **No destructive actions**: Commands create branches and PRs but never force-push, delete branches, or merge without your approval.
|
|
109
|
+
|
|
110
|
+
## File Structure
|
|
111
|
+
|
|
112
|
+
```
|
|
113
|
+
claude-github-skills/
|
|
114
|
+
├── bin/
|
|
115
|
+
│ └── install.js # Installer — copies commands to ~/.claude or ./.claude
|
|
116
|
+
├── commands/
|
|
117
|
+
│ └── gh/
|
|
118
|
+
│ ├── setup.md # /gh:setup skill definition
|
|
119
|
+
│ ├── work.md # /gh:work skill definition
|
|
120
|
+
│ ├── review-pr.md # /gh:review-pr skill definition
|
|
121
|
+
│ └── fix-pr.md # /gh:fix-pr skill definition
|
|
122
|
+
├── package.json
|
|
123
|
+
└── README.md
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
## Uninstall
|
|
127
|
+
|
|
128
|
+
Remove the command files:
|
|
129
|
+
|
|
130
|
+
```bash
|
|
131
|
+
# Global install
|
|
132
|
+
rm -rf ~/.claude/commands/gh
|
|
133
|
+
|
|
134
|
+
# Project-local install
|
|
135
|
+
rm -rf .claude/commands/gh
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
And optionally remove the `<!-- gh-skills-start -->` to `<!-- gh-skills-end -->` block from your project's `CLAUDE.md`.
|
|
139
|
+
|
|
140
|
+
## License
|
|
141
|
+
|
|
142
|
+
MIT
|
package/bin/install.js
ADDED
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
const fs = require("fs");
|
|
4
|
+
const path = require("path");
|
|
5
|
+
|
|
6
|
+
const COMMANDS_DIR = "commands/gh";
|
|
7
|
+
|
|
8
|
+
function getClaudeHome() {
|
|
9
|
+
const home = process.env.HOME || process.env.USERPROFILE;
|
|
10
|
+
return path.join(home, ".claude");
|
|
11
|
+
}
|
|
12
|
+
|
|
13
|
+
function copyDirRecursive(src, dest) {
|
|
14
|
+
if (!fs.existsSync(dest)) {
|
|
15
|
+
fs.mkdirSync(dest, { recursive: true });
|
|
16
|
+
}
|
|
17
|
+
|
|
18
|
+
const entries = fs.readdirSync(src, { withFileTypes: true });
|
|
19
|
+
for (const entry of entries) {
|
|
20
|
+
const srcPath = path.join(src, entry.name);
|
|
21
|
+
const destPath = path.join(dest, entry.name);
|
|
22
|
+
|
|
23
|
+
if (entry.isDirectory()) {
|
|
24
|
+
copyDirRecursive(srcPath, destPath);
|
|
25
|
+
} else {
|
|
26
|
+
fs.copyFileSync(srcPath, destPath);
|
|
27
|
+
console.log(` Copied: ${entry.name}`);
|
|
28
|
+
}
|
|
29
|
+
}
|
|
30
|
+
}
|
|
31
|
+
|
|
32
|
+
function install() {
|
|
33
|
+
const args = process.argv.slice(2);
|
|
34
|
+
const isLocal = args.includes("--local");
|
|
35
|
+
|
|
36
|
+
let targetBase;
|
|
37
|
+
if (isLocal) {
|
|
38
|
+
targetBase = path.join(process.cwd(), ".claude");
|
|
39
|
+
} else {
|
|
40
|
+
targetBase = getClaudeHome();
|
|
41
|
+
}
|
|
42
|
+
|
|
43
|
+
const packageRoot = path.resolve(__dirname, "..");
|
|
44
|
+
const commandsSrc = path.join(packageRoot, COMMANDS_DIR);
|
|
45
|
+
const commandsDest = path.join(targetBase, COMMANDS_DIR);
|
|
46
|
+
|
|
47
|
+
if (!fs.existsSync(commandsSrc)) {
|
|
48
|
+
console.error("Error: commands directory not found at", commandsSrc);
|
|
49
|
+
process.exit(1);
|
|
50
|
+
}
|
|
51
|
+
|
|
52
|
+
console.log("\n claude-github-skills installer\n");
|
|
53
|
+
console.log(` Installing to: ${targetBase}\n`);
|
|
54
|
+
|
|
55
|
+
console.log(" Installing commands...");
|
|
56
|
+
copyDirRecursive(commandsSrc, commandsDest);
|
|
57
|
+
|
|
58
|
+
console.log("\n Installation complete!");
|
|
59
|
+
console.log("\n Available commands:");
|
|
60
|
+
console.log(" /gh:setup - Set up project (run this first)");
|
|
61
|
+
console.log(" /gh:work <#> - Work on a GitHub issue");
|
|
62
|
+
console.log(" /gh:review-pr <#> - Review a pull request");
|
|
63
|
+
console.log(" /gh:fix-pr <#> - Fix PR review feedback");
|
|
64
|
+
console.log("\n Prerequisites:");
|
|
65
|
+
console.log(" - GitHub CLI (gh) installed and authenticated");
|
|
66
|
+
console.log(" - Run /gh:setup in your project first\n");
|
|
67
|
+
}
|
|
68
|
+
|
|
69
|
+
install();
|
|
@@ -0,0 +1,127 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gh:fix-pr
|
|
3
|
+
description: Fix PR review feedback — reads review comments and addresses each one
|
|
4
|
+
argument-hint: "<pr-number>"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Bash
|
|
7
|
+
- Read
|
|
8
|
+
- Write
|
|
9
|
+
- Edit
|
|
10
|
+
- Glob
|
|
11
|
+
- Grep
|
|
12
|
+
- Agent
|
|
13
|
+
- AskUserQuestion
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
<role>
|
|
17
|
+
You are a developer addressing PR review feedback. You read every review comment, understand what's being asked, and make the fixes. You're methodical — you address each comment one by one and don't miss any.
|
|
18
|
+
</role>
|
|
19
|
+
|
|
20
|
+
<objective>
|
|
21
|
+
Given a PR number, read all review comments and conversation comments, then fix every actionable item.
|
|
22
|
+
</objective>
|
|
23
|
+
|
|
24
|
+
<context>
|
|
25
|
+
PR number: $ARGUMENTS
|
|
26
|
+
</context>
|
|
27
|
+
|
|
28
|
+
<process>
|
|
29
|
+
|
|
30
|
+
## Step 1: Read project scope
|
|
31
|
+
|
|
32
|
+
Read `CLAUDE.md` in the project root. Look for the `<!-- gh-skills-start -->` block to find the scoped `owner/repo`.
|
|
33
|
+
|
|
34
|
+
If the block is missing, tell the user to run `/gh:setup` first and stop.
|
|
35
|
+
|
|
36
|
+
## Step 2: Fetch PR and review comments
|
|
37
|
+
|
|
38
|
+
Gather all feedback:
|
|
39
|
+
|
|
40
|
+
```bash
|
|
41
|
+
# PR details and conversation comments
|
|
42
|
+
gh pr view $ARGUMENTS --repo owner/repo --json title,body,headRefName,comments,reviews
|
|
43
|
+
|
|
44
|
+
# Inline review comments (file-level and line-level)
|
|
45
|
+
gh api repos/owner/repo/pulls/$ARGUMENTS/comments --paginate
|
|
46
|
+
|
|
47
|
+
# Review threads (to see which are resolved vs unresolved)
|
|
48
|
+
gh api repos/owner/repo/pulls/$ARGUMENTS/reviews --paginate
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
## Step 3: Check out the PR branch
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
gh pr checkout $ARGUMENTS --repo owner/repo
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
If already on the branch, just make sure it's up to date:
|
|
58
|
+
```bash
|
|
59
|
+
git pull origin $(gh pr view $ARGUMENTS --repo owner/repo --json headRefName --jq .headRefName)
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
## Step 4: Catalog all feedback
|
|
63
|
+
|
|
64
|
+
Parse all comments and create a list of actionable items. For each comment, note:
|
|
65
|
+
- The file and line it references (if inline)
|
|
66
|
+
- What change is being requested
|
|
67
|
+
- Whether it's resolved or unresolved
|
|
68
|
+
|
|
69
|
+
Focus on **unresolved** comments. Skip:
|
|
70
|
+
- Already resolved threads
|
|
71
|
+
- Comments that are just acknowledgments ("looks good", "thanks")
|
|
72
|
+
- Questions that were already answered in the thread
|
|
73
|
+
|
|
74
|
+
Present the list to the user:
|
|
75
|
+
> "Found **N** actionable review comments:"
|
|
76
|
+
> 1. `file.ts:42` — "Should handle the null case here"
|
|
77
|
+
> 2. `utils.ts:15` — "This function name is misleading"
|
|
78
|
+
> ...
|
|
79
|
+
|
|
80
|
+
## Step 5: Address each comment
|
|
81
|
+
|
|
82
|
+
For each actionable item:
|
|
83
|
+
|
|
84
|
+
1. Read the relevant file and understand the context
|
|
85
|
+
2. Make the fix
|
|
86
|
+
3. After fixing, move to the next item
|
|
87
|
+
|
|
88
|
+
Group related fixes into logical commits:
|
|
89
|
+
|
|
90
|
+
```bash
|
|
91
|
+
git add <files>
|
|
92
|
+
git commit -m "Address review feedback: <summary>
|
|
93
|
+
|
|
94
|
+
- <fix 1>
|
|
95
|
+
- <fix 2>
|
|
96
|
+
"
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
If a comment is unclear or you disagree with it, ask the user for guidance rather than guessing.
|
|
100
|
+
|
|
101
|
+
## Step 6: Push the fixes
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
git push
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
## Step 7: Reply to comments (optional)
|
|
108
|
+
|
|
109
|
+
For each addressed comment, post a reply indicating it's been fixed:
|
|
110
|
+
|
|
111
|
+
```bash
|
|
112
|
+
gh api repos/owner/repo/pulls/$ARGUMENTS/comments/<comment-id>/replies \
|
|
113
|
+
--method POST \
|
|
114
|
+
-f body="Fixed in $(git rev-parse --short HEAD)"
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
If a comment was not addressed (disagreement, needs discussion, out of scope), post a reply explaining why.
|
|
118
|
+
|
|
119
|
+
## Step 8: Report back
|
|
120
|
+
|
|
121
|
+
Tell the user:
|
|
122
|
+
- How many comments were addressed
|
|
123
|
+
- What commits were created
|
|
124
|
+
- Any comments that were skipped and why
|
|
125
|
+
- Remind them to re-request review if needed
|
|
126
|
+
|
|
127
|
+
</process>
|
|
@@ -0,0 +1,137 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gh:review-pr
|
|
3
|
+
description: Review a GitHub PR — analyzes diff, checks correctness, posts review comments
|
|
4
|
+
argument-hint: "<pr-number>"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Bash
|
|
7
|
+
- Read
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Agent
|
|
11
|
+
- AskUserQuestion
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
<role>
|
|
15
|
+
You are a thorough but focused code reviewer. You review only the changes in the PR — you do not wander into unrelated parts of the codebase. You provide actionable, specific feedback and post it directly on the PR.
|
|
16
|
+
</role>
|
|
17
|
+
|
|
18
|
+
<objective>
|
|
19
|
+
Given a PR number, perform a focused code review on the changed files and post review comments via the GitHub CLI.
|
|
20
|
+
</objective>
|
|
21
|
+
|
|
22
|
+
<context>
|
|
23
|
+
PR number: $ARGUMENTS
|
|
24
|
+
</context>
|
|
25
|
+
|
|
26
|
+
<process>
|
|
27
|
+
|
|
28
|
+
## Step 1: Read project scope
|
|
29
|
+
|
|
30
|
+
Read `CLAUDE.md` in the project root. Look for the `<!-- gh-skills-start -->` block to find the scoped `owner/repo`.
|
|
31
|
+
|
|
32
|
+
If the block is missing, tell the user to run `/gh:setup` first and stop.
|
|
33
|
+
|
|
34
|
+
## Step 2: Fetch PR details
|
|
35
|
+
|
|
36
|
+
Run these commands to gather context:
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
# PR metadata
|
|
40
|
+
gh pr view $ARGUMENTS --repo owner/repo --json title,body,author,baseRefName,headRefName,files,state,reviews,comments
|
|
41
|
+
|
|
42
|
+
# The full diff
|
|
43
|
+
gh pr diff $ARGUMENTS --repo owner/repo
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
If the PR doesn't exist or is already merged/closed, inform the user and stop.
|
|
47
|
+
|
|
48
|
+
## Step 3: Understand the PR scope
|
|
49
|
+
|
|
50
|
+
From the PR body and title, understand:
|
|
51
|
+
- What problem this PR is solving
|
|
52
|
+
- What approach was taken
|
|
53
|
+
- Which files were changed
|
|
54
|
+
|
|
55
|
+
List the changed files. This is your review boundary — do NOT review files outside this set.
|
|
56
|
+
|
|
57
|
+
## Step 4: Read changed files for context
|
|
58
|
+
|
|
59
|
+
For each changed file, read the full file to understand the context around the changes. But focus your review only on the diff — don't critique existing code that wasn't touched.
|
|
60
|
+
|
|
61
|
+
If there are more than 15 changed files, prioritize:
|
|
62
|
+
1. Core logic files (not generated, not config)
|
|
63
|
+
2. Files with the most lines changed
|
|
64
|
+
3. New files (need more scrutiny than modifications)
|
|
65
|
+
|
|
66
|
+
## Step 5: Analyze the changes
|
|
67
|
+
|
|
68
|
+
Review the diff for:
|
|
69
|
+
|
|
70
|
+
- **Correctness**: Does the code do what the PR says it does? Are there logic errors, off-by-one bugs, missed edge cases?
|
|
71
|
+
- **Security**: Any injection risks, exposed secrets, unsafe operations?
|
|
72
|
+
- **Error handling**: Are failures handled appropriately at system boundaries?
|
|
73
|
+
- **Naming and clarity**: Are new functions/variables named clearly? Would a reader understand the intent?
|
|
74
|
+
- **Tests**: Are there tests for the changes? Are important paths covered?
|
|
75
|
+
- **Performance**: Any obvious N+1 queries, unnecessary loops, or memory issues?
|
|
76
|
+
|
|
77
|
+
Do NOT nitpick:
|
|
78
|
+
- Style preferences already handled by linters
|
|
79
|
+
- Minor formatting issues
|
|
80
|
+
- Subjective naming opinions when the current name is clear enough
|
|
81
|
+
|
|
82
|
+
## Step 6: Post the review
|
|
83
|
+
|
|
84
|
+
If you have comments, post a review with inline comments:
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
gh pr review $ARGUMENTS --repo owner/repo --comment --body "$(cat <<'EOF'
|
|
88
|
+
## Code Review
|
|
89
|
+
|
|
90
|
+
<overall assessment — 2-3 sentences>
|
|
91
|
+
|
|
92
|
+
### Key Findings
|
|
93
|
+
<bullet list of the most important items>
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
Reviewed with Claude Code (/gh:review-pr)
|
|
97
|
+
EOF
|
|
98
|
+
)"
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
For specific line-level feedback, post individual review comments on the relevant files and lines:
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
gh api repos/owner/repo/pulls/$ARGUMENTS/comments \
|
|
105
|
+
--method POST \
|
|
106
|
+
-f body="<comment>" \
|
|
107
|
+
-f path="<file-path>" \
|
|
108
|
+
-f commit_id="$(gh pr view $ARGUMENTS --repo owner/repo --json headRefOid --jq .headRefOid)" \
|
|
109
|
+
-f subject_type="line" \
|
|
110
|
+
-F line=<line-number> \
|
|
111
|
+
-f side="RIGHT"
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
If the PR looks good with no issues, approve it:
|
|
115
|
+
|
|
116
|
+
```bash
|
|
117
|
+
gh pr review $ARGUMENTS --repo owner/repo --approve --body "Looks good! No issues found. Reviewed with Claude Code (/gh:review-pr)"
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
## Step 7: Optional — Playwright visual check
|
|
121
|
+
|
|
122
|
+
If the PR modifies UI files (components, templates, CSS, pages) AND Playwright is available in the project:
|
|
123
|
+
|
|
124
|
+
1. Check if `playwright` is in package.json dependencies
|
|
125
|
+
2. If available, suggest to the user: "This PR has UI changes. Want me to run Playwright to screenshot and check for visual regressions?"
|
|
126
|
+
3. Only proceed if the user confirms
|
|
127
|
+
|
|
128
|
+
If Playwright is not available, skip this step entirely.
|
|
129
|
+
|
|
130
|
+
## Step 8: Report back
|
|
131
|
+
|
|
132
|
+
Tell the user:
|
|
133
|
+
- How many comments were posted
|
|
134
|
+
- The overall assessment (looks good / needs changes / has concerns)
|
|
135
|
+
- A brief summary of the key findings
|
|
136
|
+
|
|
137
|
+
</process>
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gh:setup
|
|
3
|
+
description: Set up GitHub project scope for gh skills (run this first)
|
|
4
|
+
allowed-tools:
|
|
5
|
+
- Bash
|
|
6
|
+
- Read
|
|
7
|
+
- Write
|
|
8
|
+
- Edit
|
|
9
|
+
- AskUserQuestion
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
<role>
|
|
13
|
+
You are a GitHub project onboarding assistant. Your job is to detect the current project's GitHub remote, confirm it with the user, and write the project scope into CLAUDE.md so all other gh skills know which repository to target.
|
|
14
|
+
</role>
|
|
15
|
+
|
|
16
|
+
<objective>
|
|
17
|
+
Set up the current project for use with gh:work, gh:review-pr, and gh:fix-pr by:
|
|
18
|
+
1. Detecting the GitHub remote
|
|
19
|
+
2. Confirming the project with the user
|
|
20
|
+
3. Writing the scope to CLAUDE.md
|
|
21
|
+
</objective>
|
|
22
|
+
|
|
23
|
+
<process>
|
|
24
|
+
|
|
25
|
+
## Step 1: Check prerequisites
|
|
26
|
+
|
|
27
|
+
Run `gh auth status` to verify the GitHub CLI is authenticated. If not, tell the user to run `gh auth login` first and stop.
|
|
28
|
+
|
|
29
|
+
## Step 2: Detect the GitHub remote
|
|
30
|
+
|
|
31
|
+
Run `git remote get-url origin` to get the remote URL. Parse the `owner/repo` from it — handle both HTTPS (`https://github.com/owner/repo.git`) and SSH (`git@github.com:owner/repo.git`) formats. Strip any trailing `.git`.
|
|
32
|
+
|
|
33
|
+
## Step 3: Confirm with the user
|
|
34
|
+
|
|
35
|
+
Present the detected project to the user:
|
|
36
|
+
|
|
37
|
+
> "Detected GitHub project: **owner/repo**. Is this the project you want to work with for gh skills?"
|
|
38
|
+
|
|
39
|
+
If the user says no, ask them to provide the correct `owner/repo`.
|
|
40
|
+
|
|
41
|
+
## Step 4: Verify the project exists
|
|
42
|
+
|
|
43
|
+
Run `gh repo view owner/repo --json name,owner` to confirm the repository exists and is accessible.
|
|
44
|
+
|
|
45
|
+
## Step 5: Write to CLAUDE.md
|
|
46
|
+
|
|
47
|
+
Read the existing `CLAUDE.md` in the project root if it exists.
|
|
48
|
+
|
|
49
|
+
If a `<!-- gh-skills-start -->` section already exists, replace it. Otherwise, append the section.
|
|
50
|
+
|
|
51
|
+
Add the following block:
|
|
52
|
+
|
|
53
|
+
```markdown
|
|
54
|
+
<!-- gh-skills-start -->
|
|
55
|
+
## GitHub Skills Configuration
|
|
56
|
+
|
|
57
|
+
- **Project**: owner/repo
|
|
58
|
+
- All `/gh:*` commands are scoped to this repository only.
|
|
59
|
+
- Do NOT interact with issues or PRs outside of `owner/repo`.
|
|
60
|
+
- Prerequisites: `gh` CLI must be installed and authenticated.
|
|
61
|
+
<!-- gh-skills-end -->
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
**Important**: Preserve all existing content in CLAUDE.md. Only add or replace the `<!-- gh-skills-start -->` to `<!-- gh-skills-end -->` block.
|
|
65
|
+
|
|
66
|
+
## Step 6: Confirm completion
|
|
67
|
+
|
|
68
|
+
Tell the user:
|
|
69
|
+
|
|
70
|
+
> "Setup complete! Project scoped to **owner/repo**. You can now use:"
|
|
71
|
+
> - `/gh:work <issue#>` — work on a GitHub issue
|
|
72
|
+
> - `/gh:review-pr <pr#>` — review a pull request
|
|
73
|
+
> - `/gh:fix-pr <pr#>` — fix PR review feedback
|
|
74
|
+
|
|
75
|
+
</process>
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gh:work
|
|
3
|
+
description: Work on a GitHub issue — fetches details, creates branch, implements, and opens a draft PR
|
|
4
|
+
argument-hint: "<issue-number>"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Bash
|
|
7
|
+
- Read
|
|
8
|
+
- Write
|
|
9
|
+
- Edit
|
|
10
|
+
- Glob
|
|
11
|
+
- Grep
|
|
12
|
+
- Agent
|
|
13
|
+
- AskUserQuestion
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
<role>
|
|
17
|
+
You are a developer working on a GitHub issue. You fetch the issue, understand the requirements, create a branch, implement the solution, and open a draft PR. You stay scoped to the configured project and respect the user's existing skills and workflows.
|
|
18
|
+
</role>
|
|
19
|
+
|
|
20
|
+
<objective>
|
|
21
|
+
Given an issue number, fully implement the work described in that issue within the scoped GitHub project.
|
|
22
|
+
</objective>
|
|
23
|
+
|
|
24
|
+
<context>
|
|
25
|
+
Issue number: $ARGUMENTS
|
|
26
|
+
</context>
|
|
27
|
+
|
|
28
|
+
<process>
|
|
29
|
+
|
|
30
|
+
## Step 1: Read project scope
|
|
31
|
+
|
|
32
|
+
Read `CLAUDE.md` in the project root. Look for the `<!-- gh-skills-start -->` block to find the scoped `owner/repo`.
|
|
33
|
+
|
|
34
|
+
If the block is missing, tell the user to run `/gh:setup` first and stop.
|
|
35
|
+
|
|
36
|
+
## Step 2: Fetch the issue
|
|
37
|
+
|
|
38
|
+
Run:
|
|
39
|
+
```bash
|
|
40
|
+
gh issue view $ARGUMENTS --repo owner/repo --json title,body,labels,assignees,comments,state
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
If the issue doesn't exist or is closed, inform the user and stop.
|
|
44
|
+
|
|
45
|
+
Read the full issue body, labels, and all comments to understand:
|
|
46
|
+
- What needs to be done
|
|
47
|
+
- Any acceptance criteria
|
|
48
|
+
- Any technical guidance from comments
|
|
49
|
+
- Related issues or PRs mentioned
|
|
50
|
+
|
|
51
|
+
## Step 3: Create a working branch
|
|
52
|
+
|
|
53
|
+
Generate a branch name from the issue: `feat/<issue#>-<short-slug>` (e.g., `feat/27-add-user-auth`).
|
|
54
|
+
|
|
55
|
+
The slug should be lowercase, hyphenated, max 5 words from the issue title.
|
|
56
|
+
|
|
57
|
+
```bash
|
|
58
|
+
git checkout -b feat/<issue#>-<slug>
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
If the branch already exists, check it out instead (the user may be resuming work).
|
|
62
|
+
|
|
63
|
+
## Step 4: Plan the implementation
|
|
64
|
+
|
|
65
|
+
Before writing any code:
|
|
66
|
+
1. Explore the relevant parts of the codebase to understand the existing patterns
|
|
67
|
+
2. Summarize your implementation plan to the user in 3-5 bullet points
|
|
68
|
+
3. Proceed with implementation (do not wait for approval unless the scope is ambiguous)
|
|
69
|
+
|
|
70
|
+
## Step 5: Implement
|
|
71
|
+
|
|
72
|
+
Write the code to address the issue. Follow existing code patterns, conventions, and style in the project. If CLAUDE.md has coding conventions, follow them.
|
|
73
|
+
|
|
74
|
+
Make focused, incremental commits as you work. Each commit message should reference the issue:
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
<description> (#<issue#>)
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
## Step 6: Push and create a draft PR
|
|
81
|
+
|
|
82
|
+
Push the branch:
|
|
83
|
+
```bash
|
|
84
|
+
git push -u origin feat/<issue#>-<slug>
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
Create a draft PR:
|
|
88
|
+
```bash
|
|
89
|
+
gh pr create --repo owner/repo --draft --title "<concise title>" --body "$(cat <<'EOF'
|
|
90
|
+
## Summary
|
|
91
|
+
<what was done and why>
|
|
92
|
+
|
|
93
|
+
## Changes
|
|
94
|
+
<bullet list of key changes>
|
|
95
|
+
|
|
96
|
+
Closes #<issue#>
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
Worked on with Claude Code
|
|
100
|
+
EOF
|
|
101
|
+
)"
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
## Step 7: Report back
|
|
105
|
+
|
|
106
|
+
Tell the user:
|
|
107
|
+
- The PR URL
|
|
108
|
+
- A brief summary of what was implemented
|
|
109
|
+
- Any decisions you made or trade-offs worth noting
|
|
110
|
+
|
|
111
|
+
</process>
|
package/package.json
ADDED
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "claude-github-skills",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "GitHub-focused skills for Claude Code: work on issues, review PRs, fix PR feedback",
|
|
5
|
+
"bin": {
|
|
6
|
+
"claude-github-skills": "bin/install.js"
|
|
7
|
+
},
|
|
8
|
+
"files": [
|
|
9
|
+
"bin/",
|
|
10
|
+
"commands/"
|
|
11
|
+
],
|
|
12
|
+
"scripts": {
|
|
13
|
+
"test": "echo \"No tests yet\" && exit 0"
|
|
14
|
+
},
|
|
15
|
+
"keywords": [
|
|
16
|
+
"claude",
|
|
17
|
+
"claude-code",
|
|
18
|
+
"github",
|
|
19
|
+
"skills",
|
|
20
|
+
"pr-review",
|
|
21
|
+
"issue-workflow"
|
|
22
|
+
],
|
|
23
|
+
"author": "chinofyoung",
|
|
24
|
+
"license": "MIT",
|
|
25
|
+
"repository": {
|
|
26
|
+
"type": "git",
|
|
27
|
+
"url": "https://github.com/chinofyoung/claude.git"
|
|
28
|
+
},
|
|
29
|
+
"homepage": "https://github.com/chinofyoung/claude#readme",
|
|
30
|
+
"bugs": {
|
|
31
|
+
"url": "https://github.com/chinofyoung/claude/issues"
|
|
32
|
+
},
|
|
33
|
+
"engines": {
|
|
34
|
+
"node": ">=18.0.0"
|
|
35
|
+
}
|
|
36
|
+
}
|