About implement-issue
A skill for implementing GitHub issues from setup through code changes, tests, and commit. It guides coding agents to inspect repository conventions, work on an issue branch, and report verification results.
Key features
- 01Checks Git, gh authentication, and working-tree state
- 02Reads issue details and repository metadata
- 03Creates a categorized issue branch
- 04Analyzes code structure and implementation patterns
- 05Plans, implements, and tests changes
- 06Reports results and commits changes
Use cases
- 01Implementing a bug or feature described in a GitHub issue
- 02Adding tests while changing code to address an issue
- 03Preparing a documented implementation summary and commit
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ tenfyzhong/ skills-hub --skill implement-issueAfter installing, type/implement-issuein Claude Code to confirm it loaded.
Details
From the project READMEImplement Issue Skill
Implement a GitHub issue from start to finish: branch setup, codebase analysis, and implementation.
Prerequisites Check (MUST verify first)
Before proceeding, verify:
# 1. Check if in a git repository
git rev-parse --is-inside-work-tree
# 2. Check if gh CLI is available and authenticated
gh auth status
# 3. Check for uncommitted changes (warn user if any)
git status --porcelain
If checks fail, STOP and inform the user:
- Not in git repo → "This skill requires a git repository. Please navigate to a git project."
- gh not authenticated → "Please run
gh auth loginfirst." - Uncommitted changes → "You have uncommitted changes. Please commit or stash them first."
Input
The user provides an issue reference in one of these formats:
- Full URL:
https://github.com/owner/repo/issues/123 - Short form (if in repo):
#123or123
Workflow
Step 1: Extract Issue Information
# Get comprehensive issue metadata
gh issue view <ISSUE_NUMBER_OR_URL> --json number,title,body,state,author,labels,milestone,assignees,comments,createdAt,updatedAt
# Get repository info for branch naming
gh repo view --json owner,name,defaultBranchRef
Parse the issue to understand:
- Title: Brief summary of what needs to be done
- Body: Detailed requirements, acceptance criteria, context
- Labels: Type of work (bug, feature, enhancement, etc.)
- Comments: Additional context, discussions, clarifications
Step 2: Sync to Latest Main/Master Branch
# Detect default branch (main or master)
DEFAULT_BRANCH=$(gh repo view --json defaultBranchRef -q '.defaultBranchRef.name')
# Fetch latest changes
git fetch origin $DEFAULT_BRANCH
# Checkout and update default branch
git checkout $DEFAULT_BRANCH
git pull origin $DEFAULT_BRANCH
Step 3: Create Issue Branch
Generate a branch name based on the issue:
Branch naming convention: <type>/<issue-number>-<short-description>
| Issue Type (from labels) | Branch Prefix |
|---|---|
| bug, bugfix | fix/ |
| feature, enhancement | feat/ |
| docs, documentation | docs/ |
| refactor | refactor/ |
| test | test/ |
| chore | chore/ |
| (default) | issue/ |
Examples:
- Issue #42 "Add user authentication" →
feat/42-add-user-authentication - Issue #15 "Fix login redirect bug" →
fix/15-fix-login-redirect - Issue #99 "Update README" →
docs/99-update-readme
# Create and checkout new branch
git checkout -b <BRANCH_NAME>
Step 4: Deep Codebase Analysis
Before implementing, thoroughly understand the codebase:
4.1 Project Structure Analysis
# Get project structure overview
ls -la
find . -type f -name "*.json" -path "*/package.json" -o -name "*.toml" -path "*/Cargo.toml" -o -name "*.go" -path "*/go.mod" 2>/dev/null | head -20
# Check for configuration files
ls -la *.json *.yaml *.yml *.toml .* 2>/dev/null | head -20
4.2 Understand Existing Patterns
Use explore agents to understand:
- Architecture: How is the codebase organized? What are the main modules?
- Patterns: What coding patterns are used? (error handling, logging, testing)
- Related Code: What existing code is related to this issue?
- Dependencies: What libraries/frameworks are used?
# Fire multiple explore agents in parallel
background_task(agent="explore", prompt="Find the main entry points and understand the overall architecture of this codebase")
background_task(agent="explore", prompt="Find code related to [ISSUE_TOPIC] and understand existing patterns")
background_task(agent="explore", prompt="Find test patterns and testing conventions in this codebase")
4.3 Identify Implementation Points
Based on the issue requirements, identify:
- Which files need to be modified
- Which new files need to be created
- What tests need to be added/updated
- What documentation needs updating
Step 5: Create Implementation Plan
Before coding, create a detailed todo list:
todowrite([
{ id: "1", content: "Understand issue requirements fully", status: "completed", priority: "high" },
{ id: "2", content: "Analyze related codebase areas", status: "completed", priority: "high" },
{ id: "3", content: "[Specific implementation task 1]", status: "pending", priority: "high" },
{ id: "4", content: "[Specific implementation task 2]", status: "pending", priority: "medium" },
{ id: "5", content: "Add/update tests", status: "pending", priority: "high" },
{ id: "6", content: "Run tests and fix issues", status: "pending", priority: "high" },
{ id: "7", content: "Update documentation if needed", status: "pending", priority: "low" },
{ id: "8", content: "Final verification", status: "pending", priority: "high" }
])
Step 6: Implement the Solution
Follow these principles:
- Match Existing Patterns: Follow the codebase's established conventions
- Incremental Changes: Make small, focused changes
- Test as You Go: Verify each change works before moving on
- Document Complex Logic: Add comments where necessary
For each implementation task:
- Mark todo as
in_progress - Make the changes
- Run
lsp_diagnosticson changed files - Mark todo as
completed
Step 7: Testing
# Run project tests (detect test command from package.json, Makefile, etc.)
# Common patterns:
npm test
yarn test
go test ./...
cargo test
pytest
make test
Ensure:
- All existing tests pass
- New tests added for new functionality
- Edge cases covered
Step 8: Final Verification
# Check for any linting issues
# (detect lint command from project config)
# Verify build succeeds
# (detect build command from project config)
# Review all changes
git diff --stat
git diff
Step 9: Commit Changes
# Stage all changes
git add -A
# Create commit with conventional commit message
# Format: <type>(scope): <description>
#
# Reference the issue number in the commit body
git commit -s -m "<type>: <short description>
<detailed description of changes>
Closes #<ISSUE_NUMBER>"
Commit message examples:
feat: add user authentication systemfix: resolve login redirect loopdocs: update API documentation
Output Format
After completing the implementation, provide:
Implementation Summary
Issue: #[NUMBER] - [TITLE]
Branch: [BRANCH_NAME]
Status: [Implemented / Partially Implemented / Blocked]
Changes Made
| File | Change Type | Description |
|---|---|---|
path/to/file.ts | Modified | [What was changed] |
path/to/new-file.ts | Added | [What was added] |
Implementation Details
[2-5 sentences explaining what was implemented and how it addresses the issue]
Tests Added/Updated
- [Test 1 description]
- [Test 2 description]
Verification Results
| Check | Status | Notes |
|---|---|---|
| Build | Pass/Fail | [Notes] |
| Tests | Pass/Fail | [Notes] |
| Lint | Pass/Fail | [Notes] |
| Diagnostics | Clean/Issues | [Notes] |
Next Steps
Suggest to the user:
- Review changes:
git diff origin/<DEFAULT_BRANCH>...HEAD - Push branch:
git push -u origin <BRANCH_NAME> - Create PR:
gh pr create --title "<PR_TITLE>" --body "<PR_BODY>"
Or offer to create the PR automatically if requested.
Important Notes
- Understand Before Implementing: Spend adequate time understanding the issue and codebase
- Ask for Clarification: If issue requirements are unclear, ask before implementing
- Minimal Changes: Only change what's necessary to implement the issue
- Follow Conventions: Match the existing codebase style and patterns
- Test Thoroughly: Ensure changes don't break existing functionality
- Document: Update documentation if the change affects public APIs or user-facing features
Error Handling
| Situation | Action |
|---|---|
| Issue not found | Verify issue number/URL, check repository access |
| Branch already exists | Ask user: use existing branch or create new with suffix? |
| Merge conflicts | Report to user, suggest resolution steps |
| Tests failing | Investigate if pre-existing or caused by changes |
| Unclear requirements | Ask user for clarification before proceeding |
| Implementation blocked | Document blockers, suggest alternatives |