makelore/.opencode/skills/dev-build-test/SKILL.md

name, description

name	description
dev-build-test	当 NianCode 开发工程师角色为学习者软件项目设计数据/接口、实现代码、调试、编写或更新测试、运行验证并解释编码决策时使用。

开发构建测试

使用这个 skill，以安全且适合教学的方式实现已确认的原型。

给学生看的说话规则

必须使用 youth-plain-language。讲代码时先说学生能看到的变化，再解释文件、命令或错误。

工作流程

1. 阅读计划、设计/原型交接和现有代码。
2. 找到满足验收标准的最小代码改动。
3. 复用现有项目模式。
4. 需要时先实现数据/接口结构，再接 UI。
5. 按风险增加或更新测试。
6. 运行聚焦验证。
7. 用学习者容易理解的语言解释改动。

学习者 TDD 规则

当行为可测试时，先定义检查，再改代码：

1. 编写或描述最小的失败检查。
2. 确认失败代表什么。
3. 实现让检查通过的最小改动。
4. 重新运行检查并报告结果。

如果正式自动化测试对学习者项目来说过重，使用清晰的人工检查，写明准确步骤和预期结果。

调试规则

出现问题时不要猜。先确认：

• 准确错误或异常行为
• 如何复现
• 最近改动了什么
• 最小的可能问题来源

一次只修一个根因，在继续改动前重新检查。

验证规则

没有新证据时，不要说代码已完成。报告实际使用的命令、测试、预览或人工检查，以及观察到的结果。

UI/UX 课程质量

必须使用的子 skill： 实现或验证学习者可见 UI 时，使用 ui-ux-course-quality。

检查已实现界面是否有 aria 名称或等效标签、可见焦点、可读对比度、核心流程无横向滚动、触控区域可用、响应式布局正常，并包含原型承诺的加载/错误/空/成功状态。自动化覆盖不实际时，报告人工检查结果。

必须输出

返回工程报告，包含：

1. 改动文件
2. 数据/接口设计
3. 实现内容
4. 测试或检查命令
5. 结果
6. UI/UX 检查结果
7. 剩余风险
8. 给市场运营/部署工程师的事实说明

纠偏清单

出现这些情况时纠偏：

• 范围、UI 流程或验收标准还不清楚就开始编码。
• 方案明显超过学习者需要的复杂度。
• 代码改动忽略现有模式。
• 没有运行验证，也没有说明原因。
• 没有实现证据就做公开宣传结论。

优先选择小而可运行、并有可见证据的改动。

交接

交接给市场运营时，提供真实功能事实和限制。交接给部署工程师时，提供构建/测试状态和实际运行的命令。