القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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).
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".
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").
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.
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.
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 these equivalent", "semantically equivalent", "are these two implementations semantically equivalent", "check my refactor", "same behavior after the change?", "does my rewrite produce the same output", "switched from X to Y — same results?". SCOPE HARD RULE: requires two code versions (A and B). A single version for bug-finding uses logic-review; one version + a failing test uses logic-locate; explaining what one piece of code does uses logic-explain; codebase audit uses logic-health. Do NOT trigger for: single-version review, performance comparison, design-quality comparison, or "which is better-written" questions.
| name | new-skill |
| description | 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. |
| disable-model-invocation | true |
CLAUDE.md → "Adding a New Skill" is the authoritative checklist. This skill exists to make sure every step actually runs — the session-start loop and the eval cases are the ones most often forgotten.
Read CLAUDE.md's "Adding a New Skill" section now, then execute its steps for logic-<NAME> (ask the user for <NAME> if not in $ARGUMENTS):
skills/logic-<NAME>/SKILL.md — copy the frontmatter shape from skills/logic-review/SKILL.md (name + description). The description MUST include a "Do NOT trigger for:" clause and a "SCOPE … RULE" line distinguishing it from the other skills. Process section = 5–7 numbered items, each citing a guide step. Follow lazy-loading per skills/_shared/common.md §13.skills/logic-<NAME>/logic-<NAME>-guide.md — numbered steps (Step 1, 2, …), each explaining the why, concrete examples over abstractions.commands/logic-<NAME>.md — mirror commands/logic-review.md:
---
description: <one line>
allowed-tools: Skill
---
Use the Skill tool to invoke `logic-lens:logic-<NAME>`, then follow its instructions exactly. $ARGUMENTS
hooks/session-start (CLAUDE.md step 6 — easy to miss) — add logic-<NAME> to BOTH the for skill in … loop and the printed skill list:
grep -n "for skill in" hooks/session-start
evals/content/v2/evals-v2.json. Trigger cases under evals/trigger/v2/ are optional and only catch description regressions (positive cases always score 0% — see CLAUDE.md → Gotchas).gemini-extension.json — CLAUDE.md says Gemini auto-discovers from skills/, but the file also enumerates each skill+command under contribution. If you want that list complete, add logic-<NAME> entries to both contribution.skills and contribution.commands. (Not checked by validate-repo.sh.)npm run validate and confirm all checks pass.