Run any Skill in Manus with one click

logic-explain

Stars11

Forks1

UpdatedMay 7, 2026 at 14:14

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 this", "trace through X with input Y", "why does this return X", "what does yield-from do here", "explain the execution path". SCOPE HARD RULE: a specific function + a specific input scenario. If the user wants to find bugs without a scenario in mind, use logic-review; two-version comparison uses logic-diff; concrete failures use logic-locate; codebase-wide audit uses logic-health. Do NOT trigger for: finding bugs without a behavioral question, style or design discussion, or concept explanations not tied to specific code.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

hyhmrright

hyhmrright/logic-lens

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name

logic-explain

description

Logic-Lens — Execution Explain

Setup

Use lazy loading per ../_shared/common.md §13:

Read ../_shared/common.md only for language, report header variants, scope routing, and loading budget.
Read only the relevant step in logic-explain-guide.md as you reach it.
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.

More from this repository

same repository

iterate-skill

hyhmrright/logic-lens

Run the Logic-Lens skill-improvement loop end to end — baseline → diagnose failures → edit → sync cache → re-eval → verify net gain → iterate until clean. Use whenever the goal is to RAISE a skill's eval score or fix a failing eval mode: "improve logic-review", "the format compliance is failing, fix it", "iterate on this skill until the evals pass", "raise the score", "re-run the loop on the latest failures", "run another iteration", "tune the skill description / disambiguation table against the evals". Also use to RESUME a prior loop ("continue improving from where we left off", "do another pass", "iterate further"). Do NOT use for: a one-off question about a skill, shipping a release (use bump-version), or scaffolding a brand-new skill (use new-skill).

2026-06-0111

run-iteration-eval

hyhmrright/logic-lens

Run the Logic-Lens content-eval pipeline for one iteration and produce a scored summary.json — use to measure a skill change. Wraps scripts/run-content-evals.sh (runner, costs tokens) and scripts/grade-iteration.py (grader, free, re-runnable). ALWAYS sync the plugin cache first. Use when the user wants to "run the evals", "score this iteration", "measure the skill change", "smoke-test before the full run", or "re-grade existing outputs".

2026-06-0111

sync-skill-cache

hyhmrright/logic-lens

Sync the Logic-Lens working-copy skills/ into the installed plugin cache so content-evals test the EDITED skill, not the last published one. ALWAYS run this after editing any skills/**/SKILL.md or guide/_shared file and BEFORE running content-evals — otherwise the eval silently grades stale content and every token is wasted. Also use to verify the cache is in sync ("is the cache fresh?", "did my edit take effect in evals?", "check skill cache drift").

2026-06-0111

logic-review

hyhmrright/logic-lens

Find logic bugs in a single file or function via semi-formal execution tracing (Premises → Trace → Divergence → Trigger → Remedy). Trigger when a user shares code and suspects something is wrong without naming a concrete failure — phrases like "review this", "does this look right", "check this function", "audit this code", "tests pass but prod fails". SCOPE HARD RULE: one file or one function only. For a directory or whole module use logic-health; for a confirmed failure (stack trace, failing test, specific wrong value) use logic-locate; for two versions use logic-diff; for repo-wide autonomous fixing use logic-fix-all. Do NOT trigger for: style/formatting, security scanning, performance, test generation, architecture or design questions.

2026-05-3011

bump-version

hyhmrright/logic-lens

Bump the Logic-Lens version across all six metadata locations at once (package.json, the four plugin manifests, and the README badge), then validate. Use when cutting a release or when `npm run validate` reports a version mismatch.

2026-05-2811

new-skill

hyhmrright/logic-lens

Scaffold a new logic-* skill in the Logic-Lens repo and wire it into every place a skill must be registered, so no step is missed. Use when adding a seventh (or later) skill to Logic-Lens.

2026-05-2811

name

logic-explain

description

Logic-Lens — Execution Explain

Setup

Use lazy loading per ../_shared/common.md §13:

Read ../_shared/common.md only for language, report header variants, scope routing, and loading budget.
Read only the relevant step in logic-explain-guide.md as you reach it.
Load ../_shared/semiformal-guide.md, ../_shared/semiformal-checklist.md, and ../_shared/report-template.md on demand when the current step needs them.

Process

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 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.