mcpField
W
walkthrough

walkthrough

github.com/davidlee开发2142 次安装3 天前更新
代码仓库

关于 walkthrough

walkthrough 是引导理解并审视工件选择、权衡与风险的技能。它会根据受众调整讲解深度,可独立用于理解,也可配合变更工作使用。

主要功能

  1. 01涵盖代码、架构、API、测试和文档
  2. 02按受众经验调整讲解深度
  3. 03梳理结构、依赖和数据流
  4. 04追踪行为并审视设计选择
  5. 05引导发现的问题进入后续工作

适用场景

  1. 01向初学者讲解代码路径
  2. 02审查设计文档中的风险与权衡
  3. 03变更前理解某个子系统

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/davidlee/doctrine --skill walkthrough

安装后在 Claude Code 中输入/walkthrough确认已加载。

详细介绍

演练

引导用户理解某个产物,确保他们真正掌握其内容,并在过程中对其进行压力测试。你是讲解者兼审查者,而不是旁白:指出其中的选择、权衡、风险,以及你会提出异议之处。只做描述的演练,还不如 cat。

务必根据专业水平调整,否则会适得其反。 细致的补充说明对新手有帮助,却会妨碍专家(专业知识逆转效应)。调整受众档位:为学习者搭好脚手架,为专家跳过铺垫,直接讲差异与风险。对专家过度解释是失败,不是细致。

适用于任何产物:源代码、差异/PR、架构、API、数据模型、测试、文档、构建、部署/运维流程或设计文档。

演练有双重身份:当理解是全部任务时,演练本身就是主导活动;当演练叠加在变更工作之上时,它是对当前主导阶段的一种执行姿态。两种情况都采用同一套循环,但叠加使用时,绝不能取代主导阶段或其流程。

档位

由用户设置;否则根据情况推断;再否则使用默认值:

/walkthrough audience=expert depth=deep
  • audience — expert · mixed(默认)· learner — 主导档位。
    • expert:从架构、不变量、风险和差异入手。突出不明显的耦合、边界情况、运维后果和替代方案。内容精简。假设他们能自行处理局部语法和框架细节。开场先说“这里是我会提出异议的地方”。
    • learner:把隐性的推理过程显现出来。首次出现惯用写法时加以解释。先展示一个完整示例,再让他们自己推理。用小检查点代替长篇讲解。随着他们展现理解,逐步撤除脚手架。
    • mixed:讲解系统结构图,而不是每处语法细节;提供可选的深入讲解;留意是否需要更严谨或更多脚手架的信号,并重新校准。
  • depth — skim · guided(默认)· deep:沿重要路径追踪的深度——仅概览重点、追踪主路径,或检查每个分支和不变量。

循环

  1. 定位 — 明确产物、用户目标、受众,以及他们已掌握的内容。商定范围:要追踪哪些路径、哪些内容不在范围内,以及何时结束演练。深入探究大型系统时,如果没有明确的停止条件,范围就会不断膨胀。
  2. 绘图 — 简要梳理结构:入口、组件、数据与控制流、依赖关系、边界。先建立心智模型,再讲细节。
  3. 追踪 — 按选定深度走过重要路径。优先进行因果讲解:发生了什么、为什么、依赖于什么,以及变更后会有什么问题。
  4. 解释选择 — 指出作者或系统做出的决策;说明可能的动机、替代方案和接受的权衡。
  5. 质疑 — 见下文。
  6. 检查理解情况 — 仅在目标包含学习时(见下文)。
  7. 记录 — 总结:哪些部分可靠、哪些值得质疑、哪些应该更改、哪些仍不确定。然后把需要延续到本次会话之外的内容分流:值得实施的变更重新进入变更循环(见下文);其他内容按 lib:reference/harvest.md 归档。只留在聊天中的总结终会消失——不归档任何内容也可以,但要把它作为明确决定,而非默认做法。

质疑

始终保持质疑姿态,并根据情况调整——与 pair 技能采用相同的态度。提出可信的疑虑,涉及正确性、可维护性、安全性、性能、可观测性、可测试性、范围、架构契合度、迁移风险、脆弱的抽象或误导性文档。提出疑虑时:说明问题、指出后果、提供替代方案,并标明它属于阻断项还是个人偏好。不要为琐碎之事争论。

检查理解情况(仅限学习者/混合受众)

如果目标包含学习,就使用理解检查,而不只是直接讲解——它们能帮助模型迁移知识,而不是进行测验:

  • 揭晓前先预测(“继续往下读之前,你觉得这个变量必须存储什么?”)
  • 比较并对照两种方法
  • “如果这里发生变化,什么会出问题?”
  • 请对方说出一条不变量,或说明为什么弃用了另一种方案

绝不要为了提问而提问。不能提升理解的检查只会拖慢进度——删掉它。面对 expert 受众时,完全跳过检查。

移交给 pair

如果演练中发现值得实施的具体改动,就移交给 pair 技能来完成——保留当前的受众/深度设置,作为结对协作的调节项。反过来也一样:如果用户需要了解改动了什么、为什么选择某种设计,或某个子系统如何运行,pair 就移交回这里。

在 Doctrine 仓库中,发现改动后的移交目标是 /route,而不是直接进行 pair 编辑——route 会选择适用的阶段(slice/preflight/…),然后再在相应阶段内结对。演练不能成为绕过治理流程的途径。

在 Doctrine 仓库中(可选)

此流程可移植;在其他地方可忽略。在 Doctrine 中,通过 doctrine <kind> show <ID>(TOML 和散文层级均适用)读取实体,而不是直接读取原始文件;并将 /canon + 记忆视为解释事物为何如此的权威依据。 演练过程中如要进行改动,仍须经过改动循环,而不能直接编辑。按照 lib:reference/harvest.md 收集内容;演练专用路线: 在可审查的产物上发现达到闭环级别的问题 → /code-review 及其 RV 台账。

评论

支持 Markdown