sprint-cycle-routerlisted

> 🔴 **GitHub 操作の経路（必読・L-114）**: クラウド実行環境では `gh` がプリインストールされず、 > 導入しても repo スコープ REST が 403 になりうる。**本ファイル内の `gh ...` コマンドはローカル実行専用** > で、クラウドでは `mcp__github__*` に読み替える（対応表: `docs/rules/github-mcp-fallback-patterns.md`）。 > 本スキルは無人 cron 起動が既定のため、**Step 0.0 で毎 firing チャネルを再判定する**（§0 参照。 > 「前回動いたから今回も」という恒久判断はしない）。 # sprint-cycle-router スキル ## 目的 飼い主が単一のルーティン設定内で「N 時間ごとに開発が進む」状態を作れるよう、**1 本の決定木** で 「今 firing で何を実行すべきか」を判定し、実処理は既存パイプラインスキルに委譲するルーター。 新規スプリント着手（Step 4）だけは本スキルが内部手順を持つ（`sprint-development-rules.md` の `SD-1`〜`SD-4` を実行する主体がここに要るため）。 設計の経緯・却下案・被害の非対称性の議論全文は `content/discussions/sprint-cycle-design-20260818/whiteboard.md`（本スキルは判定ロジックの実体。 議論ログは変更しない）。 ## 他レーンとの境界 - 破壊的変更対応の実処理 → `claude-code-spec-sync` - PR レビュー・マージ・公開反映の実処理 → `pr-review-watcher` - 改善 Issue の発見・棚卸し・消化の実処理 → `self-improvement-loop` - リポジトリ衛生（Stale/Orphan/ラベル不整合）の実処理 → `workflow-health-check` → `project-sync` - 本スキルはこれらの **呼び出し順序と、どれも該当しないときの新規スプリント着手（Step 4）** だけを担う。 Step 4 の実装フローが既存 4 レーンと並ぶ「第 4 レーン（スプリント開発レーン）」であることの境界定義は `docs/rules/improvement-lane-map.md` を参照する（本スキルでは再定義しない）。 --- ## §0 実行モデル - **1 firing = 上から該当する最初の 1 ブランチだけを実行する。** スプリントは複数 firing にまたがってよい （SD-1 の完了条件は「マージされた PR にプレビュー URL があり操作レビューを完走できる」ことであって 「1 firing で完結する」ことではない）。 - **毎回新規セッション・エフェメラル VM**。前回 firing のメモリ・ローカル state は引き継がれない。 次回 firing が状態を知る手段は **GitHub 上のアーティファクト（Issue ラベル・コメント・PR・ブランチ・ コミット）だけ**。日次・毎 firing の判定に新規 state ファイルを作らない（§9 の週次ゲートのみ既存パターンを流用可）。 - 早期リターン（§2）を安く済ませることで、cron を短い間隔で回しても空振りコストを抑える