用途：读取一个产物（代码 diff、规格说明或实施计划），通过提问检验用户是否真正理解它，而不是由工具替用户解释。核心是主动回忆，目标是在问题变成 bug 或错误实现前暴露理解缺口。
来源模式：代码模式（默认）读取 git 改动，默认用 git diff HEAD（含暂存与未暂存）；说“last commit”或“previous commit”时用 git diff HEAD~1 HEAD；指定 SHA 时用 git diff <sha>~1 <sha>；说“last N commits”时用 git diff HEAD~N HEAD；PR 编号则通过 gh MCP/插件处理。规格模式在用户提到 spec、design doc 或“实现之前”时触发，读取指定路径，或查找 docs/superpowers/specs/ 中最近的文件，问题聚焦数据模型决策、接口契约、范围边界与约束。计划模式在用户提到 plan、实施计划或“架构决策”时触发，读取指定计划文件或 docs/superpowers/plans/ 中的近期文件，问题聚焦为何选此方案而非替代方案、步骤顺序、阶段间依赖与风险。若无法判断，先问用户要对哪个产物测验。
使用方式：先询问测验偏好。A）一次一题，用户回答后即时反馈再继续（推荐，默认）。B）一次性给出全部题目，用户答完后统一评分。未表达偏好时按一次一题（苏格拉底式）进行。随后生成 5–7 道需要思考而非照抄产物的题目；代码 diff 关注为何选此方案、删除某行会发生什么、空值或异常输入、迁移对现有数据的影响、对系统其他部分的影响；规格关注设计决策取舍、提供者协议契约、范围外内容、约束被违反的后果、组件通信方式；计划关注阶段边界、架构决策取舍、步骤依赖能否调换、最冒险假设、外部依赖缺失时先坏什么。题目深度随产物规模调整。
评分与语气：正确指理解“为什么”而非仅“是什么”，遗漏关键细节给部分分，回答含糊时要求具体化。答错用一两句纠正后继续，不长篇说教。语气为严厉但支持性的资深开发者。
限制：资料未提供该技能的安装命令、价格、平台支持范围或与其他工具的集成细节；其效果取决于所读取的代码、规格或计划内容与用户回答的真实性。