sdlc-continue

sdlc-continue

作業の進捗を確認し、次のステップに進みます。

手順

1. プロダクトリポジトリのルートから sh <this-skill-dir>/scripts/status.sh を実行します（<this-skill-dir> はリポジトリではなく、このスキルのインストール先ディレクトリです）。各未完了インテントのティア、ステータス、完了済みのステップ、仕様とレポートの状態、次のゲートが表示されます。sh またはスクリプトが利用できない場合は、intent/*/ を自分で確認します。
2. ユーザーが指定したスラッグ、または未完了のインテントが1つだけならそのスラッグを選びます。複数のインテントが未完了で、どれも指定されていない場合は一覧を表示して、どれを選ぶか尋ねます。
3. リポジトリと成果物が一致していることを確認し（git status と、完了済みステップが変更したとするコードを確認）、報告された次のゲートから再開して、該当するスキル sdlc-plan、sdlc-apply、または sdlc-verify を読み込みます。

自律実行

ユーザーがキューの処理を依頼した場合に限ります。オーケストレーションはあなたが担い、順序と並列実行を決めます。ワーカーが構築します。ユーザーはインテント（何をするか）と結果を受け入れ、どのように、いつ進めるかはあなたが担います。

1. 事前確認。 新しいワーカーと新しい検証担当者を起動できることを確認します。できない場合は、このセッションでインテントを1つずつ処理し、構築に取りかかる前にティアが critical のものをブロックし、ティアが change の結果は「独立したレビューなし」と伝えます。
2. 選択。 status.sh を実行します。accepted のインテントに取り組み、draft のものは一覧表示してスキップします。
3. 一度だけ、簡潔にスケジュールを作成。 各インテントの ## Approach とその受け入れ条件から、共通点（共有ファイル、契約、マイグレーション）を見つけます。重複するインテント、およびマイグレーションを追加するインテント同士は順番に実行し、後続の作業ツリーは先行分が取り込まれた後にのみ作成します。独立したインテントはそれぞれ <repo-root>/.worktrees/<slug> で並列実行します（sdlc-apply を参照）。インテントが1つだけの場合は、現在のチェックアウトを使用します。同時実行は最大3つです。10行以内でスケジュールを示し、開始します。
4. インテントごとにワーカーを1人割り当てる。 指示内容：リポジトリ、作業ツリーのパス、スラッグ、「手順5まで sdlc-apply を実行してから停止すること。verifyやcloseは実行せず、ユーザーにも決して尋ねないこと。判断が必要で進められない場合は needs-decision: <question> を返すこと。」要約を渡すのではなく、ワーカー自身に intent.md を読ませます。
5. 完了したインテントごとに、新しい検証担当者を1人割り当てる。 指示内容：リポジトリ、作業ツリーのパス、スラッグ、reviewed_head、「sdlc-verify を実行すること。」差分を読み直してはいけません。修正は指摘事項を把握しているワーカーに任せ、再レビューは差分に限定します。
6. 重要な判断。 選択肢の判断で確信度が高くない場合（sdlc-plan を参照：結果が明示され、情報源に裏付けられ、失敗モードに根拠があり、未解決の前提がないこと）、読み取り専用の調査ワーカーを最大2人起動し、それぞれに具体的な質問を1つずつ割り当て、回答は15行以内にします。判断して ## Approach に記録します。プロダクトの方向性、権限、または受け入れ条件の変更についてのみ、ユーザーに尋ねます。
7. 取り込み。 インテントを1つずつ取り込みます。メインブランチにリベースして、ファストフォワードします。パッチが変更された場合は、対象を絞って再検証します。マイグレーションを含むインテントは、アップグレードの実証を再実行します。作業ツリーの report.md をメインチェックアウトの intent/<slug>/ にコピーし、その後 git worktree remove と git branch -d を実行します。機械的な競合は解決し、意味的な競合はワーカーに戻します。統合ブランチは作成しません。
8. 範囲を限定。 インテントごとに修正は1ラウンドまでとし、同種の失敗が2度目に起きた場合は、再現手順を絞ってブロックします。次の確認時にワーカーから応答がなく、新しいコミットもない場合は、そのインテントを停滞中としてブロックし、次に進みます。待機やステータス確認を繰り返してはいけません。完了通知に基づいて対応するか、そのターンを終えます。遷移ごとにステータス行を1つ記録します：slug | phase | verdict。
9. 完了。 スラッグ、判定結果、取り込みの有無、ユーザーへの申し送りを含む表を1つだけ提示します。受け入れるのはユーザーです。ユーザーから指示があれば、完了処理（sdlc-apply）を行います。指示があれば、合格したインテントをすべてまとめて処理します。

別途許可を得ずに、プッシュ、デプロイ、外部への操作を行ってはいけません。