用途
Code craft 用于在软件工程中做设计决策时，套用 Jess 的工程约定。它的核心主张是：先证明类型能证明的部分，再只测试类型无法证明的部分。每个不变量都应有唯一归属——证明阶梯上能够真正证明它的最强一层。
主要能力
该技能围绕若干具体决策提供参考：
- 决定哪个不变量由阶梯的哪一层负责（证明阶梯）。
- 表示状态、工作流与领域身份（非法状态）。
- 将外部输入解码为有用的类型（解析而非校验）。
- 为依赖、失败与资源生命周期标注类型（效果）。
- 建模可恢复错误与必需门禁（错误即值）。
- 守卫敏感的前置条件（证明参数）。
- 选择抽象或调查性能（简洁性）。
- 维护模块边界及其文档（架构文档）。
证明阶梯的顺序为：类型与 linter、效果、证明、数据库约束、单元测试、集成测试、端到端测试。
使用方式
使用仓库当前的指令与既有约定。当所请求的变更需要设计决策时，套用这些默认约定；它们不授权无关的重构或引入新工具。
按范围内的决策查阅对应参考：不变量归属看证明阶梯；状态、工作流与领域身份看非法状态；外部输入解码看“解析而非校验”；依赖、失败与资源生命周期看效果；可恢复错误与必需门禁看“错误即值”；敏感前置条件看证明参数；抽象或性能取舍看简洁性；模块边界与文档看架构文档。
仅当语言的惯用法、并发或工具细节确实重要时，才查阅语言参考：TypeScript、Rust、Go 或 Python。
对于新的 TypeScript 代码与完整项目模板，Jess 的技术栈是 Effect、Effect Schema 或 Zod、xstate 以及 gdp-ts。对于新的 Rust 服务端，则是 tokio、axum、snafu、aerosol 与 sqlx。在已有仓库中，使用其等价物；添加其中任何一项都属于架构变更，需要先询问。
数据库 schema、约束、查询与作业使用 database-craft；测试层级使用 testing-craft。仓库初始化在需要时属于 project-bootstrap。遵循项目要求的验证方式；评审并不自动要求完整的测试套件。
适用场景
适用于在已有代码库中进行设计决策、需要统一工程约定时，例如决定某条不变量应由类型系统、数据库约束还是测试来保证，或需要为状态建模、错误处理、抽象选择等提供参考依据。
限制
该技能不授权无关的重构或引入新工具。在已有仓库中应使用其等价物，添加其推荐技术栈中的任何一项都属于架构变更，需要先询问。评审并不自动要求完整的测试套件，应遵循项目自身要求的验证方式。
来源说明
该技能改编自 leonardomso/rust-skills（MIT）、Matklad 的 Rust100k 系列、Alexis King 关于解析与类型安全的文章，以及 Matt Noonan 的 Ghosts of Departed Proofs。