用途
sdlc-continue 用于「找到工作当前所处的位置，并采取下一步」。它面向已有意向（intent）的继续推进场景，既可以恢复单个意向到其下一个关卡，也可以在用户明确要求时对队列中所有未关闭意向进行自主编排运行。
主要能力
- 状态盘点：从产品仓库根目录运行
sh <this-skill-dir>/scripts/status.sh，列出每个未关闭意向的层级（tier）、状态、已勾选步骤、spec 与 report 状态以及下一关卡。若 sh 或脚本不可用，则自行读取intent/*/。 - 意向选择：优先选择用户点名的 slug，若只有一个未关闭意向则选它；若有多个且未指定，则展示列表并询问。
- 一致性核对：检查仓库与产物是否一致（git status、被勾选步骤声称已更改的代码），并从报告的下一关卡恢复，加载 sdlc-plan、sdlc-apply 或 sdlc-verify。
- 自主运行编排：仅当用户要求处理队列时启用。由技能负责编排（决定顺序与并行度），worker 负责构建。用户接受意向（做什么）与结果，技能负责怎么做与何时做。
使用方式
单意向恢复
- 运行 status.sh（或自行读取 intent 目录）。
- 选择用户指定的 slug 或唯一未关闭的 slug；多个且未指定时先询问。
- 核对仓库与产物一致后，加载对应下一关卡技能恢复工作。
自主运行
- 预检（Preflight）：确认能启动新的 worker 和新的 verifier。若不能，则在本会话中逐个串行运行意向，将 tier critical 的意向在构建前标记为阻塞，并说明 tier 变更结果「未经独立审查」。
- 选择（Select）：运行 status.sh，处理已接受的意向，列出草稿意向并跳过。
- 排程（Schedule）：依据每个意向的
## Approach与 Acceptance 找出重叠（共享文件、契约、迁移）。重叠的意向、以及任意两个新增迁移的意向必须串行，后者的 worktree 在前者落地后才创建；独立意向可并行，各自位于<repo-root>/.worktrees/<slug>（参见 sdlc-apply）；单个意向使用当前检出。最多同时 3 个。排程用不超过 10 行展示后开始。 - 每意向一个 worker：简报包含仓库、worktree 路径、slug，以及「运行 sdlc-apply 到第 5 步后停止，不要运行 verify 或 close，绝不询问用户；若被决策阻塞则返回 needs-decision: <question>」。worker 直接读取 intent.md，而非技能给出的摘要。
- 每个完成意向配一个全新 verifier：仓库、worktree 路径、slug、reviewed_head，运行 sdlc-verify。不要重读其 diff。修复交给持有发现的 worker，复审为增量审查。
- 硬决策（Hard decisions）：在高不确定性的分叉处（参见 sdlc-plan：结果明确、来源支持、失败模式有据、无未决假设），最多启动 2 个只读研究 worker，各问一个具体问题，答案限 15 行。做出决定并记录在
## Approach。仅在产品方向、授权或验收变更时询问用户。 - 逐个落地（Land）：重基到主分支并快进。若补丁发生变化，则进行窄范围重新验证；迁移意向重跑其升级证明。将 worktree 的 report.md 复制到主检出目录的
intent/<slug>/，然后执行git worktree remove与git branch -d。机械冲突自行解决，语义冲突退回 worker。不使用集成分支。 - 有界控制（Bounded）：每个意向仅一轮修复；同一类失败再次发生则以窄复现阻塞该意向。worker 若未返回任何内容且下次检查时无新提交，视为卡住，阻塞该意向并继续。绝不在 wait 或 status 调用上循环；凭完成通知行动或结束回合。每次状态转换一行：slug | phase | verdict。
- 收尾：以一张表结束，列出 slug、verdict、是否落地、给用户的说明。用户接受后关闭（sdlc-apply），若用户要求可一次性关闭所有通过的意向。
适用场景
- 需要恢复中断或进行中的 SDLC 意向，并推进到下一关卡。
- 用户明确要求自主运行，需要按重叠关系编排多个意向的顺序与并行。
限制
- 未经单独授权，绝不推送、部署或采取外部操作。
- 自主运行仅限用户明确要求处理队列时启用。
- 并行上限为 3 个；重叠或含迁移的意向必须串行。
- tier critical 意向在无法启动新 worker/verifier 时需在构建前标记阻塞。
- 具体脚本行为、安装方式与平台细节在资料中暂未提供。