完成工作 - 提交前检查清单
在提交或 commit 之前，使用此检查清单确保工作完整性。
时机：代码编写和测试完成后，commit 之前
检查清单
1. 代码质量
bash
# 必须通过 pnpm lint pnpm type-check pnpm test
- •
pnpm lint零错误通过？ - •
pnpm type-check无类型错误通过？ - • 测试通过？
- • 没有
console.log语句（使用 logger）？ - • 没有非空断言（
x!操作符）？ - • 没有
any类型？
2. 代码规范同步
代码规范文档：
- •
.trellis/spec/backend/是否需要更新？- •新模式、新模块、新约定
- •
.trellis/spec/frontend/是否需要更新？- •新组件、新 Hook、新模式
- •
.trellis/spec/guides/是否需要更新？- •新的跨层流程、Bug 修复的经验教训
关键问题：
"如果我修复了一个 Bug 或发现了非显而易见的东西，是否应该记录下来，以免未来的自己（或其他人）再踩同样的坑？"
如果是 → 更新相关的代码规范文档。
2.5. 代码规范硬性阻断（基础设施/跨层）
如果此变更涉及基础设施或跨层契约，这是一个阻断性检查清单：
- • 规范内容是可执行的（真实的签名/契约），而非仅有原则性文字
- • 包含文件路径 + 命令/API 名称 + 载荷字段名
- • 包含验证和错误矩阵
- • 包含 Good/Base/Bad 用例
- • 包含必需的测试和断言点
阻断规则：
如果基础设施/跨层发生了变更但相关规范仍然是抽象的，不要完成。先手动运行 $update-spec。
3. API 变更
如果你修改了 API 端点：
- • 输入 schema 已更新？
- • 输出 schema 已更新？
- • API 文档已更新？
- • 客户端代码已同步更新？
4. 数据库变更
如果你修改了数据库 schema：
- • 创建了迁移文件？
- • Schema 文件已更新？
- • 相关查询已更新？
- • 种子数据已更新（如适用）？
5. 跨层验证
如果变更跨越多个层：
- • 数据在所有层之间正确流转？
- • 每个边界的错误处理正常？
- • 类型在各层之间一致？
- • 加载状态已处理？
6. 手动测试
- • 功能在浏览器/应用中正常工作？
- • 边界情况已测试？
- • 错误状态已测试？
- • 页面刷新后仍正常？
快速检查流程
bash
# 1. 代码检查 pnpm lint && pnpm type-check # 2. 查看变更 git status git diff --name-only # 3. 根据变更的文件，检查上面的相关项目
常见遗漏
| 遗漏 | 后果 | 检查方法 |
|---|---|---|
| 代码规范文档未更新 | 其他人不知道这个变更 | 检查 .trellis/spec/ |
| 规范文字过于抽象 | 基础设施/跨层变更容易回归 | 要求签名/契约/矩阵/用例/测试 |
| 未创建迁移文件 | Schema 不同步 | 检查 db/migrations/ |
| 类型未同步 | 运行时错误 | 检查共享类型 |
| 测试未更新 | 虚假的信心 | 运行完整测试套件 |
| 遗留 console.log | 生产环境日志噪音 | 搜索 console.log |
与其他命令的关系
code
开发流程：
写代码 -> 测试 -> $finish-work -> git commit -> $record-session
| |
确保完整性 记录进度
调试流程：
遇到 Bug -> 修复 -> $break-loop -> 知识沉淀
|
深度分析
- •
$finish-work- 检查工作完整性（本 Skill） - •
$record-session- 记录会话和提交 - •
$break-loop- 调试后的深度分析
核心原则
交付不仅仅是代码，还包括文档、验证和知识沉淀。
完整的工作 = 代码 + 文档 + 测试 + 验证