correct-course

コースの修正

新しい情報が判明した場合、前提が崩れた場合、スコープが変わった場合など、現在のパイプライン成果物を信頼できなくなったときに、このスキルを実行します。/correct-course は影響範囲を診断し、再実行が必要となる最も早い段階のスキルを特定して、古くなった成果物を整理してから次に進む手順を案内します。

これは、references/SYSTEM-OVERVIEW.md（このスキルと一緒にバンドルされています）に記載されたパイプライン復旧ルールの、名前付きで呼び出し可能な形式です。ルール自体は引き続き適用されます。このスキルは、それらのルールへの入り口を提供するものです。

1 回のターンにつき質問は 1 つです。 このスキル全体を通して、一度に 1 つだけ質問し、次の質問をする前にユーザーの回答を待ちます。話をさかのぼるのはフォームではなく、会話です。

単一選択を優先してください。 ユーザーが 1 つの方向性、優先事項、または次のステップを選ぶ場合は、単一選択の多肢選択形式を使用します。

複数選択はなるべく避けてください。 併存できる目標、制約、対象外事項、成功基準などに限って使用します。優先順位が重要な場合は、選択された項目のうちどれを優先するか、追加で尋ねてください。

利用可能な場合は、プラットフォームの質問ツールを使用してください。 Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user を使用します。それ以外の場合は、チャットで番号付きの選択肢を提示し、先に進む前にユーザーの返答を待ちます。

呼び出し位置

これはサイドルートのスキルで、診断結果に応じて、パイプライン内の以前のスキルからメインパイプラインに再接続します。

次のいずれかに当てはまる場合は、/correct-course を使用してください。

• /research で判明したバージョンの変更や制約により、/shape の締めくくりの要約が無効になった
• /write-a-prd で、シェーピング時に問題の捉え方が誤っていたことが判明した
• /prd-to-issues で、作業全体が提示された許容範囲を大きく超えることが判明した
• /execute で、アーカイブされた調査内容または PRD の誤りが根本原因となるエラーが発生した
• /pre-merge の境界マップ契約の観点から、仕様と現実の不一致が見つかった — コードは外部の現状を反映しているものの、宣言された仕様が古くなっている（存在しないパッケージ、名前が変更された公開 API、調査スナップショットで固定した範囲を超えるバージョンの乖離）
• /pre-merge で、助言的な指摘にとどまらず、手直しが必要となるアーキテクチャ上の懸念が見つかった
• 記述されている作業の内容が変更または置き換えられたため、GitHub Issue が古くなった

次の用途には使用しないでください。

• 予定どおりに進んでいる作業（通常のパイプラインを使用します）
• トリアージだけで済むバグ（/qa を使用します）
• 古くなった成果物とは関係のないリファクタリングの機会（/request-refactor-plan を使用します）
• 過去の成果物が存在しない新規のシェーピング（/shape を使用します）

プロセス

1. きっかけを把握する

1 つだけ質問します。「現在の成果物を信頼できなくなったのは、何が変わったからですか？」

ユーザー自身の言葉で説明してもらいます。まだ追加の質問はしないでください。すべての経緯ではなく、無効化の種類を把握します。

• 新しい情報 — バージョンの確認結果、ベンチマーク、関係者のコメント、デモの失敗
• 前提の崩壊 — /shape の要約で Likely または Uncertain とされていた内容が誤りだと判明した
• スコープの変更 — 許容範囲、対象外事項、必須事項を変更する必要がある
• 問題の捉え方の誤り — 表面化した症状ではなく、根本的な問題に取り組むべきだったとユーザーが気づいた
• 外的要因 — 依存関係の非推奨化、料金プランの変更、パートナー API の削除

該当すると思われる種類を、1 文で記録します。ステップ 2 で使用します。

2. 影響範囲を診断する

トリガーに基づいて、出力の信頼性が失われた最も早い段階のスキルを特定します。目安は次のとおりです。

トリガー	最も早い段階で影響を受けるスキル
/shape の前提が誤っている	/shape
バージョンや API の実態が、アーカイブ済みの調査内容と食い違っている	/research
問題の捉え方が誤っている — 原因ではなく症状を解決している	/shape
Appetite または避けるべきことを変更する必要がある	/write-a-prd
問題と Appetite は変わらないが、解決策の方向性が誤っている	/write-a-prd
スライスへの分解により、作業量が Appetite を超えると判明した	/write-a-prd（再構成）。/prd-to-issues（再分解）ではありません
境界マップの契約が誤っていたが、スライスは引き続き有効である	/prd-to-issues
スライスは正しいが、実行方法が行き詰まった	/execute（後戻りではありません。別の方法を試します）
/pre-merge でのアーキテクチャ上の懸念から、やり直しが必要になった	/execute。先に /request-refactor-plan を実行する場合もあります

確認のために調査します。PRD の Issue、スライスの Issue、該当機能の調査アーカイブ項目、および関連するソリューション項目を読みます。調査項目は PRD が示す絶対パスにあります（/research の Phase 5c に保存先が記されています）。PRD がまだ存在しない場合、参照するパスもありません。その場合は /write-a-prd § 4 の「Research document」を参照してください。そこに、該当する項目の照合方法と参照方法が記載されています。教訓を見つけるには、同梱のリゾルバー references/sidecar.sh を使います。まず、コマンドの先頭で SC="<this skill's directory>/references/sidecar.sh を設定し、bash "$SC" solutions-dirs が表示するすべてのディレクトリを読みます。この方針の管理元はそれらのディレクトリです（ヘッダーに記載されています）。PRD が参照する各パスについて、sidecar.sh require <path> --from "PRD #<n>" で確認します。MISSING: の行は、それ自体が古くなった成果物なので、ステップ 3 に記載します。目標は具体的に示すことです。「シェイピングが古い」ではなく、「Ably が無料プランの上限を引き上げ、Pusher が引き下げたため、調査での Ably と Pusher の比較判断が誤っている」と説明します。

診断を 1～2 文でユーザーに伝え、次の質問を 1 つだけします。「変更内容についての理解は合っていますか？」 いいえの場合は、診断を調整します。はいの場合は、次に進みます。

3. 古くなった成果物を列挙する

作業を再開する前に対処が必要な、永続的な成果物をすべて列挙します。具体的に、正確な Issue 番号とファイルパスを示してください。よくある古い成果物は次のとおりです。

• 調査アーカイブ項目（PRD が参照する絶対パス。保存先は /research の Phase 5c に記載） — 最も早い段階で影響を受けるスキルが /shape の場合は、アーカイブ項目をそのまま残します。これは特定時点の記録であり、後続のスキルが参照しなくなるため、誤解を招くことはありません。最も早い段階で影響を受けるスキルが /research の場合は、/research を再実行して、古い項目に代わる日付入りの新しい項目を作成します。以前の記録は背景情報としてアーカイブに残します。アーカイブ項目は後戻りの際に削除しません。リポジトリの外にあり、保持コストもかからないためです。
• PRD の GitHub Issue — 問題と Appetite が変わらない場合はその場で更新します。PRD 全体を再構成する場合は、コメントを残してクローズします。
• スライスの GitHub Issue — PRD を再構成する場合は各 Issue にコメントし、置き換え済みとしてクローズします。特定のスライスが引き続き有効な場合に限り、コメントを残してオープンのままにします。
• 計画またはコンテナのマイルストーン — 通常はオープンのままにします。実際の成果物は、マイルストーンに紐づく機能 Issue またはスライスの Issue です。
• ソリューション項目（リポジトリ内またはサイドカー内）— 今回の状況から記載された教訓が誤りだと判明した場合は、古い項目として明示します。ただし、ユーザーの確認なしに削除してはいけません。
• オープンな PR — 古い成果物に基づく PR の場合は、後戻りの理由をコメントしてクローズします。コードは正しいものの、問題の捉え方が誤っているだけの場合は、オープンのままにします。
• 作業中の機能ブランチ — 通常は保持します。ブランチはコードの履歴であり、永続的な計画成果物ではありません。

各成果物について、名称、対応内容（削除、既存の内容を更新、コメントを残してクローズ）、および 1 行の理由を記載します。完全な一覧を番号付きの計画としてユーザーに提示します。

4. クリーンアップを進める

成果物を1つずつクリーンアップします。それぞれについて、次の手順を実行します。

1. これから何をするのか、なぜそうするのかを伝えます。
2. ユーザーに確認を求めます（質問は1つです：「これを実行してもよろしいですか？」）。
3. 実行します。適切に gh issue close、gh issue comment、またはファイルの直接削除を使います。
4. 次に進みます。

クリーンアップをまとめて1回の確認で済ませてはいけません。各成果物は小さく、元に戻せる判断であり、まとめて確認すると、微妙な間違いを見落とす可能性が高まります。1つずつ確認する手間はわずかですが、誤ったイシューをクローズする代償は現実のものです。

ユーザーがいずれかの成果物について迷っている場合は、それをスキップし、最終サマリーで「要確認」として示します。無理に進めてはいけません。

5. 引き継ぐ

クリーンアップが完了したら、次の内容を明確に伝えます。

• ユーザーが次に実行すべきスキル（Step 2で影響を受けた最も早いスキル）
• そのスキルに持ち込むコンテキスト（きっかけ、診断結果、参照用に保持した成果物）
• 再実行を特定の対象に絞るべきかどうか（ほとんどの差し戻しでは対象を絞ります。「リアルタイムプロバイダーの判断を再調査する」のようにし、全面的な再実行にはしません）

会話が長くなった場合は、新しいセッションで次のスキルを始めることを提案します。締めくくりのサマリーが、簡潔な引き継ぎになります。

このスキルの対象外

• バグのトリアージツールではありません。 きっかけがテストの失敗や実行時エラーである場合は、まず /qa を使って、バグなのか古くなった成果物の問題なのかを診断してください（/qa のイシューごとの詳細確認では、根本原因の特定が必要な場合に /triage-issue に委譲します）。
• リファクタリング計画ツールではありません。 古くなった上流の成果物がなく、アーキテクチャ上の課題がきっかけの場合は、/improve-codebase-architecture または /request-refactor-plan を使ってください。
• 全面的な再実行ではありません。 適切な修正では、すべてを再実行するのではなく、変更があった箇所に絞って再実行します。「Xを形にしたが、Yが間違っていたため、Zを再調査する」が目標です。
• Pipeline Recovery リファレンスの代わりではありません。 references/SYSTEM-OVERVIEW.md の Pipeline Recovery セクションは、Skill Kit におけるバックトラッキングの意味を説明する正式な記述です。このスキルはそのリファレンスを呼び出し可能にします。詳しくは、リポジトリの原文 https://github.com/chrislacey89/skills/blob/main/SYSTEM-OVERVIEW.md を参照してください。

引き継ぎ

• 想定される入力： 上流の成果物を無効にしたきっかけと、影響範囲を診断するための十分なコンテキスト
• 生成されるもの： 古くなった成果物を削除、更新、またはクローズしたリポジトリの状態と、メインパイプラインへの明確な再開ポイント
• メインパイプラインへの再入ポイント： 診断結果に応じて /shape、/research、/write-a-prd、/prd-to-issues、または /execute
• 次に行うこと： ユーザーは、推奨された前段のスキルを変更箇所に絞って実行します。修正の規模が大きい場合は、新しいセッションで実行します。