--- name: gh-issues 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]" user-invocable: true metadata: { "openclaw": { "requires": { "bins": ["curl", "git", "gh"] }, "primaryEnv": "GH_TOKEN", "install": [ { "id": "brew", "kind": "brew", "formula": "gh", "bins": ["gh"], "label": "Install GitHub CLI (brew)", }, ], }, } ---

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: [email protected]: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.

---

Phase 4 — Pre-flight Checks

Run these checks sequentially via exec:

1. Dirty working tree check:

``` git status --porcelain ```

If output is non-empty, warn the user:

> "Working tree has uncommitted changes. Sub-agents will create branches from HEAD — uncommitted changes will NOT be included. Continue?" > Wait for confirmation. If declined, stop.

1. Record base branch:

``` git rev-parse --abbrev-ref HEAD ```

Store as BASE_BRANCH.

1. Verify remote access:

If FORK_MODE: - Verify the fork remote exists. Check if a git remote named fork exists: ``` git remote get-url fork ``` If it doesn't exist, add it: ``` git remote add fork https://x-access-token:[email protected]/{PUSH_REPO}.git ``` - Also verify origin (the source repo) is reachable: ``` git ls-remote --exit-code origin HEAD ```

If not FORK_MODE:

``` git ls-remote --exit-code origin HEAD ```

...