Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/sigistry/marketplaceWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/sigistry/marketplace/locate-change)<a href="https://agentmods.dev/commands/sigistry/marketplace/locate-change"><img src="https://agentmods.dev/badge/commands/sigistry/marketplace/locate-change/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/sigistry/marketplace/locate-change"><img src="https://agentmods.dev/badge/commands/sigistry/marketplace/locate-change.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00016 | $0.00557 |
| Opus 5 | $0.00008 | $0.00279 |
| Sonnet 5 | $0.00003 | $0.00111 |
| Haiku 4.5 | $0.00002 | $0.00056 |
Grade A, and why
locate-change scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 34 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Answer the hardest question in a large codebase: "where do I even make this change?" Describe the task in $ARGUMENTS (e.g. "add a 'remember me' checkbox to login", "rate-limit the export endpoint", "surface the invoice PDF in the account page") and get back a ranked list of the precise edit sites, files, functions, modules, plus the tests to update, each with a one-line rationale.
Process
Step 1: Frame the task
- Restate
$ARGUMENTSas the concrete capability to add or change. Extract the domain nouns (models/entities), verbs (actions), and surfaces (UI screen, API route, CLI command, job) it implies. - If the task is ambiguous about which surface it touches (UI vs API vs background job), note the assumption you'll search under rather than stalling.
Step 2: Localize
Launch the change-locator agent with the task. It greps for the relevant feature/route/model by the domain vocabulary, follows imports and references across layers, and identifies the specific files and functions where the change belongs plus the tests that cover them. This is a cheap, read-only, parallelizable exploration, it never modifies code.
Step 3: Report
The output is a ranked list. For each edit site:
| Rank | File:line | Symbol (function/class/module) | Why it's an edit site |
|---|
Then:
- Tests to update: the specific test files/cases that will need to change or be added, with
file:line. - Risks & edge cases: shared code paths, feature flags, migrations, or callers that make this change wider than it looks.
- Suggested order: the sequence to touch the sites (e.g. model → service → route → UI → tests) so the change stays coherent.
Important Notes
- Every edit site must be grounded in a real symbol at a real
file:line: never guess a path that doesn't exist. If the feature genuinely isn't present yet, say where the analogous existing feature lives as the template to copy. - Rank by confidence: the file that most obviously owns the behavior first, speculative sites last, each labeled with its rationale.
- Include the tests. A change isn't localized until you know which tests assert the current behavior.
- This is localization, not implementation, do not write the change here. Point precisely; let the user (or a follow-up) make the edit.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 34 lines · 16 tokens per session scan A be13bfe685d7
locate-change is a command published in the GitHub repository sigistry/marketplace (3 stars, last pushed today), licensed MIT. It adds 16 tokens to every session and 557 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
five-whys
Use the "Five Whys" root cause analysis technique to deeply understand problems.
debug
Structured debugging with parallel investigation agents.
dead-code-scan
Scan for dead code, unused imports, duplicates, and zombie code across the project.
esp-debug
Help debug ESP32 crashes, hangs, and peripheral issues.
f5-fix
This command has been consolidated into /f5-implement fix.
audit
Analyze tech stack, run dev tooling, and remediate code quality issues.