Skip to content
Skill

gh-issues

by openclaw

AI Summary

An AI-powered GitHub issue orchestrator that automatically fetches issues, spawns sub-agents to implement fixes, opens PRs, and monitors review feedback. Ideal for developers wanting to automate bug triage and fix deployment workflows.

Install

Copy this and paste it into Claude Code, Cursor, or any AI assistant:

I want to install the "gh-issues" skill in my project.

Please run this command in my terminal:
# Install skill into the correct directory
mkdir -p .claude/skills/gh-issues && curl --retry 3 --retry-delay 2 --retry-all-errors -o .claude/skills/gh-issues/SKILL.md "https://raw.githubusercontent.com/openclaw/openclaw/main/skills/gh-issues/SKILL.md"

Then restart Claude Code (or reload the window in Cursor) so the skill is picked up.

Description

Fetch GitHub issues, spawn sub-agents to implement fixes and open PRs, then monitor and address PR review comments. Usage: /gh-issues [owner/repo] [--label bug] [--limit 5] [--milestone v1.0] [--assignee @me] [--fork user/repo] [--watch] [--interval 5] [--reviews-only] [--cron] [--dry-run] [--model glm-5] [--notify-channel -1002381931352]

gh-issues — Auto-fix GitHub Issues with Parallel Sub-agents

You are an orchestrator. Follow these 6 phases exactly. Do not skip phases. IMPORTANT — No gh CLI dependency. This skill uses curl + the GitHub REST API exclusively. The GH_TOKEN env var is already injected by OpenClaw. Pass it as a Bearer token in all API calls: ` curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" ... ` ---

Phase 1 — Parse Arguments

Parse the arguments string provided after /gh-issues. Positional: • owner/repo — optional. This is the source repo to fetch issues from. If omitted, detect from the current git remote: git remote get-url origin Extract owner/repo from the URL (handles both HTTPS and SSH formats). • HTTPS: https://github.com/owner/repo.git → owner/repo • SSH: git@github.com:owner/repo.git → owner/repo If not in a git repo or no remote found, stop with an error asking the user to specify owner/repo. Flags (all optional): | Flag | Default | Description | |------|---------|-------------| | --label | _(none)_ | Filter by label (e.g. bug, enhancement) | | --limit | 10 | Max issues to fetch per poll | | --milestone | _(none)_ | Filter by milestone title | | --assignee | _(none)_ | Filter by assignee (@me for self) | | --state | open | Issue state: open, closed, all | | --fork | _(none)_ | Your fork (user/repo) to push branches and open PRs from. Issues are fetched from the source repo; code is pushed to the fork; PRs are opened from the fork to the source repo. | | --watch | false | Keep polling for new issues and PR reviews after each batch | | --interval | 5 | Minutes between polls (only with --watch) | | --dry-run | false | Fetch and display only — no sub-agents | | --yes | false | Skip confirmation and auto-process all filtered issues | | --reviews-only | false | Skip issue processing (Phases 2-5). Only run Phase 6 — check open PRs for review comments and address them. | | --cron | false | Cron-safe mode: fetch issues and spawn sub-agents, exit without waiting for results. | | --model | _(none)_ | Model to use for sub-agents (e.g. glm-5, zai/glm-5). If not specified, uses the agent's default model. | | --notify-channel | _(none)_ | Telegram channel ID to send final PR summary to (e.g. -1002381931352). Only the final result with PR links is sent, not status updates. | Store parsed values for use in subsequent phases. Derived values: • SOURCE_REPO = the positional owner/repo (where issues live) • PUSH_REPO = --fork value if provided, otherwise same as SOURCE_REPO • FORK_MODE = true if --fork was provided, false otherwise If --reviews-only is set: Skip directly to Phase 6. Run token resolution (from Phase 2) first, then jump to Phase 6. If --cron is set: • Force --yes (skip confirmation) • If --reviews-only is also set, run token resolution then jump to Phase 6 (cron review mode) • Otherwise, proceed normally through Phases 2-5 with cron-mode behavior active ---

Phase 2 — Fetch Issues

Token Resolution: First, ensure GH_TOKEN is available. Check environment: ` echo $GH_TOKEN ` If empty, read from config: ` cat ~/.openclaw/openclaw.json | jq -r '.skills.entries["gh-issues"].apiKey // empty' ` If still empty, check /data/.clawdbot/openclaw.json: ` cat /data/.clawdbot/openclaw.json | jq -r '.skills.entries["gh-issues"].apiKey // empty' ` Export as GH_TOKEN for subsequent commands: ` export GH_TOKEN="<token>" ` Build and run a curl request to the GitHub Issues API via exec: ` curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \ "https://api.github.com/repos/{SOURCE_REPO}/issues?per_page={limit}&state={state}&{query_params}" ` Where {query_params} is built from: • labels={label} if --label was provided • milestone={milestone} if --milestone was provided (note: API expects milestone _number_, so if user provides a title, first resolve it via GET /repos/{SOURCE_REPO}/milestones and match by title) • assignee={assignee} if --assignee was provided (if @me, first resolve your username via GET /user) IMPORTANT: The GitHub Issues API also returns pull requests. Filter them out — exclude any item where pull_request key exists in the response object. If in watch mode: Also filter out any issue numbers already in the PROCESSED_ISSUES set from previous batches. Error handling: • If curl returns an HTTP 401 or 403 → stop and tell the user: > "GitHub authentication failed. Please check your apiKey in the OpenClaw dashboard or in ~/.openclaw/openclaw.json under skills.entries.gh-issues." • If the response is an empty array (after filtering) → report "No issues found matching filters" and stop (or loop back if in watch mode). • If curl fails or returns any other error → report the error verbatim and stop. Parse the JSON response. For each issue, extract: number, title, body, labels (array of label names), assignees, html_url. ---

Phase 3 — Present & Confirm

Display a markdown table of fetched issues: | # | Title | Labels | | --- | ----------------------------- | ------------- | | 42 | Fix null pointer in parser | bug, critical | | 37 | Add retry logic for API calls | enhancement | If FORK_MODE is active, also display: > "Fork mode: branches will be pushed to {PUSH_REPO}, PRs will target {SOURCE_REPO}" If --dry-run is active: • Display the table and stop. Do not proceed to Phase 4. If --yes is active: • Display the table for visibility • Auto-process ALL listed issues without asking for confirmation • Proceed directly to Phase 4 Otherwise: Ask the user to confirm which issues to process: • "all" — process every listed issue • Comma-separated numbers (e.g. 42, 37) — process only those • "cancel" — abort entirely Wait for user response before proceeding. Watch mode note: On the first poll, always confirm with the user (unless --yes is set). On subsequent polls, auto-process all new issues without re-confirming (the user already opted in). Still display the table so they can see what's being processed. ---

Discussion

0/2000
Loading comments...

Health Signals

MaintenanceCommitted 1mo ago
Active
Adoption1K+ stars on GitHub
272.9k ★ · Popular
DocsREADME + description
Well-documented

GitHub Signals

Stars272.9k
Forks52.1k
Issues10523
Updated1mo ago
View on GitHub
MIT License

My Fox Den

Community Rating

Sign in to rate this booster

Works With

Cursor