# Fix Repo

> Triage every open GitHub issue in one repo, auto-fix and open a reviewed PR for whatever is safe to fix without human judgment, and set aside anything that genuinely needs a human decision. Trigger: /fix-repo <reponame>

- **Type:** Skill
- **Install:** `agentstack add skill-gssajith-claude-skills-fix-repo`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [gssajith](https://agentstack.voostack.com/s/gssajith)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [gssajith](https://github.com/gssajith)
- **Source:** https://github.com/gssajith/claude-skills/tree/master/skills/fix-repo

## Install

```sh
agentstack add skill-gssajith-claude-skills-fix-repo
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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:

```bash
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`:

```bash
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

```bash
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.

```bash
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

```bash
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**:

```bash
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**:

```bash
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.

2. **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.

3. **Open the PR:**

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

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

   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 ""
   ```

4. **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:

```bash
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](https://github.com/gssajith)
- **Source:** [gssajith/claude-skills](https://github.com/gssajith/claude-skills)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-gssajith-claude-skills-fix-repo
- Seller: https://agentstack.voostack.com/s/gssajith
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.