/autofix-issues

name: autofix-issues
description: Survey recently triaged GitHub issues, propose the ones safe to fix without a product decision, and fan the selected ones out to independent sessions.

/autofix-issues Command

Survey the issues triaged over a recent window and split them two ways: the ones that can be fixed without a decision from the user, offered as a checklist to fan out to independent sessions, and the ones that need the user's attention, with the reason for each.

Both lists are the deliverable. The second is not a leftover pile — it is where the user finds the decisions waiting on them.

/autofix-issues [timeframe]

Timeframe defaults to the last two weeks. Examples: `/autofix-issues`, `/autofix-issues 1w`, `/autofix-issues 30d`.

The user picks from a checklist. Never launch anything before they have chosen.

Step 1: Gather candidates

Start by reading the last two or three entries in `nimbalyst-local/autofix-log.md`. Past runs record which screening calls turned out wrong; a mistake logged there twice should be applied as a criterion here rather than repeated.

Triage has already done the investigation — do not redo it. Pull from both sides and join them:

• **Tracker overlays**: `tracker_list({ type: "github-issue", full: true })`. The `notes` field carries the confirmed root cause with file:line anchors. This is the highest-value input; an issue with a confirmed root cause in `notes` is a candidate, one without is usually not.
• **GitHub**: `gh issue list --state open --json number,title,labels,updatedAt,comments` filtered to the timeframe. An issue that carries an `area:*` label and no longer carries `status:needs-triage` has been through triage.

Read the triage comment on each candidate. It states what was confirmed and what was left open — both matter for screening.

Step 2: Screen for "safe to fix unattended"

Two independent bars. **A candidate must clear both.**

Bar 1: no decision belongs to the user

Include when the correct behavior is already settled — a stated contract, an in-repo precedent, or an obviously-wrong result nobody would defend.

Exclude when shipping the fix would decide something on the user's behalf:

• A business or partnership question (vendor integrations, licensing, pricing)
• New UI surface, placement, naming, or an added setting or option. A gutter icon, nav entry, or content mode is never auto-fixable
• Default behavior changes that alter what existing users see
• Anything with two defensible designs and no precedent to break the tie
• Overlay status `needs-design`, `waiting-on-reporter`, or `declined`

When an issue is **partly** decidable, split it. #1422 was a genuine bug (custom types rendered a blank Type column, no defensible reading) bundled with a request for a new display option (a real product choice). The bug half is auto-fixable; the option half is not. Propose the half that clears the bar and say plainly what you left out.

Bar 2: cheap and honest to validate with a unit test

Include when a vitest test can express the bug and flip red to green: pure logic, a parser, a comparison, a formatter, an event-handler condition, a reducer.

Exclude when the test would be theatre or absent:

• Verification needs a restart, a real window, or a manual UI pass. See [end-to-end-verification.md](../rules/end-to-end-verification.md)
• E2E-only. Those runs take over the user's desktop and are never fanned out
• The honest test would be presentation-only — icon names, exact strings, element counts. See the testing rules in [CLAUDE.md](../../CLAUDE.md)

Hard exclusions, regardless of how small the diff looks

Do not fan these out even with a confirmed root cause. They need a human watching:

• **Anything that re-keys or migrates persisted state.** #1419 looked like a two-line path-normalization fix and was actually a change to the key under which permissions are stored — a naive fix would have silently unbound every symlinked workspace. See [destructive-data-paths.md](../rules/destructive-data-paths.md)
• Sync, collab, encryption, auth, or the personal/team JWT split
• Main-process initialization order
• Database schema or migrations
• Anything touching a file over ~2000 lines, where a slice is likely to grow it

Step 3: Map files, then resolve conflicts

For each surviving candidate, list the files it will touch — source *and* tests. Then check the sets against each other.

**Overlapping candidates are one session, not two.** Merge them into a single slice with both issue numbers, or drop the weaker one. Never launch two sessions that touch the same file.

Check the shared files a source-only comparison misses: `CHANGELOG.md`, `package.json`, barrels and `index.ts`, central registries such as `KeyboardShortcutsDialog.tsx`, shared type modules. If a candidate needs one, it owns that file for the batch. See [parallel-sessions.md](../rules/parallel-sessions.md).

`CHANGELOG.md` is always orchestrator-owned. No slice ever touches it.

Step 4: Present the checklist

Use `mcp__nimbalyst__PromptForUserInput` with a `multiSelect` field. One item per candidate:

• **title**: `#1424 — comma in a tracker title splits a relationship pill into two`
• **subtitle**: the fix in one clause, plus the files it will touch
• **defaultChecked**: true only for candidates with a confirmed root cause and an obvious test

Do not pad the list to look productive. Four solid candidates beat nine speculative ones — every weak slice costs a review cycle.

The second list: needs your attention

Every screened-out issue goes into a second list, presented alongside the checklist. This is not an appendix — an issue correctly refused, with the reason, is worth as much as one fixed, and it is the only place the user learns a decision is waiting on them.

Group by **why it was excluded**, most actionable first:

1. **Waiting on a decision from you** — the highest-value group. State the decision itself, not just the issue title, so it can be