opencode-skills-collection 3.1.12 → 3.1.13

package/bundled-skills/logic-diff/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: logic-diff
+description: Compare two code versions for semantic equivalence via semi-formal tracing of both versions side-by-side. Trigger when the user shares a refactor, rewrite, migration, or A/B implementation and wants to confirm behavior is unchanged — "did I break anything", "is this equivalent", "are...
+risk: unknown
+source: https://github.com/hyhmrright/logic-lens/tree/main/skills/logic-diff
+source_repo: hyhmrright/logic-lens
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/hyhmrright/logic-lens/blob/main/LICENSE
+---
+
+# Logic-Lens — Semantic Diff
+## When to Use
+
+Use this skill when you need compare two code versions for semantic equivalence via semi-formal tracing of both versions side-by-side. Trigger when the user shares a refactor, rewrite, migration, or A/B implementation and wants to confirm behavior is unchanged — "did I break anything", "is this equivalent", "are...
+
+
+## Setup
+
+Use lazy loading per `../_shared/common.md` §13:
+1. Read `../_shared/common.md` only for language, Iron Law, Verdict header, scope routing, Remedy discipline, config fields, and loading budget.
+2. Read only the relevant step in `logic-diff-guide.md` as you reach it.
+3. Load `../_shared/logic-risks.md`, `../_shared/semiformal-guide.md`, `../_shared/semiformal-checklist.md`, and `../_shared/report-template.md` on demand when the current step needs them.
+
+## Process
+
+**Step 0. Language + scope routing.** Detect language per `common.md` §1. Confirm two versions are provided. If only one version, switch to logic-review.
+
+**Step 1. Identify the shared specification** (guide Step 1) — what inputs should both versions handle; what outputs/side effects are expected. If the user states the refactor intentionally changed behavior in a specific area (e.g., "I changed the error path to raise instead of returning None"), record that as a **declared spec change** and treat divergences within that area as expected. Flag only divergences outside the declared change as findings.
+
+**Step 2. Build independent premises for each version** (guide Step 2) — apply the Premises Construction Checklist to Version A and Version B separately.
+
+**Step 3. Trace both versions for the common case** (guide Step 3) — parallel trace, same input, note the first divergence if any.
+
+**Step 4. Trace boundary cases** (guide Step 4) — empty/null/zero, max/min, error inputs, first/last of collections. Start with at most three highest-risk boundary scenarios unless the user asks for exhaustive equivalence or the shared specification requires more.
+
+**Step 5. Identify and classify semantic divergences** (guide Step 5) — each divergence is a finding with Premises → Trace → Divergence → Trigger → Remedy and an L-code.
+
+**Step 6. Equivalence verdict** (guide Step 6) — one of: `✅ Semantically Equivalent`, `⚠️ Conditionally Equivalent` (state the condition precisely), `❌ Semantically Divergent`.
+
+**Step 7. Output** (guide Step 7) — Report Template with the Verdict header per `common.md` §5; localize headers if the user wrote in Chinese. **Format is mandatory even for trivially short snippets: every divergence finding MUST use the five labeled fields (Premises / Trace / Divergence / Trigger / Remedy); never substitute with a plain paragraph or table.**
+
+**Mode line in report:** `Semantic Diff` (Chinese: `语义对比`).
+
+## 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.

package/bundled-skills/logic-diff/logic-diff-guide.md

@@ -0,0 +1,75 @@
+# Semantic Diff — Step-by-Step Guide
+
+## Step 1: Identify the Shared Specification
+
+Two versions are semantically equivalent if they produce identical behavior for all inputs in the shared specification. Establish it:
+- What inputs are both versions expected to handle?
+- What outputs or side effects should both produce?
+- Are there inputs one version handles that the other doesn't? (This may itself be the divergence.)
+
+If the user hasn't stated the spec, derive it from shared tests, the commit message/PR description, or the function's documented contract. State the derived specification explicitly.
+
+## Step 2: Build Independent Premises for Each Version
+
+Apply the full **Premises Construction Checklist** at `../_shared/semiformal-checklist.md` to Version A and Version B **separately**:
+- Name resolution: same identifier, same resolution in both?
+- Type contracts: same type assumptions at call sites?
+- State preconditions: same preconditions required?
+- Control flow: same branches for same inputs?
+
+This step often surfaces the divergence before the trace begins — a renamed import, a changed conditional, a different default value.
+
+## Step 3: Trace Both Versions for the Common Case
+
+```
+Scenario: [describe the input]
+
+Version A — Trace:
+1. [step]
+2. [step]
+Result: [value / side effect]
+
+Version B — Trace:
+1. [step]
+2. [step]
+Result: [value / side effect]
+
+Verdict: [Equivalent / Divergent at step N]
+```
+
+If both produce the same result, proceed to Step 4. If they diverge, jump to Step 5.
+
+## Step 4: Trace Boundary Cases
+
+Rank boundary conditions by how likely they are to expose a behavior change, then trace Version A and B separately for the top scenarios:
+- Empty/null/zero inputs (catches L3 divergences)
+- Maximum values (integer overflow in one version but not the other)
+- Error inputs (which version raises, which returns a default?)
+- First and last elements of collections (off-by-one in one version)
+
+Default budget: trace the common case plus at most three boundary scenarios. Expand only when the user asks for exhaustive comparison, the shared specification names more required cases, or a traced path exposes a new boundary that must be confirmed.
+
+## Step 5: Identify Semantic Divergences
+
+A semantic divergence is any scenario where A and B produce different behavior. Classify each:
+- Bug in A corrected in B (intended)
+- Regression: B breaks something A handled (unintended)
+- Behavioral change: both work, but differently — user must decide which is correct
+- Scope expansion: B handles inputs A didn't
+
+For each divergence, write a five-field finding (Premises → Trace → Divergence → Trigger → Remedy) with the L-code that best describes the cause.
+
+## Step 6: Classify Equivalence
+
+- **✅ Semantically Equivalent:** No divergence found for all traced scenarios.
+- **⚠️ Conditionally Equivalent:** Equivalent for all common cases; diverges only when [specific condition — state precisely].
+- **❌ Semantically Divergent:** Confirmed behavioral difference at [location] for [scenario].
+
+Note: "No divergence found" is not "provably equivalent." State which scenarios were traced and acknowledge untested scenarios may still diverge.
+
+## Step 7: Output
+
+Use the Report Template from `report-template.md`. Replace Logic Score with the equivalence verdict. In Summary:
+1. The verdict
+2. The most significant divergence (or "no divergences found under traced scenarios")
+3. Any untraced scenarios that should be verified manually

package/bundled-skills/logic-explain/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: logic-explain
+description: Explain what a specific piece of code actually does for a given input by producing a step-by-step execution trace (interprocedural, with name resolution and type transitions). Trigger when the user is confused about behavior or asks why code produces X instead of Y — "walk me through...
+risk: unknown
+source: https://github.com/hyhmrright/logic-lens/tree/main/skills/logic-explain
+source_repo: hyhmrright/logic-lens
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/hyhmrright/logic-lens/blob/main/LICENSE
+---
+
+# Logic-Lens — Execution Explain
+## When to Use
+
+Use this skill when you need explain what a specific piece of code actually does for a given input by producing a step-by-step execution trace (interprocedural, with name resolution and type transitions). Trigger when the user is confused about behavior or asks why code produces X instead of Y — "walk me through...
+
+
+## Setup
+
+Use lazy loading per `../_shared/common.md` §13:
+1. Read `../_shared/common.md` only for language, report header variants, scope routing, and loading budget.
+2. Read only the relevant step in `logic-explain-guide.md` as you reach it.
+3. Load `../_shared/semiformal-guide.md`, `../_shared/semiformal-checklist.md`, and `../_shared/report-template.md` on demand when the current step needs them.
+
+Note: `logic-risks.md` is intentionally skipped — logic-explain does not produce L-code findings, and Remedy is intentionally out of scope for this mode. If the trace reveals a bug, stop and recommend logic-review or logic-locate. When handing off, do not discard work already done — present the premises established and trace steps completed under a **"Partial trace context (carry into next skill):"** heading so the user can pass them directly to the follow-on skill.
+
+## Process
+
+**Step 0. Language + scope routing.** Detect language per `common.md` §1. Confirm a single function + a single input scenario. If the user wants bug-finding without a scenario, hand off to logic-review.
+
+**Step 1. Entry point and scenario** (guide Step 1) — name the function, the input scenario, and what the user is trying to understand.
+
+**Step 2. Build premises** (guide Step 2) — resolve every non-obvious name, state the types of key variables at entry, note global/module state accessed.
+
+**Step 3. Produce step-by-step trace** (guide Step 3) — numbered, interprocedural, active voice; cross function boundaries whenever relevant to the user's scenario. Keep the trace scenario-bound; do not branch into alternative paths unless they explain the user's confusion.
+
+**Step 4. Highlight non-obvious behavior** (guide Step 4) — name resolutions, implicit coercions, hidden side effects; the "gotchas" the casual reader would miss.
+
+**Step 5. Summarize actual vs. assumed** (guide Step 5) — one sentence each; this is the core value for the user.
+
+**Mode line in report:** `Execution Explain` (Chinese: `执行解释`).
+
+**Note:** Execution Explain is descriptive, not evaluative. Omit the Logic Score / Fault Confidence / Verdict line from the report header.
+
+## 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.

package/bundled-skills/logic-explain/logic-explain-guide.md

@@ -0,0 +1,74 @@
+# Execution Explain — Step-by-Step Guide
+
+## Step 1: Establish Entry Point and Scenario
+
+Confirm or infer from context:
+- Which function/method/code block is the entry point?
+- Which input scenario is being traced?
+- What is the user trying to understand?
+
+State explicitly at the start: "Tracing `process_payment(order, card)` for the scenario where the card is declined."
+
+## Step 2: Build Premises
+
+Apply the **Premises Construction Checklist** at `../_shared/semiformal-checklist.md` — Name Resolution, Type Contracts, State Preconditions, Control Flow Assumptions.
+
+Key emphasis for explanations:
+- Resolve every non-obvious name (if the user is asking how something works, they probably don't know which `format` or `sort` is being called).
+- State the type of every significant variable at entry.
+- Note any global or module-level state the function reads or modifies.
+
+## Step 3: Produce the Step-by-Step Trace
+
+Write as a numbered sequence. Goal: a reader who has never seen this code can follow exactly what happens.
+
+- Short, active sentences: "`items.sort()` calls the list's `sort` method with no key, sorting ascending using `__lt__`."
+- When crossing a function boundary: "Entering `validate_card()` at `payments.py:88`."
+- When a conditional determines execution: "`if card.status == 'active'` evaluates to `False` because `card.status` is `'declined'`. Taking the else branch."
+- When state changes: "`order.status` mutated from `'pending'` to `'failed'` at line 134."
+
+**Depth calibration:**
+- High-level flow: trace at function-call level, summarize internals unless relevant.
+- Surprising behavior: go deep into the surprising part, even into library code.
+- Debugging: trace until the unexpected behavior, then explain exactly why it occurs.
+
+Scenario budget: stay on the single input scenario. Mention untaken branches only when they explain why the current path behaves differently than the user expects; do not trace full alternatives.
+
+## Step 4: Highlight Non-Obvious Behavior
+
+After the trace, explicitly call out anything a reader might not expect:
+- Names that resolve differently than they look (L1 patterns)
+- Implicit type coercions
+- Side effects not obvious from the signature
+- Conditions under which this execution path is NOT taken
+- Assumptions the code makes that may not hold in all environments
+
+Format: "Worth noting: `format()` on line 42 is NOT Python's builtin — it resolves to the module-level `format()` at line 8 of this file, which expects a datetime object."
+
+## Step 5: Summarize Actual vs. Assumed Behavior
+
+Close with two statements:
+
+**What the code actually does:** A one- or two-sentence factual description revealed by the trace.
+
+**What a casual reader might assume:** The plausible misreading the trace contradicts.
+
+**Example:**
+"What the code actually does: `save_record()` commits the transaction then logs the record ID, but if the commit fails, the log statement still executes with a stale ID.
+What a casual reader might assume: logging happens after commit succeeds, so the logged ID is always valid."
+
+## Step 6: Map to Report Template
+
+- **Header:** Mode = `Execution Explain` / `执行解释`; omit the mode-specific score line.
+- **Findings section:** Always omit — logic-explain produces no L-code findings and no Remedy. If the trace reveals a bug, note it in Step 4, recommend re-running with logic-review or logic-locate, and output a handoff block:
+
+  ```
+  **Partial trace context (carry into next skill):**
+  Premises established: [list key premises from Step 2]
+  Trace completed to: [last confirmed step before the bug was spotted]
+  Suspected divergence: [one-sentence description — no L-code, no Remedy]
+  ```
+
+  Chinese equivalent: `**部分追踪上下文（移交至下一技能）：**` / `已建立的前提：` / `追踪进展至：` / `疑似偏差：`
+
+- **Summary:** Place the Step-by-Step Trace (Step 3), Non-Obvious Behavior (Step 4), and Actual vs. Assumed pair (Step 5) as labeled sub-sections within Summary.

package/bundled-skills/logic-fix-all/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: logic-fix-all
+description: '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...'
+risk: unknown
+source: https://github.com/hyhmrright/logic-lens/tree/main/skills/logic-fix-all
+source_repo: hyhmrright/logic-lens
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/hyhmrright/logic-lens/blob/main/LICENSE
+---
+
+# 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:
+1. Before consent, read only `../_shared/common.md` for language, scope routing, fix-all header fields, config fields, and loading budget; then read `logic-fix-all-guide.md` through the phase map and `guide-phases-0-2-consent-scope-health.md` through Phase 0.
+2. After consent, read each phase file only when entering that phase.
+3. 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.

package/bundled-skills/logic-fix-all/guide-phases-0-2-consent-scope-health.md

@@ -0,0 +1,113 @@
+# Logic-Lens — Logic Fix All — Phases 0-2 (Consent · Scope · Health)
+
+---
+
+## Phase 0 — Pre-flight Notice & Consent Gate
+
+0a. Estimate file count (`git ls-files | wc -l` in a git repo; `find . -type f -not -path '*/.git/*' -not -path '*/node_modules/*' -not -path '*/target/*' -not -path '*/.venv/*' -not -path '*/build/*' -not -path '*/dist/*' -not -path '*/vendor/*' | wc -l` otherwise). Display this notice verbatim with the estimate filled in — do not paraphrase:
+
+```
+⚠️  /logic-fix-all — Full Repository Logic Audit & Fix
+
+Scope:    ENTIRE repository, not just recent commits or staged changes.
+          Includes runtime-affecting files: source code, runtime
+          config (.json/.yaml/.toml/.ini), constraint files
+          (CLAUDE.md, .logic-lens.yaml, AGENTS.md, etc.), and
+          behavioral documentation (README, ARCHITECTURE, ADRs).
+          Auto-excludes .git, build artifacts, dependency caches,
+          binary assets; respects .gitignore and .logic-lens.yaml
+          `ignore:` patterns.
+Estimated files to scan: ~N
+
+Method:   Semi-formal execution tracing — Premises → Trace →
+          Divergence → Remedy. This is a LOGIC review, not a
+          syntax/style/lint pass.
+
+Skills:   logic-health → logic-review → logic-locate → logic-explain
+          → logic-diff, iterated until clean.
+
+Token cost: HIGH. The pipeline uses ranked passes and scope caps, but
+deep tracing still costs roughly 5k–15k tokens per reviewed file
+(more for deeply interprocedural code, less for stateless utilities),
+times ~1.3 for iteration rounds.
+Your estimate: min(N, 100) reviewed files × ~10k tokens × 1.3 ≈
+(compute and show here, e.g. "~1M tokens").
+
+Git impact: The pipeline edits source files. It does NOT commit,
+push, or amend. If you have uncommitted work, commit or stash first.
+
+Iteration: Critical findings loop until resolved (no cap). Warnings
+and Suggestions default to 3 rounds, configurable via
+`.logic-lens.yaml` `fix_all.max_iterations:`.
+
+Proceed with full autonomous run? [Y/n]
+```
+
+0b. Parse the user's reply. Maintain two phase-local counters (reset when Phase 0 exits): `consecutive_pauses`, `consecutive_questions`.
+
+Signal sets (case-insensitive):
+- **Consent:** `Y`, `yes`, `ok`, `sure`, `proceed`, `go`, `continue`, `继续`, `好`, `好的`, `行`, `可以`
+- **Hard negation:** `no`, `n`, `abort`, `cancel`, `取消`, `don't`, `不要`
+- **Soft-pause:** `wait`, `hold on`, `not yet`, `一下`, `先别`, `等一下`, `等我`, `let me`
+
+Decision (first match wins):
+1. Hard negation → abort: "Aborted by user before scan — no files modified".
+2. Consent + soft-pause → increment `consecutive_pauses`, acknowledge in one line, wait for next message. If `consecutive_pauses` would reach 3, re-show the full Phase 0 notice and reset to 0.
+3. Consent (no negation) → proceed. Honor any scope/language instructions in one acknowledgment line.
+4. Question → increment `consecutive_questions`, answer once, re-prompt. If `consecutive_questions` would reach 2, fall through to rule 5.
+5. Unmatched (or falling through from rule 4) → re-show notice once; if next reply still unmatched, treat as abort.
+
+0c. After consent, ask no further questions until Phase 8 cap escalation.
+
+---
+
+## Phase 1 — Scope Enumeration
+
+1a. Read `.logic-lens.yaml` (if present): load only `ignore`, `focus`, `disable`, `custom_risks`, `severity:`, `trace.*`, and `fix_all.max_iterations`. Apply `ignore` immediately.
+
+1b. Detect project type from marker files and derive exclusions:
+- `package.json` → exclude `node_modules/`, `dist/`, `build/`, `.next/`, `.nuxt/`, `coverage/`
+- `Cargo.toml` → exclude `target/`
+- `go.mod` → exclude `vendor/` (unless project-owned — check `modules.txt`)
+- `pyproject.toml`/`requirements.txt`/`Pipfile` → exclude `.venv/`, `venv/`, `__pycache__/`, `*.egg-info/`, `.pytest_cache/`, `.mypy_cache/`, `.ruff_cache/`
+- `Gemfile` → exclude `vendor/bundle/`
+- `pom.xml` → exclude `target/`
+- `build.gradle`/`build.gradle.kts` → exclude `build/`, `.gradle/`
+- `build.sbt` → exclude `target/`, `project/target/`
+- `mix.exs` → exclude `_build/`, `deps/`
+- `composer.json` → exclude `vendor/`
+- `*.csproj`/`*.sln` → exclude `bin/`, `obj/`
+- `pubspec.yaml` → exclude `.dart_tool/`, `build/`
+- Always exclude: `.git/`, `.DS_Store`, lock files (`*.lock`, `package-lock.json`, `yarn.lock`, `Pipfile.lock`, `poetry.lock`, `Cargo.lock`, `go.sum`), log files, binaries (`.png/.jpg/.gif/.pdf/.wasm/.zip/.tar/.gz/.woff*/.ttf`)
+- Respect `.gitignore` as a hint, not absolute — some ignored paths may still be relevant.
+
+1c. Classify every non-excluded file into exactly one bucket:
+- **Source code:** files whose extension matches a language the project uses (inferred from markers in 1b).
+- **Runtime config:** `.json`, `.yaml/.yml`, `.toml`, `.ini`, `.conf`, `*.config.js/ts` — verify by grepping the codebase for the filename before classifying.
+- **Constraint files:** `CLAUDE.md` at every level, `.logic-lens.yaml`, `AGENTS.md`, `GEMINI.md`, schema files (`*.schema.json`, `openapi.yaml`, `*.proto`, `*.graphql`).
+- **Behavioral docs:** `README.md`, `CONTRIBUTING.md`, `ARCHITECTURE.md`, `docs/**/*.md` describing runtime behavior, `.env.example`. Skip changelogs, licenses, marketing copy, `.editorconfig`.
+
+1d. Classify each file by risk tier:
+- **High:** public API surfaces; files changed in the last 30 days (`git log --since=30.days --name-only --pretty=format: | sort -u`); core business logic without test coverage.
+- **Medium:** utility modules, helpers, non-core configs, stable constraint files.
+- **Low:** stable well-tested code, stable docs.
+
+Newly added files are already High. Constraint/behavioral-doc files are Medium by default, upgraded to High if referenced by recently-changed code. When a file matches multiple criteria, assign the highest tier.
+
+1e. Sort: High → Medium → Low; within each tier, descending line count.
+
+1f. Scope caps:
+- **>20 files:** Low-tier files reviewed at reduced depth (top 3 non-trivial functions only).
+- **>100 files:** keep only top 100 by (tier desc, line-count desc); drop the rest. Note truncation in the Fix Report.
+
+1g. State the final file list at the start of the Fix Report: file name + tier + role.
+
+---
+
+## Phase 2 — Health Pass (logic-health)
+
+2a. Apply `../logic-health/logic-health-guide.md` methodology to the Phase 1 file list, including its module/function budgets. Output: per-module Logic Score, aggregated findings by L-code, systemic patterns.
+
+2b. Record Phase 2 output for reference. Do NOT write remedies yet — health gives shape, not precision. Precise findings come from Phase 3.
+
+2c. If the health pass reveals a systemic pattern (same L-code in 4+ modules), earmark the representative file for Phase 3 priority review. Phase 3 must produce the full Premises→Trace→Divergence triple before the pattern can enter Phase 6 as a fix candidate — a systemic observation without a trace cannot justify a remedy.

package/bundled-skills/logic-fix-all/guide-phases-3-5-review-locate-clarify.md

@@ -0,0 +1,47 @@
+# Logic-Lens — Logic Fix All — Phases 3-5 (Review · Locate · Clarify)
+
+---
+
+## Phase 3 — Deep Review (logic-review)
+
+3a. Apply `../logic-review/logic-review-guide.md` to each file in Phase 1 priority order, using `../_shared/common.md` §9 and §13 scope budgets. For files over the review budget, trace the highest-risk entry points first and record untraced functions in the finding state; do not perform shallow pattern scans to claim full coverage.
+
+3b. Adapt method to file role:
+- **Source code:** standard Premises→Trace→Divergence.
+- **Runtime config:** premises = claimed shape and value constraints; trace how code reads each key; divergence = missing/wrong-typed key or constraint violation.
+- **Constraint files** (CLAUDE.md, .logic-lens.yaml, AGENTS.md): premises = stated invariants; trace the code paths they govern; divergence = code violating the invariant.
+- **Behavioral docs:** premises = documented behavior; trace the implementation; divergence = contradiction.
+
+3c. Tag each finding with: file path + line range, file role, risk code (L1–L9 or Cx), severity, full Premises→Trace→Divergence triple, and one origin tag:
+- `"confirmed by trace"` (default)
+- `"unconfirmed — manual check recommended"` (excluded from fix queue per Iron Law)
+- `"confirmed by test/error"` (written by Phase 4b)
+- `"discovered during verification"` (written by Phase 7c; queued for next iteration)
+
+3d. Deduplicate: if the same root cause appears in multiple files, record one finding for the root and list all call sites.
+
+3e. Pass budget: for more than 20 files, complete Phase 3 in ranked batches of 20 files. After each batch, immediately advance confirmed Critical findings to Phase 6 before continuing lower-tier files. Warning/Suggestion findings can wait until the current batch finishes.
+
+---
+
+## Phase 4 — Fault Location (logic-locate, conditional)
+
+Run only if: user provided a stack trace or error message, repo has failing tests, or user described a specific wrong behavior.
+
+4a. Apply `../logic-locate/logic-locate-guide.md` to each concrete failure.
+
+4b. For each locate finding: if already in Phase 3 results → mark "confirmed by test/error"; if not → add with "confirmed by test/error" tag.
+
+---
+
+## Phase 5 — Path Clarification (logic-explain, conditional)
+
+Invoke logic-explain only when a Phase 3/4 finding matches any of:
+- Call depth > 3
+- Cross-module (trace crosses a module/package boundary)
+- Premises marked "partial — path unclear"
+- Async/concurrent/callback flow hard to linearize
+
+5a. Apply `../logic-explain/logic-explain-guide.md` to each flagged finding.
+
+5b. Update the finding's Premises→Trace→Divergence from the explain output. If the explain pass shows the original divergence was a misunderstanding, remove the finding from the queue and record it in Phase 9 under "Resolved by clarification".

package/bundled-skills/logic-fix-all/guide-phases-6-9-fix-iterate-report.md

@@ -0,0 +1,143 @@
+# Logic-Lens — Logic Fix All — Phases 6-9 (Fix · Verify · Iterate · Report)
+
+---
+
+## Phase 6 — Fix Queue Assembly
+
+6a. Merge all findings from Phases 3–5 (Phase 3 review + Phase 4 locate, as updated/filtered by Phase 5 clarification). Phase 2 health observations are not directly included — they must first receive a full Premises→Trace→Divergence triple from Phase 3 before entering the queue (Iron Law).
+
+6b. Sort by severity. Secondary sort within each tier: (1) "confirmed by test/error" first; (2) systemic-pattern roots before symptoms; (3) root causes before call sites.
+
+| Priority | Criteria |
+|----------|----------|
+| 1 | 🔴 Critical |
+| 2 | 🟡 Warning |
+| 3 | 🟢 Suggestion |
+
+6c. For each finding, write the remedy: **Minimal** (change only what the trace shows is wrong), **Targeted** (no side-effect refactoring), **Justified** (one sentence explaining why this fix).
+
+6d. Remedy target for cross-file contradictions:
+- **Code vs constraint file** (CLAUDE.md/AGENTS.md/GEMINI.md/README): edit the CODE. Exception: if the constraint text is obviously stale (references a removed function/module) and code is internally coherent, edit the CONSTRAINT FILE and note spec drift in the Fix Log.
+- **Code vs runtime config**: edit the CONFIG. Exception: if the config value is internally coherent for its key AND the code looks typo'd, edit the CODE. When both sides are plausible, record as "Unresolved — unclear whether spec or consumer is wrong".
+- **Doc vs doc**: (1) more recent git mtime wins; (2) deeper path beats root-level; (3) still tied → "Unresolved — ambiguous spec" with both citations.
+- **Config internally inconsistent**: edit at the less-referenced key.
+
+---
+
+## Phase 7 — Apply + Verify (logic-diff)
+
+7a. Before the first fix, capture the baseline:
+
+```bash
+PRE_FIX_REF=$(git rev-parse HEAD)
+```
+
+If not a git repo, copy each file to `.logic-fix-all-backup/<path>` before its first edit.
+
+Apply fixes one finding at a time. After each fix: record file path, line range changed, one-line description → Fix Log row. For overlapping line ranges in the same file, fix the higher-priority one first, then re-read the file before applying the second.
+
+7b. When a remedy requires choosing between approaches, match the surrounding code's existing convention (read nearest callers and peer functions). When no convention is discoverable, default to the more defensive option (raise/reject/fail fast).
+
+7c. Apply `../logic-diff/logic-diff-guide.md` between pre-fix and post-fix versions. For independent files, verify in parallel; for same-file or cross-dependent fixes, verify one at a time.
+
+**Hard verification gate** before declaring a fix as "pass":
+```bash
+git diff -- <file>
+git diff "$PRE_FIX_REF" -- <file>
+```
+The diff must: (a) match the planned remedy, (b) touch no lines outside the finding's scope, (c) leave the file syntactically valid. If any fail, jump to 7d.
+
+Interpret logic-diff verdicts:
+
+| Verdict | Condition | Meaning | Action |
+|---------|-----------|---------|--------|
+| Conditionally Equivalent | covers exactly the failing scenario | fix removes the bug | **pass** |
+| Conditionally Equivalent | narrower or broader than failing scenario | partial/over-scoped fix | 7d |
+| Conditionally Equivalent | orthogonal to failing scenario (original Divergence no longer triggers) | fix succeeded; new condition is a pre-existing separate bug | **pass** + record new finding tagged "discovered during verification" |
+| Semantically Equivalent | — | fix changed nothing | 7d |
+| Semantically Divergent | — | fix broke previously-correct paths | 7d |
+
+Additionally verify that the specific Divergence field condition no longer triggers post-fix.
+
+7d. On regression, revert and retry:
+```bash
+git checkout "$PRE_FIX_REF" -- <file>
+# or: cp .logic-fix-all-backup/<path> <path>
+```
+Never use `git reset --hard` or `git clean -f`. After 3 failed attempts, record as "Unresolved — conflicting constraints" and continue.
+
+7e. If logic-diff cannot confirm equivalence (function too complex or involves external state), note as "unverified — integration test recommended" and continue.
+
+---
+
+## Phase 8 — Iteration Loop
+
+### 8a. Persistent state across rounds
+
+- **`unresolvable_findings`** (set): findings Phase 7d retired with "Unresolved — conflicting constraints". Each entry is `(file_path, line_range, L_code, divergence_signature)`. Match primarily on `(file_path, line_range, L_code)` — `divergence_signature` is a tie-breaker only (LLM-generated Divergence text can drift in wording).
+- **`non_critical_round_counter`** (int, starts 0): rounds since the last prompt that produced ≥1 Warning or Suggestion. Incremented in 8d, reset to 0 only on user "continue" in 8e.
+- **`consecutive_continues`** (int, starts 0): number of times user answered "continue" at the escalation prompt. Never reset. Hard cap is 3.
+
+### 8b. Re-scan scope
+
+After Phase 7, re-run Phases 2–3 on: all files modified in Phase 7 + files in the same module + files that statically import from a modified file. Skip files whose dependencies were not touched.
+
+**Static-graph boundary:** reflection-based calls, string-dispatch, shared global state, and similar dynamic wiring can carry regressions beyond this scan. If the repo has a test suite, Phase 9 summary should recommend running it.
+
+### 8c. Classify each new finding
+
+- Matches `unresolvable_findings` → skip.
+- 🔴 Critical → add to Post-Fix Queue (loops until resolved, or until Phase 7d retires it to `unresolvable_findings` after 3 failed attempts).
+- 🟡 Warning / 🟢 Suggestion → add to Post-Fix Queue.
+
+Run Phases 6–7 on the Post-Fix Queue.
+
+### 8d. Round accounting
+
+- **Clean round** (no new findings outside `unresolvable_findings`) → proceed to Phase 9.
+- **Critical-only round** → do NOT increment `non_critical_round_counter`; return to 8b.
+- **Mixed or non-critical round** → increment `non_critical_round_counter`. If below cap, return to 8b. If at cap, go to 8e.
+
+### 8e. User escalation
+
+```
+Logic-Fix-All iteration cap reached.
+
+After {cap} non-critical rounds, N Warning and M Suggestion
+findings remain. No outstanding Critical findings
+(unresolvable Criticals, if any, are listed in the Fix Log).
+
+Continue for another {cap} rounds?  [Y/n]
+```
+
+When `consecutive_continues` is 1 or 2, append:
+```
+(You have continued {consecutive_continues} time(s) so far — hard
+cap is 3 continues per run. To run more rounds without repeated
+prompts, raise `fix_all.max_iterations` in `.logic-lens.yaml`.)
+```
+
+Parse reply using the same consent/negation rules as Phase 0b.
+- **Consent:** increment `consecutive_continues`. If now ≥ 3, hard stop — record remaining as "Unresolved — hard iteration ceiling reached (user continued 3×)" and go to Phase 9. Otherwise reset `non_critical_round_counter` to 0 and return to 8b.
+- **Negation (or non-consent):** record remaining as "Unresolved — user stopped iteration at round N" and go to Phase 9.
+
+---
+
+## Phase 9 — Final Report
+
+Use the Report Template from `report-template.md` with the Fix Report additions from `SKILL.md`. Include:
+
+- **Scope summary:** file count by role; Phase 1f truncation notice if applied.
+- **Skill invocation count:** health: N, review: N, locate: N, explain: N, diff: N.
+- **Iteration history:** round count by severity class; each cap escalation and user response.
+- **Findings by role:** separate sub-tables for source, config, constraint, doc.
+- **Resolved by clarification:** findings Phase 5 downgraded as false positives.
+
+Do not output per-finding Premises/Trace/Divergence blocks in the final report — the Fix Log table is the user-facing record. Provide full trace on request.
+
+### Logic Score computation
+
+- **Logic Score (before):** start at 100, deduct for every finding collected in Phases 3–5 (before fixes). Apply the per-L-code deduction cap from `common.md`.
+- **Logic Score (after):** start at 100, deduct only for findings still marked Unresolved after Phase 8.
+
+When before and after are numerically equal despite fixes (e.g., 3 L1 findings collapse to one −15 in both), the "Findings fixed" count is the authoritative improvement signal.