How I Use Claude Skills to Quickly Work Through GitHub Issues

Overview

When working on GitHub issues, I do the same thing every time - check for duplicates, determine if it's a bug or feature, research existing PRs, and set up my environment. With Claude Code skills, I've automated all of this into a single command.

The Problem with Manual Issue Triage

When I get a new issue on an open source project, here's what I typically need to do:

1. Read and understand the issue
2. Search for duplicate issues
3. Check if there's already a PR addressing it
4. Determine if it's a bug fix or feature request
5. Set up a branch or worktree
6. Research the codebase to understand the problem
7. Write tests to reproduce the bug
8. Implement the fix

This is tedious, repetitive work. And with AI, we can automate most of it.

The Start Issue Skill

I created a /start-issue skill that handles all of this automatically. When I run:

/start-issue 1016

It kicks off a workflow that:

1. Fetches the issue details from GitHub
2. Detects the issue type - is this a bug or a feature request?
3. Searches for duplicates - existing issues and PRs that might address this
4. Offers to create a worktree - for isolated development
5. Runs the appropriate workflow based on issue type

Why Worktrees Matter

I do a lot of work with git worktrees now, especially for AI-assisted development. Here's why:

• I can have multiple issues being researched simultaneously
• Each worktree can have its own Claude session
• PRs in progress can be pulled down for review without switching branches
• Nothing conflicts or steps on each other

At any given time, I might have 4-5 projects open, with 5-10 tasks per project. Worktrees let me keep all of this separated cleanly.

Bug Fix Workflow

When the skill detects a bug report, it follows test-driven development:

1. Understand the bug from the issue description and any logs provided
2. Write a failing test that reproduces the issue
3. Implement the fix
4. Verify the test passes
5. Run the full test suite
6. Create a commit and PR

This mirrors exactly how I would approach it as a senior developer. I've been writing code for 30+ years, and I know that the first thing you do with a bug is write a test that fails.

Feature Workflow

For feature requests, the workflow is different:

1. Gather requirements - acceptance criteria, user expectations, technical constraints
2. Research the codebase - understand existing patterns
3. Define completion criteria
4. Create base branches
5. Implement with tests

Real Example: LiteStream Azure Issue

Let me walk through a real example. An issue came in for LiteStream about being unable to restore from Azure on different machines. I had no idea what the problem was - I don't even use Azure.

Running /start-issue 1016:

1. Claude detected it as a bug report
2. Searched for duplicate issues (none found)
3. Analyzed the error logs from the issue
4. Proposed a fix around iterator error handling

Now, I wasn't convinced this was the actual fix. The skill suggested code changes, but I pushed back:

"I don't see a test. I don't see us creating a test to replicate this issue prior to fixing it."

Claude acknowledged the testing challenge (Azure integration tests are hard), but I pushed further:

"Let's use Docker to try to create a set of tests that will replicate this."

This is where AI gets it wrong often - it wants to jump to code changes. As a senior developer, I know we need to reproduce the bug first.

The Result

Claude spun up Docker containers with Azure storage emulation, wrote data, took snapshots, and attempted restoration. While we couldn't reproduce the exact error (likely a config issue on the user's end), we did find a real bug: we weren't checking iterator errors properly.

The fix might not solve the user's immediate problem, but it improves error diagnostics so we can help them figure out what's actually wrong.

Pushing Back on AI

This example highlights something important: you have to push back on AI.

Claude wanted to: - Skip writing tests - Make code changes without reproducing the bug - Consider the job done after a quick fix

I had to redirect it multiple times. This is where 30 years of experience matters. AI doesn't replace senior developers - it amplifies them.

The Skills Are Free

All of these skills are available in my gopher-ai repo. I update them almost daily as Claude changes and as I refine the workflows.

They work with Claude Code, and I've recently added support for Codex and Gemini CLIs as well.

Trust But Verify

I never trust AI output blindly. After Claude creates a PR:

1. I read every line of the PR description
2. I review every code change
3. I verify tests actually test what they claim
4. I check that the solution matches my mental model

AI is a junior developer who types fast. Great output, but needs review.