HWYD AI Mind Implementation Reader
定位
只服务于 AI Mind 项目内部的“版本实施代码阅读”。当用户想在某个版本、Step 或功能实现完成后快速读懂真实代码如何跑起来时，使用本 Skill。
只解决四件事：
- 给出版本实施修改代码的阅读顺序。
- 讲解关键文件 / 函数。
- 梳理主执行流程。
- 用大白话解释实现。
默认不做
默认不要做以下事情：
- 不做 code review。
- 不提重构建议。
- 不修改代码。
- 不写测试。
- 不写博客。
- 不整理面试话术。
- 不做 Spec / Plan / Tasks 差异分析。
- 不做完整架构评审。
- 不扫描整个仓库。
- 不扩大成通用项目 Skill。
如果用户明确要求 code review、博客、面试话术、重构建议或 Spec 差异分析，说明这已经超出本 Skill 默认范围，并按用户的新任务另行处理。
信息来源优先级
真实代码是最高优先级。按以下顺序建立事实：
git diff- changed files
- 实际源码
- 当前分支最近提交
- specs、plans、tasks、docs、version notes
Specs、plans、tasks、docs、version notes 只能作为辅助背景，不能替代真实代码。不要脑补不存在的文件、函数、类型、执行流程或架构决策。
如果任务涉及“版本实现”或“某个 Step 实现”，必须定位并阅读 specs/<version>/spec.md。先用它确认该版本的目标、非目标、能力边界和关键术语，再回到真实代码梳理实现主线。
如果已经知道当前版本或 Step，优先补读与之对应的 specs/<version>/tasks.md；它只用于帮助判断这次实现大致覆盖了哪一段能力，不替代真实代码阅读。
默认执行步骤
当用户没有指定版本范围时，先轻量查看本次实现概况：
git status --short
git diff --stat
git diff --name-only
git log --oneline -n 5
根据变更文件判断本次实现涉及哪些模块。不要默认深读所有文件，只挑出能解释主流程的关键文件。
如果用户指定了版本、Step、commit、分支、PR、文件列表或 diff，以用户指定范围为准；仍然优先回到真实代码确认。
如果确认这是一轮版本实现阅读，默认步骤改为：
- 先定位版本范围。
- 先读
specs/<version>/spec.md。 - 再看
git diff、changed files、最近提交和实际源码。 - 最后抽出 5 到 8 个关键文件组织阅读顺序。
文件选择规则
只选择对理解主流程有价值的关键文件，不要因为某个文件发生变更就机械列入阅读顺序。
优先选择：
- 用户入口：页面、命令入口、API route。
- 后端执行路径：runtime、graph、manager、orchestrator、service。
- 核心契约：types、schema、runtime artifact、stream chunk、state model。
- Tool / Agent 实现：tool runtime、sub-agent、controlled loop、agent definition。
- 前端消费：reducer、renderer、panel、status component。
- 持久化：Prisma schema、database access、checkpointer、memory state。
- 测试或文档：只有在它们能帮助理解实现时才阅读。
阅读顺序规则
阅读顺序从“入口”到“执行”再到“展示”。优先按 AI Mind 常见链路组织：
用户操作 / 页面 / 命令
-> API route
-> runtime / graph / manager / orchestrator
-> tool / agent / service
-> type / state / protocol
-> stream / artifact output
-> frontend reducer / renderer / panel
-> persistence if involved
每个关键文件都要说明：
- 为什么它排在这个阅读位置。
- 它在主流程里负责什么。
- 阅读时重点看什么。
阅读方法
先用轻量命令确认变更面，再沿主链路打开少量关键文件。通常控制在 5 到 8 个关键文件以内；如果实现很小，可以更少。
阅读关键文件时，优先找：
- 对外入口函数、route handler、页面事件、命令处理器。
- Runtime 推进状态的函数。
- Tool / Agent / service 被调用的位置。
- 状态、协议、stream chunk 或 artifact 的类型定义。
- 前端如何消费后端输出并展示。
- 持久化如何读写状态；没有涉及持久化就不要展开。
测试文件只在能帮助理解“这条链路期望怎么跑”时阅读；不要把测试覆盖情况扩展成 review。
输出要求
始终使用中文输出。表达要具体、实用、直接，不要写泛泛的框架教程。除非理解当前实现必须用到，否则不要展开讲 React、Next.js、LangGraph、Prisma 等通用概念。
每次使用本 Skill 时，按以下格式输出：
# 实现代码阅读指南：<版本或功能名称>
## 1. 建议阅读顺序
| 顺序 | 文件 | 为什么先读它 | 重点看什么 |
| ---- | ---- | ------------ | ---------- |
只列关键文件，不要列所有变更文件。
## 2. 关键文件 / 函数讲解
针对每个关键文件或函数，说明：
- 位置
- 作用
- 它在主流程中的位置
- 重点阅读点
- 大白话解释
## 3. 主执行流程
用清晰的步骤串起来：
用户操作
↓
前端入口
↓
API route
↓
runtime / graph / manager
↓
核心状态 / 协议
↓
stream / artifact
↓
前端展示 / 持久化
## 4. 大白话解释
讲清楚：
- 这个版本把什么能力串起来了
- 请求 / 数据 / 状态是怎么流动的
- 哪些文件是主线
- 哪些文件只是辅助
- 这次实现最核心的代码理解点是什么
## 5. 未确认点
只有在确实无法从仓库确认时才输出这一节。不要猜。
质量要求
一次好的输出应该让用户能回答：
- 这次版本应该先读哪些代码？
- 每个关键文件为什么重要？
- 核心函数分别做什么？
- 用户操作之后，代码执行链路怎么走？
- 用大白话说，这次实现到底是怎么实现的？
强约束
- 保持结果聚焦。
- 不要扩展到 review、重构、博客、面试或架构分析。
- 不要输出无价值的完整文件列表。
- 不要脑补代码里没有的实现。
- 不要过度解释无关框架概念。
- 优先用最少的关键文件讲清楚实现主线。
- 如果实现路径不清楚，明确说明哪里不清楚，以及下一步应该检查哪个文件。