sdlc-continue

sdlc-continue

了解工作进展，并采取下一步行动。

步骤

1. 在产品仓库根目录运行 sh <this-skill-dir>/scripts/status.sh（<this-skill-dir> 是此技能的安装目录，而不是仓库目录）。该脚本会列出每个未关闭的意图，包括层级、状态、已勾选的步骤、规格和报告状态，以及下一道关卡。如果无法使用 sh 或该脚本，请自行读取 intent/*/。
2. 选择用户指定的 slug，或唯一一个未关闭的意图。如果有多个未关闭的意图，且用户未指定，请列出并询问要选哪一个。
3. 检查仓库状态是否与产物一致（git status，以及已勾选步骤声称修改过的代码），并加载相应技能，从报告的下一道关卡继续：sdlc-plan、sdlc-apply 或 sdlc-verify。

自主运行

仅当用户要求处理队列时执行。由你统筹：你决定顺序和并行方式，工作者负责构建。用户接受意图（做什么）和结果；你负责如何做以及何时做。

1. 预检。 确认可以启动新的工作者和新的验证者。如果不能，就在本会话中逐个处理意图，在构建前将层级为 critical 的意图标记为阻塞，并说明层级为 change 的结果“未经独立审查”。
2. 选择。 运行 status.sh。处理状态为 accepted 的意图；列出状态为 draft 的意图并跳过。
3. 一次性、低成本地安排。 根据每个意图的 ## Approach 和验收标准，找出重叠之处：共享文件、契约、迁移。存在重叠的意图，以及任何两个会添加迁移的意图，都要按顺序运行；只有前一个意图已合并后，才创建后一个意图的工作树。独立的意图并行运行，每个使用 <repo-root>/.worktrees/<slug>（参见 sdlc-apply）；如果只有一个意图，则使用当前检出。最多同时运行 3 个。用不超过 10 行展示安排并开始执行。
4. 每个意图分配一名工作者。 简述：仓库、工作树路径、slug、“运行 sdlc-apply 直到第 5 步，然后停止。不要运行 verify 或 close，也绝不要询问用户：如果因决策受阻，请返回 needs-decision: <question>。”工作者自行读取 intent.md，不要让其依赖你提供的摘要。
5. 每个已完成的意图分配一名全新的验证者：仓库、工作树路径、slug、reviewed_head、“运行 sdlc-verify”。不要重新阅读其差异。修复交给持有审查结果的工作者；复审只检查差异部分。
6. 关键决策。 如果遇到分歧，且信心不高（参见 sdlc-plan：结果明确、来源支持、故障模式有证据、没有未解决的假设），最多启动 2 名只读研究工作者，每人负责一个具体问题，回答不超过 15 行。做出决定，并记录在 ## Approach 中。只有涉及产品方向、权限或验收变更时，才询问用户。
7. 合并。 一次处理一个意图。变基到主分支并快进合并。如果补丁有改动，就针对性地重新验证；涉及迁移的意图要重新运行升级证明。将工作树中的 report.md 复制到主检出中的 intent/<slug>/，然后运行 git worktree remove 和 git branch -d。解决机械性冲突；语义冲突交回工作者处理。不要创建集成分支。
8. 设定上限。 每个意图只进行一轮修复；同类问题第二次失败时，用最小复现将其标记为阻塞。如果工作者没有返回任何内容，且你下次检查时没有发现新提交，则视为卡住：将该意图标记为阻塞并继续处理其他意图。不要反复等待或查询状态；根据完成通知采取行动，或结束本轮。每次状态转换只输出一行：slug | phase | verdict。
9. 结束。 最后用一张表列出：slug、结论、是否已合并、用户需要处理的事项。由用户接受结果；之后关闭（sdlc-apply）。如果用户同意，可一次关闭所有通过的意图。

未经单独授权，绝不推送、部署或采取外部操作。