One-command start

Give FixMap a public GitHub issue. It fetches the task, infers the repository, scans an isolated temporary checkout, and removes that checkout when the report is complete:

npx -y @aryam/fixmap@latest plan --issue https://github.com/aryamthecodebreaker/FixMap/issues/59

No clone, signup, configuration, or source upload is required.

If an older FixMap is installed globally, some npm/npx combinations on Windows can resolve the old global fixmap shim even when a package version is pinned. Remove it with npm uninstall -g @aryam/fixmap, or use the unambiguous form:

npm exec --yes --package=@aryam/[email protected] -- fixmap --version

The CLI points at the next useful command as you go, so --explain and verify surface when they apply rather than only living here.

The problem FixMap solves

Coding agents are fast after they find the right context. The expensive mistakes happen before the first edit:

• opening a plausible file instead of the definition that owns the behavior
• missing the nearest test or workspace-specific test command
• treating an unresolved diff as “no changes”
• reviewing a change without an explicit map of affected code and risks

FixMap adds a deterministic routing step before an agent starts searching. Its output is evidence, not a correctness claim:

Use FixMap your way

CLI

Analyze a task against any public GitHub repository:

npx -y @aryam/fixmap@latest plan \
  --issue "support public GitHub issue URLs" \
  --repo https://github.com/aryamthecodebreaker/FixMap

Analyze private source or working-tree changes locally:

npx -y @aryam/fixmap@latest plan --issue "password reset emails fail"
npx -y @aryam/fixmap@latest plan --diff main...HEAD

Write machine-readable output:

npx -y @aryam/fixmap@latest plan \
  --base main \
  --head HEAD \
  --format json \
  --output fixmap-report.json

Remote repository mode is issue-only. Clone the repository locally when you need --diff, --base, or --head.

For long or private task text, avoid shell command-length limits by reading UTF-8 text from a file or stdin:

npx -y @aryam/fixmap@latest plan --issue-file task.md
Get-Content task.md -Raw | npx -y @aryam/fixmap@latest plan --issue -

--issue @task.md is also accepted as a file shorthand. Repeated --issue flags are rejected instead of silently discarding the earlier task.

Ask why

Every report explains the files it chose. --explain answers the harder question — why a file you expected is missing:

npx -y @aryam/fixmap@latest plan --issue "password reset emails fail" \
  --explain src/billing/invoice.ts

# Why src/billing/invoice.ts

Scored 2, below the lowest reported score of 24. Name a symbol, error string,
or path from this file in the task to raise it.

It distinguishes the cases that actually differ: the file was ranked, it scored below the cutoff, it was deliberately excluded (a test, a lockfile, generated output whose source was ranked instead), or the scan never saw it. When a scan hits its file limit, it says so rather than implying the path does not exist. Add --format json for the machine-readable form.

Measure a better task

The habit worth having is: plan, add the identifier the task was missing, re-plan, and check whether the real file rose. --compare prints that instead of leaving you to diff two JSON files by eye:

npx -y @aryam/fixmap@latest plan --issue "ranking confidence" \
  --format json --output before.json

npx -y @aryam/fixmap@latest plan \
  --issue "confidenceForEntry gives every top-8 file high confidence" \
  --compare before.json

2 entered, 2 left, 6 moved. The leading file changed from
scripts/evaluate-adversarial.mjs to packages/core/src/rank.ts.

Task grounding changed from **descriptive** to **anchored**.

## Moved
- `packages/core/src/rank.ts` rose from rank 2 to 1, score 9 to 42, confidence medium to high

That is FixMap's own feedback loop, measured in one command: naming a symbol moved the fix site from second place to first and turned a descriptive task into an anchored one.

Keep the noise out

Demo pages, marketing copy, and documentation often contain every symptom word a product documents, so they compete with the implementation. FixMap's built-in penalties cover conventions like examples/; a repository's own layout it cannot know:

npx -y @aryam/fixmap@latest plan --issue "password reset emails fail" \
  --exclude apps/web --exclude 'docs/**' --limit 3

Patterns can also live in a .fixmapignore file at the repository root, one per line, gitignore-flavored. The two combine — a flag refines the file rather than replacing it. --explain reports an excluded file as excluded, naming the pattern, rather than claiming it scored too low.

--limit caps how many context files come back. The useful signal is usually the top one to three; the rest burns agent context and invites drive-by edits.

To map what you are editing right now, without crafting a git spec:

npx -y @aryam/fixmap@latest plan --working-tree --issue "reset flow"

That means staged and unstaged tracked changes against HEAD. Untracked files stay out unless you add --include-untracked, so agent metadata and scratch files do not rank beside real edits.

Verify the change afterwards

plan answers where to start. verify answers whether the change that followed matches the plan — by comparing the saved report against a real git diff:

npx -y @aryam/fixmap@latest plan --issue "password reset emails fail" \
  --format json --output fixmap-report.json

# ...make the change...

npx -y @aryam/fixmap@latest verify --report fixmap-report.json --diff main...HEAD

FixMap verified 3 changed files against the plan and raised 1 error and 2 warnings.

- **error** A file was edited in a generated or retired location. A build regenerates
  these, so the change will be lost. Edit the source they are produced from.
  - `dist/auth/reset-password.js`
- **warning** One file changed that the plan did not rank. Either the task grew beyond
  the original description, or the ranking missed them — worth checking which.
  - `src/billing/charge.ts`
- **warning** Code changed but no test did. The plan routed this test as most related.
  - `test/reset-password.test.ts`

It checks five things: edits in generated or retired locations, files the change needed that the plan never ranked, an untouched leading file, source moving with no test moving, and risk areas the plan never flagged. Nothing is executed — both inputs are things you already have.

Only a discarded, untracked generated edit exits non-zero. A committed generated release artifact is a warning: confirm its maintained source changed and it was rebuilt. Everything else is advisory because a plan can be wrong and a change can still be right.

Check the install

An older global install can shadow the version npm was asked for, so a feature that shipped appears not to exist. doctor says which version is actually running and why:

npx -y @aryam/fixmap@latest doctor

# FixMap Doctor

- ok  Running version: 0.8.0
- PROBLEM  Global install: 0.3.1 (this process is 0.8.0)
    A globally installed fixmap shadows the version npx was asked for. Run
    `npm uninstall -g @aryam/fixmap`, or invoke the exact version with
    `npm exec --package=@aryam/fixmap@<version> -- fixmap <command>`.
- ok  Node version: 24.13.0

It exits non-zero when it finds a shadow, so a CI step fails rather than reading on.

MCP server

FixMap exposes three stdio tools: fixmap_plan builds the starting map, fixmap_verify compares that JSON report with the diff produced after editing, and fixmap_explain answers why one file ranked where it did — or why it is missing — for agents that have no shell to run --explain in.

fixmap_plan takes limit to cap how many context files come back, which matters when the useful signal is the top one to three and the rest is context budget. fixmap_verify accepts its report either inline or as a path to a saved JSON file, so a large plan need not be re-embedded in the tool call.

Claude Code:

claude mcp add fixmap -- npx -y @aryam/fixmap@latest mcp

Cursor, Windsurf, or another MCP client:

{
  "mcpServers": {
    "fixmap": {
      "command": "npx",
      "args": ["-y", "@aryam/fixmap@latest", "mcp"]
    }
  }
}

The official MCP Registry identifier is io.github.aryamthecodebreaker/fixmap. Analysis runs locally over stdio; FixMap does not send repository source to a hosted model or service.

Tell the agent how much to trust it

The fixmap_plan tool description carries this guidance, so most clients pick it up automatically. Add it to your agent's system prompt when you want it enforced:

Treat FixMap's output as a starting map, not proof that the task is valid.

1. Check the analysis block first. If it reports unresolved or unverified
   identifiers, vague task grounding, an incomplete scan, or a clustered
   ranking, do not assume the top-ranked file is correct.
2. Verify that identifiers, error strings, commands, and paths named in the
   task were actually found in the repository.
3. When no strong anchor resolves, search more broadly or ask for
   clarification before editing.
4. Prefer changed files, exact definitions, imports, and tests over generic
   keyword matches.
5. Never edit a file only because it ranked highly. Confirm the code there
   relates to the requested behavior.

This matters because the ranking is a lead, not a conclusion: across the frozen suites, a top result labeled high confidence is the correct fixing file 9 times out of 15 — measured below, not asserted.

GitHub Action

Install FixMap from GitHub Marketplace, or add the versioned Action directly:

name: FixMap

on:
  pull_request:

permissions:
  contents: read
  issues: write
  pull-requests: write

jobs:
  fixmap:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - id: fixmap
        uses: aryamthecodebreaker/[email protected]
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

The Action upserts one marked pull-request comment, writes the complete report to the step summary, and exposes report, context-count, and test-route-count outputs. Pin a release tag; a floating v1 tag will follow wider acceptance testing.

To close the plan→edit→verify loop without leaving GitHub, save the plan as an artifact and check later pushes against it with mode: verify:

      - id: plan
        uses: aryamthecodebreaker/[email protected]
        with:
          format: json
      - run: echo '${{ steps.plan.outputs.report }}' > fixmap-plan.json
      - uses: actions/upload-artifact@v4
        with:
          name: fixmap-plan
          path: fixmap-plan.json

      # In a later run, after the fix is pushed:
      - uses: aryamthecodebreaker/[email protected]
        with:
          mode: verify
          report-path: fixmap-plan.json

Verify mode exposes finding-count and changed-file-count, and fails the step only for an edit in a generated or retired location — the one finding that is wrong regardless of the task. Everything else is advisory, because a plan can be wrong and a change can still be right.

On forked pull requests, GitHub supplies a read-only token. FixMap warns instead of failing and keeps the full report in the step summary and outputs. Do not switch to pull_request_target while checking out untrusted fork code just to restore comments.

Why trust the output?

FixMap is deliberately inspectable:

• Deterministic: the same task, repository, and diff produce the same ranking—there is no hidden model call.
• Explainable: every ranked file includes reasons such as path matches, content matches, exact definitions, changed-file evidence, or import proximity.
• Local-first: local repositories stay local; public URLs use an anonymous temporary checkout.
• Non-executing: FixMap never installs dependencies or runs repository build, test, hook, or package scripts.
• Git-aware: scans respect .gitignore, include untracked files in working-tree diffs, and surface unresolved refs as errors.
• Monorepo-aware: test routing understands npm, pnpm, Yarn, Bun, and workspace package boundaries.
• Bounded: file counts, text samples, issue bodies, network responses, and remote-fetch time are capped with explicit diagnostics.

Public repository inputs accept only canonical credential-free https://github.com/owner/repository URLs. FixMap disables credential helpers, inherited Git configuration, hooks, submodules, symlinks, and LFS smudging, then removes the checkout on success or failure. Public issue fetching uses GitHub’s fixed API host without credentials or redirects.

Evidence, not hype

Most tools show you the benchmark they tuned on. Here is both.

FixMap is measured against real issues that were later fixed by a merged pull request. Each case pins the commit before the fix, feeds FixMap the issue text a maintainer actually wrote, and checks whether the file that fix changed appears in the ranking. Cases are chosen mechanically, and every input and output is checked in.

Plan around the held-out column. The regression suite is where the ranking heuristics were developed — a case missed, the ranker changed — so its 100% describes fit, not accuracy on your repository.

And read the intervals, not the percentages. At twelve cases one result flipping moves Top-3 from 67% to 83%. The honest statement is "somewhere in the region of three quarters", not "75%". Anyone quoting these figures to two significant figures, including us, is overstating them.

Two things the point estimates hide. Held-out Top-1 (58%) remains close to its Top-3 (75%) — when FixMap finds the file at all, it usually ranks it first, which is what actually matters to an agent that opens one file. The tuned suite's 100% Top-3 still conceals that in 33% of those cases something wrong ranks above the answer, so an agent following it opens the wrong file first.

The three held-out misses are published with their real rankings in benchmarks/heldout/, not removed or explained away.

Held-out repositories: mongoose, immer, jest, knex, mocha, got, socket.io, svelte, vite, vue, winston, yargs. Regression repositories: Express, Axios, debug, ky, Zod, Pino, Fastify, Chalk, Vitest, ESLint, Webpack, Undici, Redux Toolkit, Prettier, Hono.

Median scan and rank across the pinned repositories is 1.75 s, measured over three warm runs each.

Does the confidence label mean anything?

A confidence label is only useful if it predicts something. Across all 27 cases in both suites, when the top-ranked file is labeled:

The bands are not monotonic in this 27-case sample, so the label is a heuristic rather than a calibrated probability. High confidence still means “check this lead first,” not certainty. The intervals overlap heavily at these sample sizes, and the raw counts are published so the limitation is visible.

Since v0.8.0 the label is also scarce. It used to come from an absolute score threshold, which on a real Zod task labeled all eight results high while the leader was nineteen points ahead of the runner-up — telling an agent the eighth guess was as safe to edit as the first. High is now reserved for a file that leads, ties the lead within two points, or carries definition-site evidence of its own; and a leader that merely out-talks a definition site below it is capped at medium, because that competitor has the stronger kind of evidence. The table above is unchanged by this: it scores only the top-ranked file, and these rules almost always leave a genuine leader alone. What changed is the other seven rows, which no longer borrow the leader's certainty.

Does it stay quiet when it should?

Ranking the right file matters less than not inventing one. An adversarial suite runs fabricated identifiers, real identifiers from the wrong repository, vague requests, absent features, and runtime-only symptoms against real pinned repositories, and asserts FixMap does not overclaim:

Fabricated identifiers produce a diagnostic naming them and a low-confidence report rather than a persuasive wrong answer.

What is not claimed: there is no tokens-saved or minutes-saved figure here. Establishing one honestly needs a controlled experiment running the same tasks with and without FixMap, which has not been done. Byte-based context-size proxies are recorded in docs/BENCHMARKS.md and labeled as estimates, not savings.

Read the full benchmark methodology and scanner measurements, or reproduce either suite yourself:

npm run evaluate:heldout

What changed in v0.8.0

v0.8.0 closes all 22 open reports from a dogfooding sweep of v0.7.4. Two themes run through it.

FixMap was accurate about JavaScript and imprecise about everything else. Go and Rust repositories returned ranked files and no test command at all, which is ranking without any way to check the change. Both now route go test ./... and cargo test, workspace-scoped to the crate being edited. Language is read from the root manifest rather than by asking whether any file ends in .py — which had labeled clap-rs/clap, a Rust project with one helper script, a Python repository.

High confidence meant "in the list" rather than "the answer". It came from an absolute score threshold, so a real Zod task labeled all eight results high while the leader was nineteen points clear. High is now reserved for a file that leads, ties the lead, or carries definition-site evidence, and a leader that merely out-talks a definition site below it is capped at medium.

New surface: fixmap doctor, plan --compare, --exclude and .fixmapignore, --limit, --working-tree, progress phases on stderr, the fixmap_explain MCP tool, mode: verify for the Action, and pull request URLs accepted as task input. Fixed: verify --output created no file, duplicate --repo/--format flags silently kept the last value, and diagnostics echoed unbounded user text — including a quadratic-backtracking path that took 2.4 seconds on a 30,000-character paste, on a code path the Action feeds from public pull requests.

Inspect the changelog · See the held-out results · See every regression ranking · Audit the efficiency assumptions

Watch it work

Play the launch film · Explore the browser demo · Open the repository

The website demo runs against a small browser-only sample. The CLI, MCP server, and Action scan real repositories.

How ranking works

FixMap combines bounded, visible signals rather than one opaque score:

1. Normalize the issue, task text, repository input, and optional git diff.
2. Scan code, tests, documentation, and configuration while respecting ignore rules.
3. Rank path/content overlap, distinctive definition sites, changed files, import-graph proximity, nearby paths, and workspace ownership.
4. Route the closest package-level test command and related test files.
5. Report risk areas and diagnostics without executing the suggested commands.

The implementation lives in packages/core, shared by every interface.

Repository layout

packages/core     scanner, ranking, routing, reports
packages/cli      npx/CLI entry point and MCP server
packages/action   bundled GitHub Action
apps/web          interactive Next.js product site
benchmarks        transparent ranking evaluation cases
examples          inspectable sample input and output

Develop locally

FixMap requires Node.js 20.11 or newer.

npm ci
npm run ci

npm run ci covers typechecking, tests, a high/critical production audit gate, linting, production builds, Action and MCP metadata, bundle drift, smoke tests, evaluations, and scanner correctness. Use npm run benchmark:scan for the non-gating performance benchmark.

Current scope

FixMap is focused on JavaScript and TypeScript repositories. It does not claim that a ranked file is correct, execute suggested commands, or hide failed diff resolution.

Next priorities include:

• growing the held-out suite past twelve cases, where the confidence interval is still wide enough to matter
• measuring agent success with and without FixMap, which is the only honest route to a savings figure
• adding co-change and ownership signals
• publishing more monorepo adapters and examples
• promoting a stable v1 Action tag after wider acceptance testing

Real failure reports are worth more here than any of the above. If FixMap ranks the wrong file on your repository, that case is more useful than one selected by our own rule — open an issue with the task text and the repository, and it becomes a permanent benchmark case.

See open issues for scoped work, or start with CONTRIBUTING.md. Security reports belong in the process described by SECURITY.md.

License

MIT © FixMap contributors.