菜单
与用户共同阅读代码，逐层讲解架构与数据流。支持自底向上分层模式和调用链追踪模式。主动发现 dead code、设计偏差、迁移遗漏，但不修改代码。先建立全局视角再逐文件深入，阅读过程中可随时 zoom out 回到全景。Use when user wants to walkthrough code, understand architecture, trace call chains, review a module's structure, or says "过代码" / "walkthrough" / "walk me through" / "zoom out".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Comprehensive quality verification: spec compliance, lint, type-check, tests, cross-layer data flow, code reuse, and consistency checks. Use when code is written and needs quality verification, before committing changes, or to catch context drift during long sessions.
Discovers and injects project-specific coding guidelines from .trellis/spec/ before implementation begins. Reads spec indexes, pre-development checklists, and shared thinking guides for the target package. Use when starting a new coding task, before writing any code, switching to a different package, or needing to refresh project conventions and standards.
Guides collaborative requirements discovery before implementation. Creates task directory, seeds PRD, asks high-value questions one at a time, researches technical choices, and converges on MVP scope. Use when requirements are unclear, there are multiple valid approaches, or the user describes a new feature or complex task.
Guides collaborative requirements discovery before implementation. Creates task directory, seeds PRD, asks high-value questions one at a time, researches technical choices, and converges on MVP scope. Use when requirements are unclear, there are multiple valid approaches, or the user describes a new feature or complex task.
Deep bug analysis to break the fix-forget-repeat cycle. Analyzes root cause category, why fixes failed, prevention mechanisms, and captures knowledge into specs. Use after fixing a bug to prevent the same class of bugs.
Discovers and injects project-specific coding guidelines from .trellis/spec/ before implementation begins. Reads spec indexes, pre-development checklists, and shared thinking guides for the target package. Use when starting a new coding task, before writing any code, switching to a different package, or needing to refresh project conventions and standards.
| name | code-walkthrough |
| description | 与用户共同阅读代码，逐层讲解架构与数据流。支持自底向上分层模式和调用链追踪模式。主动发现 dead code、设计偏差、迁移遗漏，但不修改代码。先建立全局视角再逐文件深入，阅读过程中可随时 zoom out 回到全景。Use when user wants to walkthrough code, understand architecture, trace call chains, review a module's structure, or says "过代码" / "walkthrough" / "walk me through" / "zoom out". |
与用户共同阅读代码，逐文件讲解架构、数据流与设计决策。纯讲解 + 审查，不修改代码。
从数据实体开始，逐层向上经过 Repository → Service → Handler → Domain → Engine → Task。
适用场景：新接手模块、架构改造后全貌理解、PRD 实现 review。
层级顺序（按 DDD 四层架构）：
Layer 1: 数据实体 / 值对象（domain/entity/, domain/value_object/）
Layer 2: 仓储接口（domain/repository/）
Layer 3: 仓储实现（infrastructure/db/）
Layer 4: Application Service（application/service/）
Layer 5: Handler / API 层（handler/ 或 app/）
Layer 6: Domain 核心接口与模型（domain/ 核心类型）
Layer 7: Engine / 编排层（domain/engine/ 或 application/service/ 编排逻辑）
Layer 8: App 层适配器 / Helper（app/ 下的 adapter、helper）
Layer 9: 生产装配（bootstrap/）
Layer 10: 具体业务实现（task/、handler/ 具体实现）
每层只选 1-2 个代表性文件深入，不求全覆盖。用户可以随时跳过某层或深入某层。
从一个入口点出发，沿调用链逐函数深入。
适用场景：排查问题、理解某个具体流程、验证数据流正确性。
流程：
根据用户输入判断模式和范围：
| 用户输入 | 处理方式 |
|---|---|
| 指定目录/模块名（如 "workflow 资源审计"） | 模式 A，扫描目录结构确定层级 |
| 指定文件/类型名（如 "SaveALBTask"） | 先用 grep/find 推导上下游，用户选择模式 |
| 指定入口函数（如 "从 Engine.Execute 开始"） | 模式 B，沿调用链追踪 |
| 模糊描述（如 "过一下这块代码"） | 用 ask_user_question 确认范围和模式 |
范围推导：当用户只给了起点时：
fffind / grep 找到相关文件在逐文件阅读之前，先建立模块全景认知。 不知道全貌就不知道该看什么、以什么顺序看。
用 fffind / grep / ls 扫描目标模块的所有相关文件，识别：
用项目的领域词汇（而非泛化的技术词汇）绘制全景地图：
呈现格式：
workflow 资源审计模块全景（15 个文件）
├── domain/flow/ ← 审计声明模型（flow 包，不依赖 mife_cluster）
│ ├── resource_audit.go ResourceChange / Declaration / Writer 接口
│ ├── resource_audit_collector.go Collector（有变更 task 嵌入用）
│ ├── no_resource_change_audit.go NoResourceChangeAudit（无变更 task 嵌入用）
│ └── flow_task.go FlowTask 接口 + DeclareResourceAudit
│
├── domain/engine/ ← Engine 审计处理
│ ├── engine.go Engine 结构体 + writer 注入
│ └── task_executor.go processResourceAudit 核心逻辑
│
├── app/workflow/audit/ ← App 层适配器
│ ├── writer.go ResourceAuditWriter（flow → entity 转换）
│ └── resource_change.go AlbCreated / NodeCreated 等 helper
│
├── domain/resource_audit/ ← 持久化层
│ ├── entity/change_record.go ResourceChangeRecord 实体
│ ├── repository/audit_repository.go AuditRepository 接口
│ └── infrastructure/db/ GORM 实现
│
└── bootstrap/ ← 生产装配
└── register_admin_workflows.go deps 注册 + writer 注入
数据流方向：task → collector → Engine → writer → service → repository → DB
关键要求：
展示全景地图后，向用户确认：
用户确认后进入 Phase 3。
对阅读清单中的每个文件，执行以下步骤：
用 read 工具完整读取目标文件。如果文件超过 200 行，分段读取但保持讲解连贯。
每个文件讲解以下内容（按需，不求全覆盖）：
结构梳理：
关键设计：
具体引用：
文件路径:行号 格式引用阅读过程中主动检查以下问题：
| 检查项 | 说明 |
|---|---|
| Dead code | 没有调用方的函数/方法/类型 |
| 设计偏差 | 实现与文档/PRD 描述不一致 |
| 迁移遗漏 | 接口变更后未同步更新的实现 |
| 边界缺失 | 缺少 nil 检查、空值处理、错误传播 |
| 层级违规 | 上层依赖下层的反向依赖、跨层直接访问 |
| 重复逻辑 | 多处存在相似代码应提取为共享函数 |
发现问题时：
每个文件讲完后：
在逐文件阅读过程中，用户可以随时要求回到全局视角（如说 "zoom out"、"往上拉一层"、"给我个全景"），或者在以下时机自动触发：
执行方式：用最新的已读状态重新绘制 Phase 2 的模块地图（✅ 标记已读文件），问用户："要继续逐文件深入，还是先看看其他层？"
每过完一个 DDD 层级后，做一个简要总结：
所有文件过完后，输出完整总结：
## 代码地图
### 分层结构
[按层级列出所有文件及其职责]
### 数据流
[从入口到出口的完整调用链，标注文件:行号]
### 设计决策
[关键决策及其权衡]
### 发现的问题
[按严重程度排列的问题列表]
- Dead code: [文件:行号]
- 设计偏差: [描述]
- 迁移遗漏: [描述]
### 待确认项
[阅读过程中未解决的开放问题]
文件路径:行号