Fixing GitHub issues is one of those workflows that should be simple but never is. You read the issue. You find the code. You write a fix. You push a branch. You open a PR. You wait for reviews. You address feedback. Each step is straightforward; the aggregate is tedious enough that a stack of open issues becomes background noise.

The gh-issues skill removes the tedium. Point it at a repository, and it fetches open issues, spawns parallel sub-agents that each implement a fix on their own branch, opens pull requests, and — after reviewers weigh in — spawns more agents to address the feedback. The whole cycle runs with a single command.

This post breaks down how it works, when it works well, and where it fits in a real development workflow.

What the Skill Actually Does

At its core, gh-issues is an orchestrator. It doesn’t write code itself. Instead, it coordinates a multi-phase pipeline:

1. Fetch — Pulls open issues from the GitHub REST API, filtered by label, milestone, assignee, or state.
2. Triage — Presents the issues in a table and asks which ones to process (or auto-processes all in cron mode).
3. Pre-flight checks — Verifies git auth, checks for existing PRs or in-progress branches, validates the token, and records the base branch.
4. Parallel fix — Spawns up to 8 sub-agents concurrently. Each agent reads the issue, searches the codebase, implements a fix, runs tests, commits, pushes a fix/issue-{N} branch, and opens a PR.
5. Review handling — After PRs are open, the skill fetches review comments (inline, general, and even embedded tool reviews like Greptile), determines which are actionable, and spawns agents to push fixes and reply to each comment thread.

Every step uses curl against the GitHub REST API directly — no gh CLI dependency, which makes it portable across any environment with curl, git, and a GH_TOKEN.

A Real Workflow: From Issue to Merged PR

Here’s what a typical run looks like. You invoke the skill with:

/gh-issues owner/repo --label bug --limit 5

The skill fetches up to 5 open issues labeled “bug” and displays them:

| #   | Title                         | Labels        |
| --- | ----------------------------- | ------------- |
| 42  | Fix null pointer in parser    | bug, critical |
| 37  | Add retry logic for API calls | bug           |
| 28  | Timeout on large payloads     | bug, perf     |

You type all (or specific issue numbers). The skill runs pre-flight checks — dirty working tree warnings, existing PR detection, branch collision checks, and a claim-based deduplication system that prevents two cron runs from processing the same issue simultaneously.

Then it spawns three sub-agents in parallel. Each one:

1. Runs a confidence check (1–10 scale). If it scores below 7 — the issue is too vague, the code can’t be located, or the scope is too wide — it skips the issue with a clear explanation instead of guessing.
2. Creates a fix/issue-42 branch from the base.
3. Searches the codebase with grep/find, reads relevant files, identifies root cause.
4. Implements the minimal fix, following existing code style.
5. Discovers and runs the test suite (package.json scripts, Makefile targets, pytest, cargo test — whatever’s there).
6. Commits with a conventional commit message referencing the issue.
7. Pushes and opens a PR with a structured body: summary, changes list, testing notes, and a Fixes #42 closing reference.

Three minutes later you have three PRs open, each linked to its source issue, each with test results documented.

The Confidence Check: Knowing When Not to Fix

The most underappreciated part of this skill is what it doesn’t do. Before writing any code, each sub-agent evaluates whether the issue is actually fixable:

• Is the problem clearly described?
• Can the relevant code be located in the repo?
• Is the scope reasonable (single file/function vs. entire subsystem)?
• Is a specific fix suggested, or is it a vague complaint?

If the confidence score lands below 7, the agent reports its analysis and moves on. This prevents the worst outcome of automated fixing: a PR that technically changes something but doesn’t address the actual problem. Half-baked PRs waste reviewer time, and the skill’s authors clearly thought about that.

Fork Mode and Open Source Contributions

One of the more thoughtful features is fork mode. If you’re contributing to a repository you don’t have push access to, you pass --fork user/repo:

/gh-issues upstream/project --fork myuser/project --label "good first issue" --limit 3

Issues are fetched from upstream/project. Branches get pushed to myuser/project. PRs are opened from the fork to upstream. The skill manages the git remote configuration automatically, adding a fork remote with token-based auth if it doesn’t exist.

This makes it viable for open source triage: point it at a project’s “good first issue” label, let it attempt fixes from your fork, review the PRs it opens, and submit the ones that look correct. You’re not blindly merging — you’re using automation to draft PRs that you then review and refine.

Watch Mode and Cron: Continuous Issue Processing

For ongoing maintenance, the skill supports two persistent modes:

Watch mode

Adding --watch --interval 5 keeps the skill polling every 5 minutes. It tracks processed issues and addressed review comments between cycles, only picks up new work, and runs Phase 6 (review handling) on every cycle for all tracked PRs. You can stop it anytime.

Cron mode

--cron is designed for scheduled execution. It auto-confirms issues (no interactive prompt), processes one issue per invocation using a cursor file for sequential tracking, and exits immediately after spawning — fire-and-forget. A separate cron schedule with --cron --reviews-only handles incoming review comments.

The sequential cursor prevents the stampede problem: if your cron fires every 30 minutes and there are 20 open issues, it works through them one at a time rather than spawning 20 agents simultaneously. The claim-based deduplication (with a 2-hour expiry) ensures overlapping cron runs don’t duplicate work.

Combined, a typical cron setup looks like:

# Fix one issue every 30 minutes
/gh-issues owner/repo --label bug --cron

# Check for review comments every hour
/gh-issues owner/repo --cron --reviews-only

Review Handling: Closing the Loop

Opening a PR is step one. The real work starts when reviewers comment. Phase 6 of the skill handles this by:

1. Discovering all open fix/issue-* PRs in the repository.
2. Fetching review comments from every source: PR reviews, inline comments, general conversation comments, and even embedded review tool output (the skill parses Greptile’s HTML comment markers).
3. Filtering for actionability: approvals, “LGTM” messages, and bot-generated informational comments are skipped. Comments containing phrases like “please fix,” “change this,” “will break,” or specific code concerns are flagged for action.
4. Spawning review-fix agents that check out the PR branch, implement the requested changes, push an update, and reply to each comment thread with “Addressed in commit {sha} — {description}.”

The reply step matters. Reviewers get notified that their feedback was addressed, with a link to the specific commit. No silent pushes that leave people wondering if their comments were seen.

What the Skill Handles Well

• Well-scoped bug fixes — Issues that describe a specific problem in a specific location. “The parser throws a null pointer when input is empty” is ideal.
• Test-backed codebases — When there’s an existing test suite, the sub-agents run it and catch regressions. The feedback loop is tight.
• Repositories with clear structure — Standard project layouts (src/, tests/, reasonable naming) make it easier for agents to find relevant code.
• Conventional workflows — Branch-per-fix, PR-based review, conventional commits — the skill follows the patterns most teams already use.

Where It Struggles

Being honest about limitations matters more than a feature list:

• Vague issues — “The app is slow sometimes” gives the confidence check nothing to work with. It’ll correctly skip these, but you won’t get a fix.
• Cross-cutting changes — Issues that require coordinated changes across multiple subsystems exceed the single-agent model. Each agent works in isolation on one issue.
• Unfamiliar frameworks — If the codebase uses a niche framework that wasn’t well-represented in training data, the agent’s fixes may be structurally off.
• Integration tests that require external services — The agent can run unit tests, but it can’t spin up a database, message queue, or third-party API for integration testing.

The skill works best as a first pass, not a replacement for human review. It drafts PRs; you decide which ones to merge.

Architecture Lessons: Why This Skill Is Well-Built

If you’re building your own skills — especially orchestrator-type skills — gh-issues demonstrates several patterns worth studying:

1. Claim-based deduplication

A JSON file (gh-issues-claims.json) tracks which issues are being processed, with timestamps and a 2-hour expiry. This prevents double-processing across cron runs, watch cycles, and manual invocations running concurrently. Simple, file-based, no external dependencies.

2. Confidence gating

Each sub-agent evaluates whether it should attempt a fix before attempting one. This is the skill equivalent of a gotchas section — it encodes the failure mode “agent attempts fix on unclear issue, produces bad PR” and prevents it structurally.

3. Progressive phases with clear exit points

The 6-phase structure means the skill can exit cleanly at any point: no issues found (Phase 2), user cancels (Phase 3), all issues already have PRs (Phase 4), cron mode spawns and exits (Phase 5). There’s no “half-finished” state.

4. Structured sub-agent prompts

The sub-agent task prompt is a template with clear sections: config, issue context, numbered instructions, and constraints. It gives the agent enough structure to be reliable while leaving room for judgment in the implementation step.

Installation

The skill ships with OpenClaw and is available on ClawHub:

clawhub install gh-issues

Requirements:

• curl and git (available on essentially any development machine)
• A GH_TOKEN with repo access (set via OpenClaw’s skill configuration or environment variable)

No gh CLI needed. The skill uses the GitHub REST API directly, which means it works in CI environments, containers, and minimal server setups where installing the GitHub CLI isn’t practical.

Frequently Asked Questions

Can gh-issues work with private repositories?

Yes. As long as your GH_TOKEN has access to the repository (via a personal access token with repo scope or a fine-grained token with appropriate permissions), the skill works identically for public and private repos.

How many issues can it process at once?

In normal mode, up to 8 sub-agents run concurrently (matching OpenClaw’s default subagents.maxConcurrent setting). In cron mode, it processes one issue per invocation to avoid resource spikes. The --limit flag controls how many issues are fetched per cycle.

What happens if a sub-agent’s fix breaks existing tests?

The sub-agent runs the project’s test suite after implementing its fix. If tests fail, it attempts one retry with a corrected approach. If tests still fail after the retry, the agent reports the failure and does not open a PR. The issue is marked as failed in the results summary.

Does it work with monorepos?

It works, but results vary. The agent searches the entire repo for relevant code, so in a large monorepo, it may find the wrong files or miss the relevant package. For monorepos, adding clear labels or package names in issue titles helps the agent locate the right code.

Where It Fits in the Bigger Picture

gh-issues belongs to Category 7 (CI/CD & Deployment) in the agent skills taxonomy. It pairs well with code quality skills that catch issues before they become bugs, and with the other top skills in the ecosystem.

The broader pattern here — an orchestrator skill that coordinates multiple sub-agents for parallel work — is applicable far beyond bug fixing. The same architecture works for documentation generation, migration scripts, test coverage expansion, and any workflow where “do this independently for each item in a list” is the core loop.

If you’re building agent skills and want to study a well-structured orchestrator, gh-issues on ASE is worth reading end to end. And if you’re maintaining a project with a growing issue backlog — give it a run. The worst case is a few PRs you close; the best case is a few hours of your week back.