用途：指导独立开发者把单个可发布功能从意图推进到交付，保持「流程不要跑得比功能快」。它是行为指南而非引擎，不构建通用配置、执行器、遥测或优化器。
核心原则：由人定义期望的系统状态，智能体维护规格，测试与证据判断现实是否达标。始终保留两个人工闸门——批准目标契约（易改动的时刻）和审查合并（不可逆时刻），当规模或风险触发条件成立时增加第三个（计划批准）。其余部分是单一聚焦的智能体循环。
适用与跳过：适用于有界、可发布的功能；琐碎改动跳过重流程（短目标→TDD→跑仓库检查→合并）；XL 功能（跨多日、共享契约、迁移、认证/计费、产品歧义）先拆分，不整体跑循环。
六步循环：1）接收，创建或修复目标契约，先做快速规模判断；S 级可在对话中确认短目标，否则将 assets/goal-contract.md 复制为目标仓库的功能目录下的 goal.md（建议 docs/factory/<date>-<slug>/goal.md），由人确认每个字段，必填字段缺失或无法映射具体证据则不通过。2）规模与风险分级：S/M/L/XL 与 R0–R4，默认更少流程，仅在触发时加计划批准、追踪器、可视化证据或审计；R4 禁止或高风险须先外部审查再实施。3）TDD 实现循环：在功能分支或工作树上红→绿→重构，单一聚焦循环，无并行分工；缺测试框架时按栈最小引导；不确定如何写失败测试时可有时间盒的探针，探针代码丢弃；避免基于时钟或休眠的断言；契约变更须枚举并验证所有调用点。4）验证与审计：运行仓库真实的验证命令（测试、lint、类型检查、构建、密钥扫描），本地与 CI 一致，结果记录到 evidence/verify.log；不稳定即失败，不重试、不隔离；由独立新上下文审查者做计划审计与差异审计，结论写入 evidence/audit-*.md。5）证据打包：evidence/ 下仅保留相关证据，合格 UI 改动才截图；统计/行为类结果须在契约中预注册并按真实实验评估。6）回顾删除钩子：发布后在 retro.md 写四行（什么拖慢交付、什么抓到真 bug、哪个产物从未使用、下个功能前删什么），不添加使用遥测、仪表盘或计数器。
追踪：仅当功能确实可分解为多个任务时才建 epic 与 issue；每个功能选一个台账（如 bd、Linear、GitHub Issues 或不用），不得开两个台账。
可移植性：纯 markdown、平台无关；未自动发现技能的智能体需在仓库的 AGENTS.md 或 CLAUDE.md 添加条目指向 SKILL.md；复制时只复制内容文件（SKILL.md、assets/、references/），本地工具状态不得随附。限制：复杂 UI/集成场景的轻量性尚未证实，需用不同功能继续检验；不提供具体收费、价格或平台信息。