Problem Locating Solving

Problem Locating and Solving

Concept of the skill

Use when locating a bug in an unfamiliar codebase, tracing a failure from symptom to source, or choosing between candidate fixes after the symptom is observed but before a patch lands.

Coverage

End-to-end bug localization workflow: problem-statement construction, search-space reduction by symptom type, boundary-based fault localization (entry-point tracing, differential comparison, binary search, minimal repro, search-before-read), root-cause isolation (symptom vs cause analysis with stop conditions), multi-option fix generation across local-patch / guardrail / structural classes, blast-radius comparison between candidates, implementation rules that bind the fix to a regression-proofing artifact, five verification types (repro test, regression test, neighbor check, blast-radius check, explanation check), and a four-question post-fix reflection that promotes one-off fixes into prevention mechanisms when the class could recur.

Philosophy of the skill

The most common debugging failure is not lack of skill — it is skipping steps. Agents jump from symptom to fix without isolating the root cause, which produces patches that hide bugs instead of removing them. This skill exists for the gap between "something is wrong" and "the right fix is verified."

Every step in the loop has been added because skipping it caused a real false fix. Knowing debugging theory is not enough — you need a repeatable way to find the failing boundary, isolate the actual cause, compare solution options, and prove the fix closes the problem without widening the blast radius. The loop is the process; intuition without the loop produces patches that look like fixes and re-emerge under different inputs two days later.

Workflow

Use the ordered phases, checklists, and guardrails in the sections below as the canonical workflow for this skill. When multiple subsections describe steps, follow them in the order presented.

1. The Locate-to-Solve Loop

Use this loop in order. Skipping steps creates false fixes.

1. Define the problem precisely.
2. Bound the search space.
3. Locate the first failing boundary.
4. Isolate the root cause.
5. Generate multiple fix options.
6. Choose the lowest-blast-radius fix that prevents recurrence.
7. Verify with regression evidence.
8. Reflect on what should now be prevented or documented.

2. Problem Statement Contract

Before searching the codebase, write the problem in a concrete form.

If one of these is missing, the search space is still too loose.

3. Bound the Search Space

Do not search the whole repo emotionally. Reduce the space first.

Search-space reduction table

Bounding rules

• Prefer the first failing boundary over the final visible symptom.
• Prefer the smallest reproducible path over the full production path.
• Prefer one confirmed stack trace or failing assertion over broad speculation.
• If you cannot name the likely subsystem, you are still in discovery, not fixing.

4. Locate the First Failing Boundary

The critical move is to find the first point where reality stops matching the expected flow.

Boundary questions

• Where is the first bad value observed?
• What was the last known-good step immediately before it?
• Is the failure caused by code, data, environment, or timing?
• What single check would prove which of those four buckets owns it?

5. Root Cause Isolation

Symptoms are not causes. A cause explains why the symptom appears.

Cause-isolation pattern

1. State the symptom.
2. Ask what immediate condition makes that symptom possible.
3. Ask what created that condition.
4. Stop only when the answer identifies a fixable logic, data, config, or process cause.

Symptom vs cause table

If the proposed fix does not explain why the symptom happened, it is probably still a patch.

6. Generate More Than One Fix

Do not lock onto the first plausible solution.

Generate at least two candidate fixes whenever the root cause is not trivial.

Compare candidate fixes by

• blast radius
• reversibility
• recurrence prevention
• alignment with existing patterns
• verification cost

Pick the option that solves the root cause with the smallest justified surface area.

7. Implementation Rules

• Fix the cause, not only the symptom.
• Add the smallest regression-proofing artifact that fits: test, guard, or doc rule.
• Keep the proof close to the fix: failing case before, passing case after.
• If the fix touches a shared pattern, look for sibling sites that may carry the same defect.

8. Verification Rules

The fix is not complete until the original failure mode is proven closed.

Verification minimum

1. Reproduce the failure before the fix when possible.
2. Show the failure no longer occurs after the fix.
3. Check one neighbouring path that could regress.
4. Record the root cause in one sentence.

9. Reflection and Prevention

After the fix, ask:

• Was this a one-off or a repeated class of issue?
• Should this become an eval, lint rule, or doc rule?
• Did the real delay come from locating the bug or deciding the fix?
• What clue should future agents notice sooner?

If the same class of bug could reasonably recur, promote the learning into a prevention mechanism.

Verification

• I can state the problem in concrete expected-vs-actual terms.
• I have reduced the search space before opening lots of files.
• I know the first failing boundary, not just the final symptom.
• I can explain the root cause in one sentence.
• I considered more than one fix when the cause was non-trivial.
• I verified the original failure path and one neighbouring path.
• I captured any new prevention rule if this problem class could recur.

Do NOT Use When