Localize

---
name: localize
description: >-
  Resolve a change request into an EXACT edit target before touching code, then
  gate the edit on tests — the localize → edit → validate loop. Use for a bug fix,
  an issue, or a feature change where the right files/symbols are not already
  obvious, or when the user says "이거 고쳐줘", "어디를 고쳐야 해?", "fix this
  issue", "where does this live?". Produces a localization artifact (targets +
  evidence + uncertainty) first; edits only after it, validates with a focused
  test then a regression run.
argument-hint: "<issue / change description>"
allowed-tools: Read, Grep, Glob, Bash, Edit, Write
---

# localize — localize → edit → validate

Do NOT start editing from the first plausible file. Empirically, a staged
**localize → repair → validate** loop resolves real repository issues at a
fraction of the cost of broad autonomous exploration (Agentless, arXiv
2407.01489), and the benchmark contract for "resolved" is a change whose tests
pass (SWE-bench, arXiv 2310.06770). This skill enforces that discipline: name the
target with evidence, make the minimal edit, then prove it with tests.

## 1. LOCALIZE — produce the target before editing

From the request, find the exact edit site(s). Do NOT edit in this phase.

- Extract the concrete signals from the request: error text, stack trace,
  symptom, endpoint / field / component name, the file it mentions.
- Search from those signals: `grep` the error string / symbol; `glob` the module;
  read the suspected files. For a symbol you will change, run
  `/harness-kit:blast-radius <symbol>` to enumerate everything that depends on it,
  so the edit scope is known up front (not discovered after a half-fix).
- If tests exist, use the failing test (or write one that reproduces the symptom)
  to point at the fault — a failing test IS localization evidence.

**Localization artifact (write it down, BLUF):**
- **Targets**: each `file:line` + symbol you intend to change, with the evidence
  that put it there (the grep hit / the failing test / the reference).
- **Impact**: the blast-radius set for any changed signature (callsites that must
  move together).
- **Uncertainty**: what you are NOT sure about + the candidate you'd check next.
  Non-empty is honest; a confident-but-wrong target is the failure mode here.

## 2. EDIT — minimal, scoped to the target

Make the smallest change that addresses the request at the localized site. Update
every callsite the blast-radius set named — do not leave a half-migrated signature.
Match the surrounding idioms.

## 3. VALIDATE — tests gate the change

- **Focused first**: run the specific test covering the change (or the reproducer
  from step 1). It must go from failing → passing.
- **Regression next**: run the stack's test command (the repo's detected
  `test_cmd`). Report pass/fail counts.
- **Real-run evidence** for a "feature works" claim: a real input → real output,
  not just green unit tests (per the kit's `0.3 No premature done`).
- Record the commands run + outcomes in the handoff / verify artifact.

## Constraints

- The localization artifact (step 1) is REQUIRED before any edit — no "edit first,
  find the rest later".
- A change is not done until its focused test passes AND the regression run is
  green (or the failures are pre-existing and named). "Compiles" / "200 OK" is not
  validation.
- No blind retries: if two edits don't pass, re-localize (the target was wrong),
  don't loop on the same site — broad retry loops compound error, they don't fix
  localization.
- Bounded autonomy: this is one change → one validation → the human gate, not an
  open-ended fix loop.