Fix Repo

fix-repo

Works through every open issue in one repo in a single run: triages each one, fixes and opens a PR for everything judged safe (implemented with TDD, independently reviewed by a separate adversarial subagent before the PR opens), and sets aside anything that needs a human decision instead of guessing. Nothing merges automatically — every PR this skill opens waits for a human to click merge on GitHub, even after an automated approval.

**Scope guard: ` org only.** If the target repo's GitHub owner isn't `, stop before doing anything else — do not sync, do not list issues, do not touch the repo.

Announce at start: "Using fix-repo to triage and fix issues in ``."

Step 1: Resolve the target repo and enforce the scope guard

` is a local directory name (not a URL) — the argument to /fix-repo`.

Find it as a workspace subdirectory with a .git present:

repo_dir=""
if [ ! -d "$repo_dir/.git" ]; then
  echo "No local checkout named '$repo_dir' found here."
fi

• Not found → stop and ask the user for the correct directory name. Do not guess, and

do not speculatively gh repo clone — unlike fix-issue, there's no issue URL here to derive a clone target from, so a wrong guess could clone the wrong thing.

• Found → continue.

Read the remote and extract owner/repo:

remote=$(git -C "$repo_dir" remote get-url origin 2>/dev/null)
slug=$(echo "$remote" | sed -E 's#\.git$##; s#.*[:/]([^/]+/[^/]+)$#\1#')
owner="${slug%%/*}"

Scope guard: if $owner is not exactly `, stop immediately and tell the user this skill only operates on ` org repos — take no further action (no sync, no issue list, nothing). This check must run before Step 2.

Step 2: Sync

git -C "$repo_dir" status --short

If this prints anything at all, stop and ask the user how to proceed — never stash or discard automatically. Only continue once the tree is confirmed clean.

default_branch=$(git -C "$repo_dir" remote show origin | grep "HEAD branch" | awk '{print $NF}')
git -C "$repo_dir" checkout "$default_branch"
git -C "$repo_dir" pull

Step 3: Triage every open issue

gh issue list --repo "$slug" --state open --json number,title,body,labels,url

If this errors (no access, rate limit), stop and report the error — do not guess at the issue list.

For each open issue, dispatch one subagent (Agent tool, in parallel across issues — same pattern as file-issue's per-repo audit dispatch) with this exact brief:

> "Given this GitHub issue (title, body, comments, labels), read the implicated code on > the current default branch of $repo_dir — code-read only, never start services or run > the app — and answer three things: > > 1. Still reproduces? Reason explicitly about whether the described behavior is still > present given what the code does today. > 2. Auto-fixable, or human-required? Answer human-required if any of these is true: > - The issue is ambiguous or underspecified — you cannot determine a concrete correct > fix without guessing at intent. > - The fix would touch DB schema, migrations, or data deletion/backfill. > - The fix would touch auth, RBAC, tenant isolation, or secrets handling. > - The fix would break a public API, a cross-repo contract (e.g. > -app-contracts), or require a coordinated multi-repo change. > When in doubt, answer human-required — this bar exists to keep blast radius small, > not to maximize how much gets auto-fixed. If human-required, name exactly which > criterion above it tripped. > 3. Implicated files — the concrete file paths a fix would touch. Best-effort; doesn't > need to be exhaustive. > > Report your answer as: reproduces (yes/no), classification (auto-fixable/human-required), > criterion (if human-required), implicated_files (list of paths)."

Collect every subagent's verdict before moving on to Step 4. Keep the full per-issue result set (issue number, verdict, implicated files) in context — Step 5 (clustering) and Step 6 (per-issue fix) both consume it directly.

Step 4: Close already-fixed issues, label human-required ones

For every issue where the Step 3 triage found it no longer reproduces:

gh issue close  --repo "$slug" --comment ""

No PR, no branch, no code change. Record it for the final report.

For every issue triaged human-required:

gh label list --repo "$slug" --limit 200 | cut -f1 | grep -qxF "needs-human" || \
  gh label create "needs-human" --repo "$slug" --color "d876e3" --description "Set aside by fix-repo — needs a human decision, not auto-fixed"
gh issue edit  --repo "$slug" --add-label "needs-human"
gh issue comment  --repo "$slug" --body "fix-repo set this aside: ."

Take no further action on this issue this run. Record it (issue number + criterion) for the final report. If the label-create or issue-edit calls fail (permissions), don't block the rest of the run — report which issues didn't get labeled.

Every remaining issue (reproduces, and classified auto-fixable) carries forward into Step 5.

Step 5: Cluster the auto-fixable issues by file overlap

This is plain computation over the Step 3 triage output — not a subagent call.

Build clusters from the auto-fixable issues' implicated_files lists: two issues belong to the same cluster if they share at least one implicated file, applied transitively (if issue A shares a file with B, and B shares a file with C, then A, B, and C are all one cluster even if A and C share no file directly). A simple way to compute this: treat each issue as a node, add an edge between any two issues that share a file, and take connected components as clusters.

• A cluster with exactly one issue, or clusters that share no files with each other, are

independent — safe to process concurrently in Step 6.

• A cluster with more than one issue must be processed sequentially, in a stable order

(e.g. ascending issue number) — Step 7 handles what happens after the first one.

Step 6: Fix, review, and open a PR — one issue at a time per cluster

Process clusters from Step 5: independent clusters concurrently, issues within one cluster one at a time in the stable order chosen in Step 5. For each auto-fixable issue:

1. Implement with TDD, writing an inline spec first (same sections as fix-issue's

spec — Problem, Root cause, Proposed fix, Affected files, Risks/edge cases, Test plan — saved to $repo_dir/docs/issue-fixes/--spec.md, same convention fix-issue uses). Then:

• Write a failing test reproducing the issue; run it, confirm it fails for the expected

reason.

• Implement the fix described in the spec.
• Run the full test suite for the affected package/module.

Branch is cut from the current default-branch tip (git checkout "$default_branch" && git pull right before branching) so it includes any earlier PR from this same run that has already merged.

1. Independent adversarial review. Dispatch a fresh subagent (Agent tool) that is

not the implementer and has not seen the implementer's reasoning — only the issue text, the spec file, the diff (git diff "$default_branch"), and the test run output. Brief:

> "You are reviewing this fix adversarially — your job is to find reasons to reject it, > not to rubber-stamp it. Given the issue, the spec, the diff, and the test output, > decide APPROVE or REQUEST-CHANGES. If REQUEST-CHANGES, give concrete, specific > reasons tied to exact lines or exact spec sections — not general concerns."

• REQUEST-CHANGES → the implementer retries, addressing the specific feedback.

Cap: 2 retry attempts (3 tries total). Still not approved, or the suite is still red, after that → treat this issue exactly like Step 4's human-required path: apply the needs-human label, comment with the reviewer's final reasoning, no PR opens. Record it for the final report and move to the next issue.

• APPROVE → continue to step 3.

1. Open the PR:

```bash branch="fix/issue--" git -C "$repodir" checkout -b "$branch" git -C "$repodir" add "docs/issue-fixes/--spec.md" git -C "$repo_dir" commit -m "fix:

Fixes #" git -C "$repodir" push -u origin "$branch" gh pr create --repo "$slug" --title "" --body "Fixes #. See docs/issue-fixes/--spec.md for the fix spec." --base "$defaultbranch" ```

Then post the reviewer's approval as a real GitHub review, not just a comment, so it's visible on the PR itself:

``bash gh pr review --repo "$slug" --approve --body "" ``

1. Do not merge. Leave the PR open and approved. Move immediately to the next issue —

do not wait here for a human to merge it.

Step 7: Handle cluster conflicts

Within a cluster with more than one issue, only the first issue (in the Step 5 stable order) gets a PR opened this run. For every remaining issue in that same cluster:

gh issue comment  --repo "$slug" --body "Queued behind PR # in this same repo (same-file conflict). Re-run \`/fix-repo \` after merging it to continue with this issue."

Do not poll or wait for the merge inside this run — that could block indefinitely on someone else's schedule. A future /fix-repo invocation re-triages from scratch and will pick these up once the blocking PR has actually merged (they'll no longer show as conflicting with anything already on the default branch).

Step 8: Report

Summarize the run in four groups:

• PRs opened and approved, ready for your merge click — list URL + title, in

cluster/dependency order.

• Issues closed as already-fixed — issue number + one-line reason.
• Issues labeled needs-human — issue number + which criterion it tripped (or, for

ones dropped after failed review, the reviewer's final reasoning).

• Clusters partially blocked — the first PR's link, and the remaining queued issue

numbers in that cluster.

Error handling

| Situation | Behavior | |---|---| | ` not found locally | Stop, ask — no speculative clone | | Repo owner isn't | Stop immediately, before any other step | | Uncommitted changes before sync | Stop, ask — never auto-stash/discard | | Issue no longer reproduces | Close with explanation, no PR, report | | Issue fails the human-required bar | Label needs-human, comment why, no fix attempt | | Reviewer requests changes twice (3 tries total) | Drop to needs-human with reviewer's reasoning, no PR | | Test suite red after implementation/retries | Same as above — never open a PR on a red suite | | Cluster has 2+ conflicting issues | Open first PR only; queue the rest with a pointer comment | | gh` collaborator/label calls fail (permissions) | Don't block the run; report what wasn't applied |

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: gssajith
• Source: gssajith/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.