---
name: cs-clean-code
description: "整理代码、重构、审查实现、修复已定位问题或同步开发文档时使用。聚焦需求与业务行为、最小修改和本地验证；Git 或部署收尾由 cs-ending-time 处理。"
---

<!-- CS Skills · 陈硕 | https://github.com/ChenShuo2004/cs-skills -->

# CS Clean Code

让实现符合需求，降低维护成本。保留现有框架、公共接口与用户改动；不为风格一致重写可用模块。

## 先定位再修改

读取拥有该行为的代码、相关项目指令、测试和错误证据。Bug 先复现或找到可追溯的失败路径，再解释原因和最小修复。

明确请求是审查还是修改：只要求 review 时给发现，不自动修复；要求整理、修复时直接执行。可推断的命名、目录和实现细节自行决定。

## 按风险选择工作量

- 小范围重命名、删重复、文案或注释调整：直接修改并检查 diff，不强制计划卡或新增测试。
- 行为修改：从输入、状态变化到输出追踪一条业务路径，覆盖本次缺陷与相关失败条件；复用已有测试。
- 跨模块重构、迁移或多项验收：用简短诊断记录说明原因、影响范围、接口约束和验证方案。需要时参考 [review checklist](references/review-checklist.md)。

公共接口变化若已在用户要求内，继续实现兼容或迁移方案；只有会超出约定范围、损失用户数据或破坏他人工作且无法隔离时才需要决定。请求确认之前先完成不依赖该决定的工作。

## 修改与验证

沿用现有组件和依赖。修复真正拥有逻辑的模块；更新因本次行为变化失效的文档、命令或示例，不写无关历史说明。

每个行为修改保留“需求 → 修改 → 验证”的证据，可以是一段说明，不强制表格。按影响运行针对性测试、类型检查或构建；UI 行为需要真实交互证据。通过必需检查后即交付，只有新改动、失败或未解假设才扩大检查。

测试应能发现实际回归，不为可逆的小改动编写重复实现的测试。不因工具缺失冒充通过：报告失败命令、原因及仍未验证的行为。

## 交付

说明改了什么、原因、实际验证和剩余阻塞。Bug 修复补一句如何避免再次发生。审查以有证据的发现及文件位置开头。

只请求本地整理时不扩大为发布。若用户已要求“整理后提交/推送”，本地验证完成后继续 $cs-ending-time，沿用已有授权；若用户明确“确认后再提交”，在该处停下。