用途：当用户给出的是一个宽泛目标而非单次窄小改动时使用，适用于实现、实验、评估、清理、规划或需要多次提交的任务。核心原则是把用户目标当作完成单位，而非一次编辑、一次测试或一次提交；提交只是检查点。
主要能力：先检查仓库以理解项目目的、现有架构、测试/检查/构建/运行命令、既有约定、近期提交信息风格与工作区是否干净，并以现有文件和提交历史为准。若目标含糊，做最合理解释并继续；仅在继续可能造成有害或不可逆工作时才询问。将目标内部重述为期望结果、可观察完成标准、可能的验证命令、已知风险或未知项，并维护轻量计划。
使用方式：循环执行——选择下一个能直接推进目标的小目标（通常适合一次逻辑提交）；实现、重构、实验、文档或清理；运行最相关的检查（单元测试、集成测试、类型检查、lint、构建、格式化、定向复现命令、基准或评估脚本），昂贵时先做定向验证、里程碑再做更广验证；提交前审查 diff，确认范围、排除生成或临时文件、无密钥、格式可接受、行为符合当前目标、无关改动已还原或分离；在 diff 构成连贯进展时提交。提交信息需先查看近期历史（如 git log --oneline -n 20），沿用其语气、格式、长度与前缀习惯，但使用通用英文 Conventional Commit 风格前缀（feat、fix、doc、test、refactor、chore），主题正文用日语，格式为 <prefix>: <日本語の要約>，一行，具体且避免含糊。
适用场景与限制：适合多迭代的自主工程循环，默认在每次提交后重新评估并继续，不因单步完成、一次提交、部分测试通过或中间里程碑而停止；计划耗尽但目标未达成时新建短计划继续。仅在目标达成并验证、存在无法解决的阻塞、继续需要凭据/付费服务/破坏性操作/外部权限、仓库无法安全推进，或用户明确要求限量停止时停止。失败验证应作为反馈，诊断并迭代，不隐藏失败。实验应尽量隔离、记录尝试、只保留有用结果，实验基础设施与生产行为可分开提交。收尾前清理临时文件与调试输出，确保文档、注释与测试符合行为，检查 git status 并运行最广的合理验证。最终回复需说明目标是否达成、创建的提交及其日语信息、运行的验证命令与结果、剩余阻塞或后续工作，保持简洁事实。资料未提供具体安装命令、收费或平台信息。