gh-issues
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]
What this skill does
# 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. 2. **Record base branch:** ``` git rev-parse --abbrev-ref HEAD ``` Store as BASE_BRANCH. 3. **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 ``` If this fails, stop with: "Cannot reach remote origin. Check your network and git config." 4. **Verify GH_TOKEN validity:** ``` curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $GH_TOKEN" https://api.github.com/user ``` If HTTP status is not 200, stop with: > "GitHub authentication failed. Please check your apiKey in the OpenClaw dashboard or in ~/.openclaw/openclaw.json under skills.entries.gh-issues." 5. **Check for existing PRs:** For each confirmed issue number N, run: ``` curl -s -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" \ "https://api.github.com/repos/{SOURCE_REPO}/pulls?head={PUSH_REPO_OWNER}:fix/issue-{N}&state=open&per_page=1" ``` (Where PUSH_REPO_OWNER is the owner portion of `PUSH_REPO`) If the response array is non-empty, remove that issue from the proce
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.