soia-dev-coding-protocollisted

# soia-dev-coding-protocol ## 客户可读说明 ### 这个技能可以做什么 为代码实现、bug fix、重构和评审建立可验证的工作契约：改什么、为何改、如何证明改变正确，以及哪些风险尚未覆盖。 | 客户想要 | 技能会做 | 客户能看到 | |---|---|---| | 修复缺陷或实现功能 | 先定义最小范围和验收证据，再做最小可靠改动 | 变更映射、测试证据和残余风险 | | 评审或重构 | 检查行为保持、类型边界与同类模式 | 发现、复核路径和未处理项 | ### 客户如何使用 说明目标、目标仓库、相关文件、可观察的预期行为，以及可用的测试或复现路径。涉及认证、删除、不可逆数据变更、公开 API 或远端发布时，缺少关键约束必须先询问。 ### 依赖与安装 安装： ```bash npx skills add soia-team/soia-open-skills -g -a '*' -s soia-dev-coding-protocol -y ``` 强依赖：目标仓库和与任务相称的验证手段。优先使用项目已有测试、lint、类型检查和 fixture；没有时使用最窄的可靠复现并说明限制。本技能无需私有配置。 ### 日志与完成回执 ```markdown 完成：<实现、修复、重构或评审结果>。 契约：<假设、范围边界、验收目标> 文件变化：<每项变更如何映射到请求> 验证：<命令、结果和独立复核> 残余风险：<未覆盖场景或“无”> ``` ## 执行契约 写代码前明确： - 假设：哪些来自观察、哪些是推断； - 范围：包含什么、不包含什么； - 验证计划：每个步骤对应的可证伪检查。 写代码后明确：改变了什么、它如何满足请求、实际运行了哪些验证、哪些真实风险仍存在。没有证据就不能称为完成。 ## 核心规则 ### 1. 暴露不确定性 会影响正确性、安全性、外部行为、数据完整性或 API 合约的歧义必须先问。低风险歧义采用最窄、可逆的解释并说明。认证、破坏性操作和不可逆变更不得靠猜测推进。 ### 2. 最小范围 只写完整解决当前问题所需的代码。不要因为顺手加入抽象、开关、重命名、格式化或“未来可能需要”的分支。发现无关问题时单独报告，不混入补丁。 ### 3. 隔离并追溯改动 每一行改动都应能映射到请求或为该改动必要的验证。沿用周边风格；只移除被本次改变淘汰的内容。修复一种模式后搜索同类调用点，再决定是否纳入范围。 ### 4. 验证结果，不验证意图 - bug fix：可行时先复现；否则建立最窄的失败检查； - validation logic：覆盖非法输入及预期通过路径； - refactor：以 before/after 或行为测试证明语义保持； - 多步任务：先写 `[步骤] -> [验证]`； - 测试失败、无法运行或只覆盖 happy path 时，如实报告，不能用“代码看起来对”替代证据。 ## Anti-Fake-Fix Gate 在宣称完成前逐项检查： | 症状 | 要求 | |---|---| | 没跑验证就称完成 | 补跑真实命令或明确说明为何无法验证 | | 用 TODO、注释或吞错代替修复 | 让行为本体满足需求，或明确将任务标为未完成 | | 只验证自己的结论 | 使用独立路径：测试、fixture、类型检查、日志或人工复核 | | 修一处就收口 | 搜索同类模式，说明纳入或排除理由 | | 一次提交混入无关调整 | 拆分或移除无关改动