OpenChamber 变更纪律
在修改 OpenChamber 代码库时，强制执行“最小完整变更 + 最窄级别验证”的工程纪律，防止局部修复演变成投机性重写。
该技能是纯流程/规范文档，无脚本执行、无权限请求、无外部副作用或数据流，红线风险不存在；要求显式处理回滚、清理与破坏性操作，安全导向良好。扣分点：来源归属仅限仓库许可（MIT），技能文件自身无署名或版本，未验证发布者身份。
指令内部自洽：风险分类表、验证矩阵与完成标准相互呼应，冲突时要求停止而非静默选择，失败反馈要求明确报告未执行项。扣分点：完全未执行验证，'bun run dead-code' 等命令依赖仓库脚本可用性，无法静态确认可运行性，受静态校准上限约束。
description 触发条件明确（实现、修复、重构 OpenChamber 源码、依赖、导出、构建配置等），场景与不适用范围相对清晰，且明确告诫不要把局部变更升级为全仓仪式，触发精度较好。扣分点：严格绑定 OpenChamber 这一特定 monorepo（bun、knip、多 workspace），跨项目不可复用，无中文支持声明。
结构清晰，采用渐进式分层（原则→风险分类→结构纪律→审查提示→验证矩阵→测试设计→完成标准），表格化表达可读性好，仓库有 MIT 许可与 SECURITY.md。扣分点：技能文件自身无版本号、更新记录、示例或 FAQ，维护责任与更新路径未在技能层面说明。
作为变更纪律指南，其最小完整变更、风险分类、验证矩阵等方法论对 AI 代理修改该仓库代码有实际边际价值，指令具体可操作。扣分点：静态评审无法验证产出效果，价值依赖模型遵循程度，无可比的代表性输出证据，受静态校准上限约束。
仓库含真实 CI 工作流、测试脚本与手动检查清单（如 shortcut-registry checklist），为技能声明的验证流程提供部分旁证。扣分点：无任何证据直接覆盖该技能文件本身的关键路径，未执行复现，多源交叉验证薄弱。
- 该技能严格绑定 OpenChamber 仓库的工具链（bun、knip、多 workspace 脚本），不适用于其他项目。
- 所有验证命令（如 bun run dead-code、各包 test/lint）均为静态引用，未实际执行复现。
- 技能文件自身无版本号与变更记录，后续修订难以追踪。
- 发布者未经验证，身份按未知处理；未据此扣分，也未据此加分。
- 核心工作流依赖 GitHub 与 opencode.ai 等海外服务，中国大陆网络可达性未验证。
这个 Skill 能做什么，适合哪些场景？
openchamber-change-discipline 是 OpenChamber 仓库（一个 OpenCode AI 代理的桌面/Web 界面）内置的 18 个技能之一，位置在 .agents/skills/openchamber-change-discipline/SKILL.md。它是一份纯指令型方法论文档，没有脚本或工具依赖。技能规定：编辑前先检查邻近实现、调用方和测试，把变更按风险分类（局部实现、模块契约、跨工作区契约、持久化/外部行为、平台运行时行为），并据此选择最小验证范围。还包含结构化纪律（行为保持、依赖注入、拒绝 any 类型）、审查提示清单、验证矩阵和测试设计原则，最后以“完成标准”收尾。
读取使用者当前的变更意图后，技能指导模型：1) 对变更做五类风险分类，并为每个风险指定负责人和所需验证；2) 按验证矩阵选择最小验证组合（如包内类型检查 + lint、跨工作区检查、bun run dead-code、兼容性/回环测试）；3) 应用结构纪律——保持调用方建立的行为、入口保持精简、显式依赖注入、避免 any 和盲转型、对重试/缓存/兼容路径要求证据；4) 对破坏性或多步操作明确回答回滚、清理、可重试范围和用户可见结果；5) 完成前做最终简化检查，移除投机分支和浅层包装。
- 维护 OpenChamber 这类多包 monorepo 的开发者，在修改导出 API 或类型时需要判断哪些消费方受影响、要跑哪些验证。
- 团队希望约束 AI 代理或新成员不要把局部修复扩大成全库重构，或反过来把架构迁移伪装成本地补丁。
- 修改持久化数据、路由、CLI 输出等外部契约时，需要强制考虑兼容性、失败处理和降级行为。
- 执行 Electron、VS Code 等平台相关行为变更时，需要提醒必须做真实运行时验证而非仅静态检查。
- 设计回归测试时，希望测试断言可观察契约而非内部实现细节，使重构测试对等价实现保持韧性。
这个 Skill 有哪些优点和局限？
- 提供具体可执行的验证矩阵，把“改什么就验证什么”落到明确条目，而非空泛建议。
- 风险分类表直接对应计划后果，便于代理和人类据此分配测试范围。
- 对破坏性操作、持久化数据迁移、回滚语义给出了明确且克制的定义，避免过度工程。
- 纯文档无运行时依赖，可移植到任何支持 Agent Skills 的客户端。
- 强绑定 OpenChamber 项目语境（bun run dead-code、工作区结构、Electron/VS Code 等具体平台），用于其他项目需要改写细节。
- 不含自动化脚本或检查工具，所有验证依赖执行者自觉运行。
- 没有独立的测试套件或效果证据证明该纪律能减少缺陷；源材料中未提供采纳后的量化结果。
- 指令密集且篇幅较长，对简单变更可能显得流程偏重。
如何安装这个 Skill？
该技能随 OpenChamber 仓库分发。获取方式是克隆仓库 https://github.com/openchamber/openchamber 并使用 .agents/skills/ 目录下的技能文件；仓库 README 未单独说明此技能的安装命令。遵循 Agent Skills 标准的客户端通常只需将技能文件夹放入其技能目录。
如何使用这个 Skill？
在修改 OpenChamber 源码、依赖、导出、构建配置、生成资产或模块归属时触发。示例提示词：“我准备重构这个包的导出 API，请先按变更纪律分类风险并列出所有受影响的消费方和需要的验证。”技能也适用于让代理在实施前先回答审查提示（新抽象是否被复用、失败后状态是否会滞留等）。