📦 deps(thirdparty): update snapshots

antigravity-awesome-skills/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.

antigravity-awesome-skills/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.