kyro-pi-sprint-flow

用途

kyro-pi-sprint-flow 是 Kyro 流程中的编排器（Orchestrator）。它的职责是：识别当前必须发生什么、启动正确的工作者、注入先前结果、收集结构化返回、展示状态，并遵循 KYRO NEXT STEP 推进。它本身不实现冲刺，也不对冲刺进行认证。

适用场景包括：用户要求处理当前活跃的 Kyro 冲刺；用户要求编排、继续或恢复 Kyro 执行；用户在已有执行结果后要求运行 Kyro QA；用户询问本技能已启动的进行中流程的 Kyro 状态。不适用于规划新范围、退役范围或活跃冲刺之外的工作，这些属于其他 Kyro 技能（kyro-forge、kyro-idea、kyro-scope-retire）。

主要能力与角色划分

• 编排者（本技能）：不加载工作者技能，只负责路由、启动、注入状态、展示状态、询问门控、构建 Fix Plan；不实施、不认证、不打包上下文、不记录证据、不审查。
• Executor Worker：加载 kyro-task-context 与 kyro-sprint-executor，从真实状态执行活跃冲刺。
• QA / Certificator Worker：加载 kyro-qa，独立认证真实工作。
• Fix Worker：加载 KYRO NEXT STEP 所要求的技能（通常为 kyro-task-context 加执行技能），应用 Fix Plan。

使用方式

流程状态保存在编排者会话中，每次传给新工作者的提示必须包含：WHAT HAS BEEN DONE、WHAT WAS VALIDATED、WHAT FAILED、WHAT REMAINS、WHAT KYRO RECOMMENDS NEXT。流程状态包含 current_stage、current_status、worker_results（含 worker_type、status、summary、findings、validation、next_step、raw_output）、executor_results、qa_results、fix_results、pending_actions、current_next_step、fix_qa_rounds、qa_model。

主要步骤：

1. Step 0 识别当前阶段：仅做路由。用户已指明阶段则使用；否则运行 kyro status（或 kyro status --json）查看活跃冲刺与推荐下一步。若 CLI 缺失，须说明并停止，不得从文件臆造 Kyro 状态。
2. Step 1 启动 Executor Worker：要求其自行加载 kyro-task-context 与 kyro-sprint-executor，从真实现状继续，不重做已完成工作，不处理未来或过去冲刺，不手工编辑 sprint.json 等状态。返回须包含 STATUS、SPRINT、WORK COMPLETED、VALIDATION、PENDING、KYRO NEXT STEP，缺项即 BLOCKED。
3. Step 2 展示 Executor 状态（用户门控）：完整呈现各段内容，不得压缩为一段摘要。若下一步是 QA，则先询问用户是否启动，不得自动启动。
4. Step 3 启动 QA / Certificator Worker：仅在首次授权后或修复后的再 QA 时启动。在 Pi 上须先完成认证模型选择。QA 工作者加载 kyro-qa，其最终消息必须原样等于 kyro-qa 的输出，不得包装、摘要、翻译或省略段落。返回契约应包含 QA STATUS、FINDINGS、VALIDATION、CERTIFICATION RESULT、KYRO NEXT STEP（若 kyro-qa 使用不同标题则保留原标题）。
5. Step 4 QA 之后：按 QA STATUS 与 NEXT STEP 分支。CHANGES_REQUIRED 时构建 Fix Plan（含 Problem、Evidence、Expected result、Required change、Scope、Restrictions、Validation），递增 fix_qa_rounds，超过 3 轮则停下询问用户。PASS 时按 Kyro 定义的下一步推进。BLOCKED/FAILED 时展示阻塞，等待解决或用户指示。

关键规则

• 编排者只调度，工作者执行；不得在编排者会话中加载 kyro-sprint-executor、kyro-task-context 或 kyro-qa。
• 每个阶段使用一个新的独立工作者，干净上下文。
• 不得臆造工作者结果；返回契约不完整应视为 BLOCKED 并重新索取缺失字段。
• 遵循 KYRO NEXT STEP；EXECUTOR → QA → FIX → QA 是常见路径而非硬编码状态机。
• 只处理活跃冲刺。
• 不得手工编辑 sprint.json、project.json、证据、裁决或任何 Kyro 管理状态。
• 首次 Executor 运行后的 QA 需用户授权；展示状态后再询问。
• 在 Pi 上，QA 启动前必须让用户从 enabledModels 明确选择认证模型；不得使用 Pi 子代理默认模型；由未选定模型运行的认证无效。
• QA 始终是新的独立工作者；修复后的再 QA 若用户已授权该 QA 轨道则无需第二次授权，但启动前仍展示状态，且 Pi 上仍需确认 qa_model。
• fix → QA 循环上限 3 轮；第 4 次 CHANGES_REQUIRED 时停止并询问。
• 关闭冲刺属于用户门控；关闭由 Executor 工作者经其自身技能完成，编排者不关闭。
• 不得改写工作者的最终报告；Executor 与 Fix 需展示全部契约段落，QA 需逐字呈现其最终消息。

Pi 上的 QA 认证模型（强制）

仅当宿主为 Pi 时适用。每次 QA / 再 QA 子代理启动前：从 ~/.pi/agent/settings.json 的 enabledModels 读取活跃模型（完整 provider/id 字符串），文件缺失则说明并停止，不得臆造目录；向用户展示列表（可附 ~/.pi/agent/models-store.json 中的显示名，但可选值为 enabledModels 条目）；标注父会话模型与 .subagents.defaultModel；推荐一个独立的强认证模型（在已知时不要用 Executor 工作者的模型）；询问使用哪个模型，直到用户从该列表中指定或确认推荐后才启动；将选择存入 qa_model；以该 id 启动 QA 子代理（这是唯一允许覆盖 Pi“子代理不传模型”规则的例外，仅限 Kyro QA、由用户选定、且来自 enabledModels）。如需要思考级别，可使用同一设置文件中的 modelThinkingLevels[qa_model]。

宿主说明

Pi：启动子代理并告知其加载工作者技能（如 /skill:kyro-sprint-executor）；本技能保留在父会话；QA 工作者传入 model = 用户选定的 qa_model；Executor/Fix 工作者仍不传模型（使用 Pi 默认）。Claude Code 或类似宿主：使用 Task 并在简要说明中指明技能，父会话不要执行 Skill("kyro-sprint-executor")。

限制

本技能仅做编排，不实现或认证冲刺；不处理非活跃冲刺及规划、退役范围等工作；不得修改 Kyro 管理状态；QA 与冲刺关闭受用户门控约束；fix→QA 循环有 3 轮上限。关于具体宿主平台、CLI 安装命令、收费与价格等事实，资料未提供。