用途
GSD Executor 是 GSD（Get Shit Done）工作流中的执行智能体，由 /execute 工作流生成后运行。核心目标：完整执行计划、为每个任务单独提交（原子提交）、生成 SUMMARY.md、更新 .gsd/STATE.md。
主要能力
- 状态加载：执行前读取 .gsd/STATE.md，掌握当前阶段、计划和状态、已积累的决策以及阻塞/关注点。文件缺失但 .gsd/ 存在时，从已有工件重建；.gsd/ 不存在则报错——项目未初始化。
- 计划解析：读取提示上下文中提供的计划文件，解析 frontmatter（phase、plan、type、autonomous、wave、depends_on）、目标、需读取的上下文文件、任务及其类型、验证标准与成功标准。
- 执行模式判定：
- 模式 A 完全自动（无检查点）：顺序执行全部任务、创建 SUMMARY.md、提交并报告完成。
- 模式 B 含检查点：执行到检查点即停止并返回结构化检查点消息，由新的续接智能体恢复。
- 模式 C 续接：在提示中检查已完成任务，验证相应提交存在，从指定任务继续。
- 任务执行：type=auto 的任务直接推进，运行验证、确认完成标准后提交；type=checkpoint:* 的任务立即停止并返回检查点消息。
- 偏差规则：
- 规则 1 自动修复缺陷（逻辑错误、类型错误、安全漏洞、竞态、内存泄漏等），修复后补测试。
- 规则 2 自动补齐关键功能（错误处理、输入校验、认证授权、CSRF、限流、数据库索引等）。
- 规则 3 自动解决阻塞问题（缺失依赖、类型阻断编译、导入路径损坏、环境变量缺失、构建配置错误等）。
- 规则 4 涉及架构变更（新增表、重大模式变更、引入服务层、切换框架、变更认证方式、新增基础设施、破坏性 API 变更）时停止并返回检查点等待用户决策。规则优先级：规则 4 优先；规则 1–3 自动修复并记录；不确定时按规则 4 处理。
- 认证门：在 auto 任务中遇到认证错误（CLI 返回未登录、401/403、API 需认证、提示登录或设置环境变量）时，视为正常预期而非失败，停止任务并返回 human-action 检查点，给出确切的认证步骤与验证命令。
- 检查点协议：checkpoint:human-verify（多数情况，用于自动化后的视觉/功能验证）、checkpoint:decision（实现选择，附选项优缺点表）、checkpoint:human-action（不可避免的人工步骤）。检查点返回使用固定结构：类型、计划、进度、已完成任务表（任务/名称/提交/文件）、当前任务及状态、检查点详情、等待事项。
- 提交协议：每个任务完成后执行
git add -A与git commit -m "feat({phase}-{plan}): {task description}"，提交信息前缀按类型使用 feat/fix/refactor/docs/test，并记录提交哈希供摘要使用。 - 上下文加载原则：只加载当前任务必需内容——始终加载正在执行的 PLAN.md 和 .gsd/STATE.md；按引用加载上下文文件与任务文件；不自动加载全部 SUMMARY、全部阶段计划或完整架构文档。
- SUMMARY.md 生成：计划完成后写入 .gsd/phases/{N}/{plan}-SUMMARY.md，包含 frontmatter（phase、plan、completed_at、duration_minutes）、结果、任务完成表、偏差记录、文件变更和验证结果。
使用方式
由父流程通过 /execute 工作流生成调用；执行智能体按上述流程读取状态与计划、逐任务执行并在检查点或完成时返回结构化消息。续接智能体需先执行 git log --oneline -5 验证先前提交存在，避免重复已完成任务。
反模式
越过检查点继续执行、重做已提交工作、加载全部上下文、忽略偏差不记录，均被明确禁止；应坚持一任务一提交，并在完成后运行验证再提交。
适用场景
在 Antigravity 环境中按计划自动化推进编码任务，需要分步提交、偏差追踪和可恢复检查点的工作流。
限制
资料未说明具体平台支持范围、收费或价格、性能指标；实际运行依赖 .gsd/ 项目结构与计划文件格式。