القائمة
Scaffold a new lens for this plugin. Use when /lens:retro proposed a lens, or a recurring theme has no lens. Takes a lens name (kebab-case) and a one-line purpose.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | new |
| description | Scaffold a new lens for this plugin. Use when /lens:retro proposed a lens, or a recurring theme has no lens. Takes a lens name (kebab-case) and a one-line purpose. |
Every lens — bundled or one you create — is used the same way: through
/lens:socratic, which discovers and applies it. Lenses you create are NOT separate
slash commands; only the bundled set has /lens:<name> shortcuts (a Claude Code
namespace limit, not a choice). So a new lens just needs a HOME + a registry row that
socratic reads. Draft the battery socratically first (step 3), then write it to the
chosen scope — no commit, no plugin rebuild, no reload; socratic reads it fresh.
Offer the SCOPE — but only the options that apply to the current context (never ask about "maintaining the plugin"; that option appears on its own, below, only when you detect you're inside the lens plugin repo):
<repo>/.lens/lenses/<name>/SKILL.md from the template (no surviving placeholders),
append the row to <repo>/.lens/registry.md (create if absent), and git-exclude
.lens/ via git rev-parse --git-path info/exclude (handles worktrees/submodules;
on failure PROPOSE a .gitignore entry — never silently edit it). To SHARE it with
the team, commit its SKILL.md to <repo>/.claude/skills/lens-<name>/ (Claude Code
loads that one natively as a slash command).<foundry>/lenses/<name>/SKILL.md and append the row to <foundry>/registry.md
(foundry from the config: $LENS_CONFIG → ~/.claude/lens.json → ~/lens/lens.json).
Lives in the foundry, outside the plugin — auto-updates never touch it. A global
lens that earns its keep can be PR'd into the bundled set../lens-proposal-<name>.md with a note on how to add it later, and point at /lens:setup.Maintainer path — auto-detected, never asked. Offer "into the bundled set" ONLY
when the current git repo IS the lens plugin itself — detect it: the repo root
(git rev-parse --show-toplevel) contains .claude-plugin/plugin.json whose name
is lens. That is the only signal; there is no pluginRepo config and no setup
question. If detected, the steps below apply (the plugin repo is the cwd's repo root).
Preconditions (in the plugin repo root): checkout on the default branch, clean tree. If not, stop and tell the user exactly what is off.
Name check: kebab-case; dir skills/<name>/ must not exist; name must not
collide with a registry row. Enforce lens agnosticism (core/protocol.md): reject
names coupled to a library or framework unless the lens's SUBJECT is that
technology — "design", not "shadcn-design"; "data-privacy", not "prisma-privacy".
Draft the battery socratically — interview the user briefly (protocol.md rules, one question at a time): what does this lens examine? what are its 2 framing questions? which contexts condition Tier 2? Target 8–12 questions total. If retro provided sample questions, start from those.
Scaffold: copy ${CLAUDE_PLUGIN_ROOT}/templates/lens-template/SKILL.md to
<plugin-root>/skills/<name>/SKILL.md, replacing every {{PLACEHOLDER}} with the
drafted content. No placeholder may survive — grep for {{ to verify.
Register: append the row to <plugin-root>/core/registry.md (type lens,
modes design, purpose, trigger signals). Remove the lens from the "Planned"
list if it was there.
Show the full diff (git -C <plugin-root> diff). On explicit approval only:
git -C <plugin-root> add skills/<name> core/registry.md
git -C <plugin-root> commit -m "feat(skill): lens:<name> (scaffolded via /lens:new)"
Offer to push. Never push unasked.
Remind: new skills load on next session (or /reload-plugins with --plugin-dir).
Use when starting any non-trivial feature, issue, or objective — BEFORE designing or coding — and again AFTER implementing, to audit it. Design mode runs iterative Socratic discovery (caveats, rabbit holes, blast radius), then plans and chains the right lenses. Audit mode re-runs the session's lens plan against the implemented code and verifies it against the dossier's recorded decisions. Trigger phrases - "let's build", "add feature", "how should we approach", "audit what we built", "review the implementation".
The Lens of Observability — Socratic battery over operational recovery and visibility for money flows, state machines, webhooks, and background jobs. Use for anything where a lost external event or a stalled multi-step flow can strand a user (payments, webhooks, onboarding funnels, queues, crons). Modes - design (questions to you) and audit (questions to the code).
The Lens of Security — Socratic question battery over sessions, auth, tokens, secrets, and authorization. Use for any feature touching login, tokens, payments, user data, webhooks, file uploads, or anything an attacker would love. Modes - design (questions to the user) and audit (questions to the code).
The memory loop. Use when closing significant work or weekly — processes queued lens sessions, mines them for patterns, proposes new lenses / lens updates / CLAUDE.md diffs, and writes approved observations to the foundry ledger. Also accepts an explicit transcript path or session_id as argument.
One-time setup of YOUR lens memory loop on Claude Code — your foundry where the SessionEnd hook queues lens sessions, /lens:retro mines them, and /lens:new grows your collection. Use when the user runs /lens:setup, or when a foundry-dependent skill (retro, new) finds no config. Claude Code only — the loop is not supported on Cowork.
The Lens of the Adversary — red-teams a PLAN before you commit to it. Tries to refute it, names the weakest decision and the unexamined assumption, re-checks the four excavations against the plan. Runs as the MANDATORY final step of /lens:socratic, or standalone (/lens:adversary) on any plan, diff, or design. A meta-lens — it critiques the plan, not a domain.