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 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
+ }