fix-issues

Batch Issue Fixing Pipeline

Arguments: $ARGUMENTS — optional space-separated issue numbers to limit the batch. Empty means all open issues.

This skill encodes the full process: triage -> parallel fixes in isolated worktrees -> merge into develop -> release -> final review -> publish. Follow the phases in order. All gh commands run from the repo root (no --repo flag needed).

Phase 0 — Preflight

1. git fetch origin and confirm the working tree is clean (git status --short). If dirty, stop and ask the user.
2. Compare branches: git rev-list --left-right --count origin/main...origin/develop.
   • If develop is strictly behind main (0 unique commits), fast-forward it: git push origin origin/main:develop.
   • If develop has unique commits, ask the user how to proceed before branching anything.
3. All fix branches are created from origin/develop.

Phase 1 — Triage

1. List issues: gh issue list --state open --limit 100 --json number,title,labels.
2. Read EVERY issue in scope with comments: gh issue view <n> --comments. Comments often contain the real root cause or a maintainer-agreed approach.
3. Build a summary table (number, type bug/feature, one-line problem). Explicitly check for duplicates and overlapping fixes.
4. Ask the user (AskUserQuestion) before starting work:
   • Scope: which issues go into this batch (call out breaking changes and pure feature requests separately).
   • Whether to auto-merge fix PRs into develop or leave them open for manual review.
   • Anything that looks external/not-a-bug (e.g. Docker Hub rate limits): propose fix / message-only / skip-and-close options.
5. Decide the version bump now (semver table in CLAUDE.md) so the release phase is mechanical. The user may override.

Phase 2 — Parallel fixes (one worktree + one agent per issue)

1. Create worktrees as siblings of the repo:

   git worktree add ../<repo-name>-worktrees/issue-<n> -b fix/issue-<n>-<slug> origin/develop
   

   Use fix/ for bugs, feat/ for features (feat! commit prefix for breaking changes).
2. Launch one background agent per issue, all in parallel. Each agent prompt MUST include:
   • Work EXCLUSIVELY in its worktree path; never touch the main checkout.
   • Work fully autonomously; never wait for user input.
   • Step 1: read the issue with gh issue view <n> --comments and the worktree's CLAUDE.md.
   • Step 2: invoke the Skill tool with feature-dev:feature-dev to implement. Skip interactive steps; prefer the minimal robust fix.
   • Step 3: commit with a conventional-commit message.
   • Step 4: invoke the Skill tool with pr-review-toolkit:review-pr on the diff origin/develop...HEAD. Fix ALL critical and important findings; ignore nitpicks. Commit fixes.
   • Step 5: git push -u origin <branch> and open a PR to develop with gh pr create --base develop. Body in plain English: summary, what changed, verification, and the line Fixes #<n>.
   • Constraints: do NOT modify CHANGELOG.md or VERSION (prevents 7-way merge conflicts; release handles both). Verification: bash -n on every changed script, cp .env.example .env (gitignored, delete after) + docker compose -p localai config --quiet, node --check welcome/app.js if touched. Docker CLI may not be on PATH — try /usr/local/bin/docker.
   • Known facts from the codebase report (file, line numbers, verified behavior) — give each agent everything already learned during triage.
   • Push the agent to verify root causes upstream (WebFetch the upstream repo/Dockerfile/entrypoint) rather than trusting the issue's proposed fix. Issues regularly misdiagnose (wrong mount path vs stale volume; missing tool vs wrong endpoint).