Add cc-switch-dev-workflow skill
这个提交包含在:
@@ -0,0 +1,68 @@
|
||||
# Foundation: Refactoring And Gap Closure
|
||||
|
||||
## Purpose
|
||||
把 `Code -> Alignment -> Refinement` 之间的关系讲清楚,防止团队把重构当成末尾装饰,把 Gap 当成补锅动作。
|
||||
|
||||
## When to Use
|
||||
- 在实现阶段安排检查点时
|
||||
- 在对齐阶段判断要补什么、不该补什么时
|
||||
- 在准备验收前决定优化层级时
|
||||
|
||||
## Inputs
|
||||
- `SPECS/*.md`
|
||||
- 实现代码
|
||||
- 测试结果
|
||||
- 最近变更范围
|
||||
|
||||
## Outputs
|
||||
- Gap 分类结果
|
||||
- 重构批次
|
||||
- 优化层级选择
|
||||
|
||||
## Primary Agent/Model
|
||||
`GPT-5.4 Pro xhigh`
|
||||
|
||||
## Secondary Agent/Model
|
||||
`Claude Opus 4.6`
|
||||
|
||||
## Required Skills
|
||||
- `spec-gap-tasking`
|
||||
- `code-simplifying`
|
||||
- `code-refactoring`
|
||||
- `architecture-audit`
|
||||
|
||||
## Steps
|
||||
1. 先比对 Spec 和实现,分类缺口。
|
||||
2. 缺口补齐后立刻做简化,避免把新增复杂度直接沉积下来。
|
||||
3. 每完成一批类别,做一次增量重构。
|
||||
4. 所有功能补齐后,再做全局简化、重构、必要时模块化与结构重组。
|
||||
|
||||
## Exit Criteria
|
||||
- 已知缺口有计划、有实施、有验证
|
||||
- 重构不再是“以后再说”,而是节奏化动作
|
||||
- 优化层级与项目目标匹配
|
||||
|
||||
## Failure Recovery
|
||||
- 若对齐阶段开始大规模重写无关代码,回到缺口范围定义
|
||||
- 若重构修改了行为,回到最近稳定计划和测试
|
||||
|
||||
## Related Templates
|
||||
- [`../templates/tdd-plan-template.md`](../templates/tdd-plan-template.md)
|
||||
- [`../templates/todo-yaml-template.md`](../templates/todo-yaml-template.md)
|
||||
|
||||
## Gap Types
|
||||
- `Missing`
|
||||
- `Partial`
|
||||
- `Divergent`
|
||||
- `Untested`
|
||||
- `Integration`
|
||||
|
||||
## Refactor Rhythm
|
||||
- 实施后立即 `Simplify`
|
||||
- 每 4 个类别做一次 `Refactor`
|
||||
- 全库阶段做 `Architecture Audit`
|
||||
|
||||
## What Not To Do
|
||||
- 不要在缺口分析前先写修复代码
|
||||
- 不要把“代码更优雅”当成偏离 Spec 的理由
|
||||
- 不要把 `Refinement` 用来掩盖前面没有对齐好的问题
|
||||
在新工单中引用
屏蔽一个用户