菜单
Inspect the codebase, infer behaviour and constraints, then resolve planning decisions that code cannot answer. Use when planning and inspection alone is insufficient to produce an implementation-ready plan.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/lhohan/agentfiles --skill interrogate-plan命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, or when another skill needs to maintain the domain model.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
A relentless interview to sharpen a plan or design, producing domain documentation as the conversation progresses.
基于 SOC 职业分类
正在显示 SKILL.md
| name | interrogate-plan |
| description | Inspect the codebase, infer behaviour and constraints, then resolve planning decisions that code cannot answer. Use when planning and inspection alone is insufficient to produce an implementation-ready plan. |
Read the relevant parts of the codebase before asking any question. Infer as much as possible from code, tests, configuration, and documentation.
When the user arrives with a pre-baked solution ("add X to Y", "just do Z"), treat it as a hypothesis. Before enumerating decisions, validate intent: ask whether the proposed change captures the full problem or only a partial solution, and whether unstated requirements exist. Do not proceed to write-implementation-plan until the true requirements boundary is clear.
After inspection, list:
A semantic decision is live when different choices would materially change behaviour, implementation, or documentation truthfulness.
Treat code, tests, config, and docs as already-made decisions unless they conflict, appear incomplete, or depend on context that cannot be safely inferred.
This is the dominant operating mode. Walk unresolved branches sequentially.
Never batch questions. Never ask a downstream question while an upstream ambiguity remains. Resolve or accept each decision before moving to the next.
For each question:
If the user's answer is vague, reject it by narrowing: call out what remains ambiguous and ask a sharper follow-up.
Continue until every live semantic decision is resolved by repository evidence, an explicit user answer, or an explicit user acceptance of an assumption or risk.
If you believe no questions are needed, state why every material branch is already resolved by repository evidence or explicit task text. Do not proceed past this point if any live decision remains unresolved.
Do not ask generic discovery questions when the answer can be inferred from inspection. Do not use the user as a substitute for codebase analysis.
Typical reasons to ask:
Before writing the plan, summarise:
Produce a plan complete enough to implement safely: every material decision inferred from the codebase, confirmed with the user, or explicitly accepted by the user as an assumption or risk.
Residual unknowns may be recorded as assumptions or risks only when inspection shows they are local, reversible, non-user-visible, and unlikely to affect behaviour, implementation direction, compatibility, migration, data integrity, security, or documentation truthfulness.
If a risk depends on product intent, business policy, user expectations, or future maintenance preferences, ask the user rather than classifying it as low-risk yourself.
Stop questioning once no material semantic decisions remain live and any remaining unknowns are low-risk by the criteria above. Do not re-confirm decisions the user has already accepted.