用途
Symphony 技能用于让单人智能体的工作与 Symphony 的队列和生命周期保持连接。Symphony 是工作项的操作层，Codex 可以通过 App Server 运行这些工作项，同时使用者可以在 Mac 应用以及后续的 Dobby 中保持可见性。当智能体被给定一个 Symphony 工作项 ID 时，应使用该技能加载工作项、在目标仓库中完成工作，并更新生命周期状态。
运行模型
- 当存在 Symphony 工作项时，把它作为协调对象。
- 优先遵循目标仓库的 AGENTS.md、文档、检查项和本地工作流，其次才是本技能的偏好。
- 使用真实的仓库工作目录，以便 Codex Mac 应用会话保持可见和可恢复。
- 将 Symphony 元数据与人工交接分开。
- 不要把 Symphony 生命周期状态写入 Things 3。只有当任务明确来自 Things 时，Things 才作为遗留输入。
- 不要把原始日志、密钥、大型 diff 或嘈杂的诊断信息粘贴到交接内容中。
生命周期状态
Symphony 的状态包括：
- ready：工作可以被领取。
- running：Codex 正在积极工作。
- needs_input：被使用者阻塞。
- done：Codex 认为工作已完成。
- failed：执行失败。
- cancelled：被有意停止。
没有 needs_review 状态。在单人智能体原生循环中，如果 Codex 认为任务已就绪，Symphony 工作项即为 done；最终交接仍可提及注意事项和验证缺口。
仅在进展确实受阻时使用 needs_input，例如：
- 需要凭据、账户权限、设备访问或外部批准。
- 多个可能的产品决策会导致实质不同的结果。
- 继续工作可能带来数据丢失、破坏性生产变更或违反仓库指引的风险。
- 必需的源材料缺失，且无法从仓库或任务中推断。
受阻时，请求能解除下一次运行阻塞的最小具体输入。
工作流程
- 当给定一个 Symphony 工作项 ID 时，通过任务客户端加载它。
- 从加载得到的 repoPath 读取目标仓库指引。
- 按照本地规则在目标仓库中完成工作。
- 运行仓库提供的最相关验证。
- 遵循仓库正常的收尾路径处理提交、钩子、评论和推送。
- 在结束前通过任务客户端更新 Symphony 生命周期状态。
任务客户端
使用 Symphony 仓库中打包的机器主客户端。所有正常的生命周期读写都优先使用这个直接的 Node CLI：
~/GitHub/symphony/dist/src/cli.js task <command> <work-id> --no-input
如果构建好的 CLI 缺失，运行：
cd ~/GitHub/symphony && npm run build -- --pretty false
加载工作项：
node ~/GitHub/symphony/dist/src/cli.js task get <work-id> --no-input
获取最小交接提示：
node ~/GitHub/symphony/dist/src/cli.js task prompt <work-id> --no-input --plain
完成工作项：
printf '%s\n' "<human handoff>" \
| node ~/GitHub/symphony/dist/src/cli.js task complete <work-id> --note-file - --no-input
标记工作项受阻：
printf '%s\n' "<smallest useful request>" \
| node ~/GitHub/symphony/dist/src/cli.js task needs-input <work-id> --note-file - --no-input
标记工作项失败：
printf '%s\n' "<failure summary>" \
| node ~/GitHub/symphony/dist/src/cli.js task failed <work-id> --note-file - --no-input
记录使用者的回答并让工作项重新就绪：
printf '%s\n' "<Adi's answer>" \
| node ~/GitHub/symphony/dist/src/cli.js task input <work-id> --note-file - --no-input
客户端返回稳定的 JSON 信封，包含 schema_version、command、status、data、error 和 meta。将非零退出视为生命周期写入失败。
回退辅助脚本
这是一个薄封装。仅当更短的命令有用时使用；如果出现卡住或令人困惑的情况，请切回上面的直接 Node CLI。
$HOME/GitHub/agents/skills-source/owned/symphony/scripts/task
该封装转发到 ~/GitHub/symphony/dist/src/cli.js task ...，并保留相同的稳定 JSON 信封。把它视为回退便利路径，而不是首选调试路径。
加载工作项：
"$HOME/GitHub/agents/skills-source/owned/symphony/scripts/task" get <work-id> --no-input
完成工作项：
printf '%s\n' "<human handoff>" \
| "$HOME/GitHub/agents/skills-source/owned/symphony/scripts/task" complete <work-id> --note-file - --no-input
标记工作项受阻：
printf '%s\n' "<smallest useful request>" \
| "$HOME/GitHub/agents/skills-source/owned/symphony/scripts/task" needs-input <work-id> --note-file - --no-input
标记工作项失败：
printf '%s\n' "<failure summary>" \
| "$HOME/GitHub/agents/skills-source/owned/symphony/scripts/task" failed <work-id> --note-file - --no-input
该辅助脚本直接更新 Symphony 状态；它不与 Things 通信。它默认有较短的超时，并返回与直接 Node CLI 相同的稳定 JSON 信封。
交接格式
用自己的话写一份简洁的交接。选择适合结果的格式，而不是每次都强制使用所有标题。
通常包括：
- Outcome：completed、blocked 或 failed。
- What changed：有意义的代码、文档、配置或行为变更。
- Validation：运行的命令/检查以及是否通过。
- Human attention：注意事项、需要做出的决策，或工作受阻的原因。
- Follow-up：仅真实的后续事项，而非泛泛的下一步。
保持交接以人为先。如果运行元数据有用，把它放在底部一个简短的 Run details 部分下。
避免事项
- 不要把 Things 3 当作 Symphony 的协调界面。
- 不要创建 review 状态，或把请求人工审查作为生命周期要求。
- 不要把机器专用的回执作为主要交接内容。
- 不要把实际结果埋在提交哈希、线程 ID 或检查路径之下。
- 不要编造未运行的验证。
- 当仓库已经定义了流程规则时，不要创建新的流程规则。