
Gh Issues
Automate GitHub issue triage: fetch filtered issues, spawn background fix workers, open PRs, optionally watch reviews, and process review comments with gh and git.
Overview
gh-issues is an agent skill most often used in Operate (also Ship review, Build backend) that fetches GitHub issues, runs background fix agents, opens PRs, and optionally handles PR review comments via gh.
Install
npx skills add https://github.com/steipete/clawdis --skill gh-issuesWhat is this skill?
- End-to-end issue-to-PR automation preferring gh CLI with gh api fallback
- Filters: label, milestone, assignee, state, limit (default 10), optional fork target
- Watch mode with configurable interval (default 5 minutes) for issues and PR reviews
- Flags: --dry-run list-only, --reviews-only, --cron spawn-and-exit, --model for workers
- Requires git + gh bins and GH_TOKEN (primaryEnv)
- Default issue limit 10
- Default watch interval 5 minutes
- Documented phases: resolve repo, fetch issues, spawn workers, PR and optional reviews
Adoption & trust: 1.9k installs on skills.sh; 378k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
Open issues and stale review threads pile up while you lack time to branch, fix, and open PRs for each candidate.
Who is it for?
Solo maintainers with GH_TOKEN, gh, and git who want scripted issue triage and fix agents on repos they control.
Skip if: Non-GitHub forges, repos without CLI auth, or production changes you are not willing to auto-branch without dry-run review.
When should I use this skill?
User wants GitHub issue fetching, automated fix agents, PR creation, watch/cron issue loops, or PR review comment processing with gh.
What do I get? / Deliverables
Filtered issues become worker-driven branches and PRs, with optional polling for new issues or review feedback until you merge or intervene.
- Candidate issue list or dry-run report
- Branches and pull requests for selected issues
- Review comment processing outcomes when enabled
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Issue-to-PR loops are canonically shelved under Operate iterate because they maintain and improve shipped codebases, though the same flow appears during active Ship review cycles. Iterate captures ongoing fixes, PR churn, and review handling rather than one-off greenfield implementation.
Where it fits
Cron-watch open bugs labeled good-first-issue and open PRs while you focus on support.
Run --reviews-only to address reviewer comments on open PRs after a release candidate.
Dry-run a milestone filter to see which backend issues are fixable before cutting a patch release.
How it compares
Opinionated issue-to-PR orchestration atop gh—not a substitute for human code review or your CI policy gates.
Common Questions / FAQ
Who is gh-issues for?
Indie developers and small teams maintaining GitHub repos who want agents to list issues, attempt fixes in the background, and open PRs with standard gh/git tooling.
When should I use gh-issues?
In Operate iterate for backlog burning; in Ship review when processing PR comments (--reviews-only); during Build when closing bug issues before release—always with gh authenticated.
Is gh-issues safe to install?
Use the Security Audits panel on this Prism page; unattended --yes/--cron runs can push branches and open PRs—dry-run first and scope GH_TOKEN minimally.
SKILL.md
READMESKILL.md - Gh Issues
# gh-issues Use for issue-to-PR automation. Prefer `gh` CLI; fall back to `gh api` only when a high-level command lacks the needed field. ## Arguments - positional `owner/repo`: optional; else infer from `git remote get-url origin`. - `--label <label>`: filter. - `--limit <n>`: default 10. - `--milestone <title>`: filter. - `--assignee <login|@me>`: filter. - `--state open|closed|all`: default open. - `--fork <owner/repo>`: push branches to fork, PR to source. - `--watch`: poll issues + reviews. - `--interval <minutes>`: default 5. - `--dry-run`: list only. - `--yes`: no confirmation. - `--reviews-only`: skip issue fixing; handle PR reviews. - `--cron`: spawn and exit; implies `--yes`. - `--model <id>`: pass to workers when supported. - `--notify-channel <id>`: optional final notification target. ## Phase 1: resolve repo ```bash git remote get-url origin if [ -z "${GH_TOKEN:-}" ]; then CONFIG_PATH="${OPENCLAW_CONFIG_PATH:-${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/openclaw.json}" GH_TOKEN=$(jq -r '.skills.entries["gh-issues"].apiKey // empty' "$CONFIG_PATH" 2>/dev/null || true) if [ -n "$GH_TOKEN" ]; then export GH_TOKEN; fi fi gh auth status gh repo view OWNER/REPO --json nameWithOwner,defaultBranchRef ``` If `gh auth status` fails and `GH_TOKEN` is missing, stop and ask for GitHub auth/config. Derived: - `SOURCE_REPO`: issue repo. - `PUSH_REPO`: fork if set, else source. - `BASE_BRANCH`: source default branch unless user says otherwise. - `PUSH_REMOTE`: `fork` in fork mode, else `origin`. Stop on dirty worktree unless user confirms that workers should ignore uncommitted changes. In fork mode, do not mutate remotes before confirmation or during `--dry-run`. Verify auth/read access only: ```bash gh auth token >/dev/null || test -n "${GH_TOKEN:-}" gh repo view "$PUSH_REPO" --json nameWithOwner git ls-remote --exit-code origin HEAD ``` ## Phase 2: fetch issues Build filters and fetch: ```bash gh issue list --repo "$SOURCE_REPO" --state open --limit 10 --json number,title,labels,url,body,assignees,milestone ``` Add `--label`, `--milestone`, `--assignee`, `--state`, `--limit` as requested. `gh issue list` already excludes PRs. If none found: report no matches. If `--dry-run`: show compact list and stop. ## Phase 3: avoid duplicate work For each candidate: ```bash gh pr list --repo "$SOURCE_REPO" --search "$SOURCE_REPO#<n>" --state open --json number,url,title,headRefName gh pr list --repo "$SOURCE_REPO" --head "fix/issue-<n>" --state open --json number,url gh api "repos/$PUSH_REPO/branches/fix/issue-<n>" >/dev/null ``` Skip candidates with an open PR, existing branch, or active local claim. Claim file: ```text ${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/gh-issues-<owner>-<repo>.json ``` Expire claims older than 2 hours. Create the parent directory before writing. ## Phase 4: confirm Unless `--yes` or `--cron`, ask user to choose: - `all` - comma-separated issue numbers - `cancel` After confirmation, in fork mode, configure the push remote before handing work to agents: ```bash gh auth setup-git git remote get-url fork || git remote add fork "https://github.com/$PUSH_REPO.git" git remote set-url fork "https://github.com/$PUSH_REPO.git" git ls-remote --exit-code fork HEAD ``` ## Phase 5: spawn workers Launch up to 8 background workers. Do not block on each worker when `--cron`. Before each spawn, write a claim for `SOURCE_REPO#<n>` with the current ISO tim