用途：把“Software Factory 2026秋”的开发流程应用到当前会话，约束编码智能体的工作方式。仓库自身的格式化、lint、测试与依赖准备步骤以仓库的 CLAUDE.md 或 README 为准。
主要能力与流程：开始前先向用户提问澄清不明点与顾虑，再进入 plan mode；改动告一段落后做 bug 检查，运行 formatter 与 linter，必要时提交，不直接向默认分支提交，push 需用户明确指示。被要求创建 PR 时以 draft 创建，导出对话上下文，并起草带文件名与行号的行内评审评论供用户向评审者说明。sanity-review 由实现者而非评审者执行，需等用户指示，处理意见并 push 后简要评论，再切换为 ready for review；PR 转为 ready 后若可用 squash and merge 指定提交信息，则给出标题与正文草稿。合并后清理开发环境。
环境前提：执行前需确认运行环境，不满足则报告并停止。要求自身模型为 Opus 及以上层级；若存在 Codex CLI，其模型需为 Sol 及以上旗舰且 reasoning effort 为 medium 以上，可用 command -v codex 检查，并以 codex exec --ephemeral 通过 stdin 试运行一次读取输出头部。无 Codex CLI 时可回退到 subagent-consultation skill 并注明，subagent 需指定 Opus 及以上模型；Codex 因限额或通信故障不可用时不得回退，应报告用户。
Git 与 PR 规范：提交前确认分支，处于默认分支则停止并建议分支名；分支名以最重要主题开头，采用 对象-性质 的 camelCase 段与连字符连接，不加 fix/ 或 worktree- 前缀；不擅自改写已提交历史。创建或 push 后运行 conversation-context-export skill，worktree 中输出到主 worktree 的 .dev/contexts/。
限制：sanity-review 需对话上下文已发布到 PR 评论、同机有满足条件的 Codex CLI，且使用 Opus 及以上层级，否则不执行或中止；不得因改动小省略 sanity-review；合并后按条件同步主 worktree 默认分支，不满足时报告原因。代码注释、Agent Skill、GitHub 文案与测试写法分别遵循 kuden:code-comment、kuden:agent-skill、kuden:github、kuden:software-test 的基准。