菜单
Map the user's relevant unknown unknowns for a task before planning, then help them sharpen the request. Use when the user asks for a "blindspot pass", says they know little about the area they're about to change, or wants to find out what they don't know before prompting or planning.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Bootstrap and manage the personal .lightbridge namespace — per-project config at ~/.lightbridge/projects/<project-key>/config.toml (docs-index, repo-links, research, plans, …) and the rest of the user-level ~/.lightbridge/ tree (handoffs, plans, repos.toml). Use when setting up lightbridge config for a repo, enabling or adding a config section, asking what .lightbridge supports, wiring a new config feature, or locating user-level lightbridge state.
Explain an existing agentic system — a codebase where an AI agent is the central "CPU" surrounded by agent-native organs (reasoning loop, memory, context, tools, skills, MCP, subagents, hooks) — or design one from requirements. Covers agent runtimes/harnesses and capability/steering packs. Use when the user invokes it by name (`agentic-architecture`) or near-match.
The agent-experience ("AX") lens for any interface an AI agent drives — a CLI, MCP server, HTTP/REST API, or library/SDK. Judge an existing surface against the AX principles and prescribe prioritized fixes, or apply the principles while designing a new agent-facing surface. For a descriptive whole-surface doc across all audiences (end user / developer / agent), use `surface-architecture` instead. Use when the user invokes it by name (`ax-interface`) or near-match ("AX analysis", "agent experience of …", "agent-friendly interface").
The reconciliation pass between a settled design and the first line of code. Read the design docs, hunt the places they disagree with each other and with the chosen framework, then compile the object model that must satisfy all of them at once — turning prose rules into machine-checked invariants and amending upstream docs it contradicts. Use when design is settled and you are about to build, or when the user invokes it by name (`codebase-blueprint`) or near-match.
Explain an existing codebase's data architecture — where data rests (stores, schema) and how it moves (dataflow, lineage) — or design one from requirements. One Markdown doc with Mermaid diagrams. Use when the user invokes it by name (`data-architecture`) or near-match.
Decompose a function, method, class, or module of an existing codebase into a runnable notebook that explains it top-down — each piece executed on concrete inputs with real output shown inline. Use when the user invokes it by name (`explain-as-notebook`) or near-match mentioning.
| name | blindspot-pass |
| description | Map the user's relevant unknown unknowns for a task before planning, then help them sharpen the request. Use when the user asks for a "blindspot pass", says they know little about the area they're about to change, or wants to find out what they don't know before prompting or planning. |
| metadata | {"version":"2026-07-08"} |
I'm about to work in territory I don't know well. Do a pre-work reconnaissance pass: map my relevant unknown unknowns — not a general codebase tour, only what would change my approach or my prompt.
Explore the target area first; ground every finding in what's actually there, not in what's typical.
Deliver three things:
This is a framing pass — not a plan, not an implementation. Deliver the three outputs and stop; don't start building.
Natural order: blindspot pass → plan mode → grilling. A blindspot pass earns me the right to have a plan; grilling stress-tests the plan I have.
