| name | cc-diff |
| description | Use when 用户明确要求对齐 Claude Code(cc)与当前仓库某功能点实现,并需要基于源码做精细差异分析而非直接改代码。 |
CC Diff
Overview
把“我要对齐 cc 的某个功能”变成源码驱动的差异分析:输入功能点,读取 claude-code-haha 与 ys-code 双边实现,输出可执行的对齐差异清单。
本 skill 只做分析和建议,不直接修改代码。
When to Use
- 用户显式提出:对齐
claude-code-haha / Claude Code 实现
- 用户给出功能点:如
agent loop、compact、edit tool
- 需要“精确到细节”的设计与实现差异证据
When NOT to use:
- 纯重构、纯修 bug(未要求 cc 对齐)
- 需要直接产出 patch 并修改代码
- 纯性能 benchmark 任务
The Process
一旦用户给出功能点,直接执行,不要再次请求“确认后开始”。
Scope → Read CC → Read YS → Compare → Gate Evidence → Recommend
Step 1: Scope the Feature
把功能点拆成四个子域:
- 入口:命令、工具、API 或调用入口
- 核心:主流程、关键分支、数据结构
- 状态:内存状态、持久化、恢复
- 异常:错误路径、重试、回滚、降级
任一子域缺失,最终结论必须标为“局部对比”。
Step 2: Read Both Sides
先读 cc,再读 ys,并使用同一子域映射:
- CC:优先
refer/claude-code-haha,先主路径,再边界路径
- YS:优先
src/,按 CC 子域寻找对应实现
- 不要只看一侧代码后推断另一侧
Step 3: Compare by Layer
按顺序比较:
Design:职责、边界、生命周期、策略选择
Implementation:调用链、函数签名、数据结构、关键分支
Behavior:成功路径、失败路径、边界条件、恢复策略
实现不同但运行语义等价时,标记为“实现差异(非行为差异)”。
Step 4: Gate Evidence
每条关键结论必须有:
- 1 条 cc 证据:文件/符号/关键片段
- 1 条 ys 证据:文件/符号/关键片段
缺任一侧证据,不得写成确定事实;标记为“待确认”或“局部对比”。
Output Contract
最终回复必须包含 5 个标题,顺序固定:
Design Diff
Implementation Diff
Behavior Diff
Alignment Gaps
Prioritized Recommendations
Alignment Gaps 使用差异矩阵:
| Layer | CC Evidence | YS Evidence | Gap | Impact | Priority | Confidence |
|---|---|---|---|---|---|---|
| Design | ... | ... | ... | ... | P1 | High |
Prioritized Recommendations 必须按 P0 → P1 → P2 排序:
- P0: <必须优先对齐的项>
- Why: <不修会导致的风险>
- Scope: <涉及模块/路径>
- Verify: <如何验证对齐生效>
Recommendation rules:
- 至少 3 条建议
- 至少包含 1 条
P0 和 1 条 P1
- 每条必须包含
Why/Scope/Verify
- 每条必须可追溯到
Alignment Gaps 的证据
- 不输出自动改码或 patch
Priority
P0:不对齐会导致错误行为、稳定性风险、安全风险或关键能力缺失
P1:对齐后显著提升一致性、恢复能力、可维护性或调试能力
P2:增强项、体验项、可观测性或长期一致性优化
Verification
输出前自检。不要默认把这份 checklist 作为报告章节输出;只有用户要求或存在缺失项时才说明。
Red Flags
- 只看一侧代码就下结论
- 只比 happy path,不比错误路径
- 用“看起来像”替代证据
- 把推测写成确定事实
- 用户给了功能点后仍要求“确认后开始”
- 没有 P0/P1 推荐建议
- 建议脱离证据,变成泛泛方向口号