Logic-Lens — Logic Fix All
When to Use
Use this skill when you need autonomous repository-wide audit-and-fix pipeline: health → review → locate/explain → fix → diff-verify → iterate until clean. Starts with a mandatory consent prompt (token-intensive); after consent runs hands-free. Trigger when the user wants ALL logic issues found and fixed — "fix...
Setup
Use phase-gated lazy loading per ../_shared/common.md §13:
- Before consent, read only
../_shared/common.mdfor language, scope routing, fix-all header fields, config fields, and loading budget; then readlogic-fix-all-guide.mdthrough the phase map andguide-phases-0-2-consent-scope-health.mdthrough Phase 0. - After consent, read each phase file only when entering that phase.
- Load
../_shared/logic-risks.md,../_shared/semiformal-guide.md,../_shared/semiformal-checklist.md,../_shared/report-template.md, and the other skill guides on demand when that phase invokes their methodology.
Process
Step 0. Language + scope routing. Detect language per common.md §1. Default scope is the repo root; honor a user-named subpath or pasted snippet. For a pasted snippet, skip the consent prompt and run the fix pipeline directly. Read .logic-lens.yaml for ignore:, custom_risks, severity:, focus:, and fix_all.max_iterations.
Step 1. Consent + scope enumeration (guide Phase 0–1) — for repo/directory scope: mandatory consent prompt displaying scope / method / cost / iteration cap; on consent, enumerate runtime-affecting files (source / config / constraint / doc), exclude .git and build artifacts, classify by risk tier. For a pasted snippet: skip consent, enumerate the snippet's functions directly.
Step 2. Health pass (guide Phase 2) — apply logic-health methodology to map per-module Logic Scores and L-code patterns.
Step 3. Deep review (guide Phase 3) — apply logic-review per file to collect full Premises → Trace → Divergence findings.
Step 4. Conditional clarification (guide Phase 4–5) — apply logic-locate where concrete failures exist; apply logic-explain when a finding's path is unclear (call depth > 3, cross-module, or async).
Step 5. Fix queue + remedy (guide Phase 6) — sort by severity; write a paste-ready Remedy per finding; route cross-file contradictions to the correct edit target (code / constraint / config / doc).
Step 6. Apply + verify (guide Phase 7) — apply each fix, then apply logic-diff methodology comparing original vs. fixed code. Expected verdict: ⚠️ Conditionally Equivalent where the differing condition is exactly the bug scenario. Revert if verdict is ✅ Semantically Equivalent (fix had no effect) or shows new divergences outside the bug scenario (regression). Retry up to 3×.
Step 7. Iterate + report (guide Phase 8–9) — re-run health + review on modified files and their consumers; Criticals loop without cap; Warning/Suggestion rounds capped by fix_all.max_iterations with user-escalation prompt at the cap. Output the Fix Report.
Mode line in report: Logic Fix All (Chinese: 逻辑全修).
Fix-report additions (appended after the standard Summary; localize all labels):
## Scope
| Role (source/config/constraint/doc) | Files scanned | Tier H/M/L | Truncated? |
|-------------------------------------|---------------|------------|------------|
## Skill Invocations
logic-health: N · logic-review: N · logic-locate: N · logic-explain: N · logic-diff: N
## Iteration History
| Round | Severity class | New findings | Action |
## Fix Log
| # | File | Lines | Finding | Risk | Severity | Fix Applied (one-line edit or diff summary) | Status (resolved/unresolved/reverted) |
## Resolved by Clarification
[Findings the Phase-5 logic-explain pass revealed as false positives. Empty if none.]
## Unresolved Findings
[Include reason per entry: "conflicting constraints", "user stopped iteration at round N",
"hard iteration ceiling reached", "ambiguous spec", "unclear whether spec or consumer is wrong".
Empty if all resolved.]
Report header fields (replace the standard single-line header per common.md §5):
**Logic Score (before):** XX/100
**Logic Score (after):** YY/100
**Findings fixed:** N (Critical: n1 · Warning: n2 · Suggestion: n3)
**Findings unresolved:** M
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.