Trace root causes of confirmed failures with formal logic

A Logic-Lens skill for fault location: finding the root cause of a CONFIRMED failure via backward-then-forward semi-formal tracing. It triggers on a stack trace, failing assertion, error message, or specific wrong-value observation - phrases like "find the bug", "this test is failing", "track down this crash". It uses lazy loading of shared reference docs (common.md for language, Iron Law, Fault Confidence, scope routing, Remedy discipline, config fields, and loading budget; logic-locate-guide.md loaded step by step; logic-risks.md, semiformal-guide.md, semiformal-checklist.md, and report-template.md loaded on demand). The process runs eight steps: Step 0 detects language and confirms a concrete failure exists, switching to logic-review if there is only a suspicion rather than a confirmed failure. Step 1 establishes observed behavior, expected behavior, and the reproduction path. Step 2 identifies the entry point - the failing test, outermost application frame, or request handler closest to the failure - and stays inside the "failure cone" first: stack frames, the failing test fixture, directly called local functions, and config/env values read on that path, without scanning unrelated modules unless the trace crosses into them. Step 3 traces backward from the failure point, walking each value and state back to its origin and building premises at every hop. Step 4 traces forward from the suspected root to verify the trace reaches the observed symptom. Step 5 performs interprocedural tracing if a callee is implicated - tracing into the callee, checking return values, unhandled exceptions, and shared-state mutation - applying a depth limit and the Call-Chain Context Label format, and downgrading to Medium confidence when the limit is hit and the remaining callee path is stated as a premise assumption instead of traced. Step 6 identifies the root divergence and classifies it: the exact line/expression, the violated premise, the actual behavior, the propagation chain to the symptom, and an L-code. Step 7 outputs a focused report with a Fault Confidence line (High/Medium/Low), a single Primary Fault five-field finding, optional Contributing Factors, and a minimal Remedy. Formatting is mandatory even for simple one-function bugs - the labeled Premises/Trace/Divergence/Trigger/Remedy fields and the Fault Confidence line must always appear, never a plain fix suggestion. The mode line reads "Fault Locate" (故障定位 in Chinese), and unlike logic-review's Critical/Warning/Suggestion split, the Findings section here has exactly one Primary Fault, with the Logic Score line replaced by Fault Confidence.

Use it when a user provides a stack trace, failing assertion, error message, or specific wrong-value observation and wants the root cause found. Switch to logic-review instead if there is only a suspicion of a problem without a confirmed, reproducible failure.

Input is a confirmed failure - a stack trace, failing assertion, error message, or wrong-value observation. Output is a focused report: a Fault Confidence line (High/Medium/Low), a single Primary Fault finding with all five labeled fields and an L-code, optional Contributing Factors, and a minimal Remedy.

Part of the Logic-Lens skill family, sharing ../_shared/common.md, ../_shared/logic-risks.md, ../_shared/semiformal-guide.md, ../_shared/semiformal-checklist.md, and ../_shared/report-template.md with sibling skills logic-review, logic-diff, and logic-explain, and handing off to logic-review when the user only has a suspicion rather than a confirmed failure.

Developers debugging a confirmed, reproducible failure - a crash, failing test, or wrong output - who need the root cause traced back through the failure cone rather than a broad, unscoped code review.