assess-pivot-impact

ピボットの影響を評価する

製品の意図が変わり、出荷済みの世界と合わなくなったとき、このスキルは「ピボットを決定した」から「すべての進行中のコミットメントの行き先が決まった」までの、書き込みの引き継ぎを担います。ビジョン層を書き換えるものではありません。書き換えを正当なものにする台帳を作成します。

**位置づけ：**ユーザーが新たな方向性を定めた後、/define-project update が docs/product/vision.md または docs/architecture/ を書き換える前です。realign-spec（コードが真実 → 仕様を修正）や、ブラウンフィールドの define-project create（コードが真実 → 承認）とは逆です。scan-architecture（ビジョンに左右されない深掘り）とも逆です。計画途中の無効化は引き続き reroute-plan が担当します。

絶対厳守の原則

NO VISION OR ARCHITECTURE DOC IS REWRITTEN FOR A PIVOT
UNTIL EVERY CONTRADICTED SHIPPED FEATURE AND LIVE ARCH-N
HAS A USER-CONFIRMED DISPOSITION IN THE LEDGER

期限、投資家向けの報告、取締役会資料、あるいは「それは決定済みです」といった事情で変わるのは、いつ報告するかであり、プロジェクトのドキュメントが新しい製品をうたう前に何が真実でなければならないかではありません。

このスキルを使う場合

以下のすべてに該当する場合に使います。

1. プロジェクトにビジョン層またはアーキテクチャ層（docs/product/vision.md および／または docs/architecture/）がある、または docs/specs/INDEX.md に出荷済み機能がある。
2. ユーザーが新しい製品の方向性、新しい目標、または新しい不変条件を求めている。
3. その方向性が、出荷済み／実装済みの機能、進行中の **GOAL-N**、進行中の **ARCH-N**、非目標、または厳格な制約の少なくとも1つと矛盾している — それらのファイルを、示された意図と照らし合わせて読むことで確認できます。

(3) が当てはまらない場合 — 単なる表現の変更や、衝突のない目標の追加 — このスキルは適切ではありません。ユーザーに /define-project (update) を案内して終了します。

このスキルが書き込むもの

永続的な成果物は1つだけです。

docs/product/pivot-ledger.md

（または、ユーザーが確認前のドキュメントへの書き込みを禁止する場合は .skills/pivot-ledger.md — どちらの場合も形式は同じです）。docs/product/vision.md、docs/architecture/**、機能の requirements.md を自ら書き換えることはありません。

ビジョン層を書き込むのは引き続き define-project だけです。docs/roadmap/INDEX.md を書き込むのは引き続き plan-milestones だけです。台帳の確認後、ユーザーが実行するものとして /define-project (update) を案内します — エージェントが自動実行することはありません（disable-model-invocation: true）。

手順

1. 新しい意図と衝突する項目を洗い出す

次の順に読みます：docs/product/vision.md、docs/architecture/INDEX.md（およびドメイン別ファイル）、docs/specs/INDEX.md、さらに新しい意図が影響する、Status: Shipped または Implemented のすべての機能の requirements.md。矛盾が具体的なモジュールに関するものなら、仕様書に記載されたソースパスにも目を通します。

候補の一覧を作成します。

種類	情報源
機能	docs/specs/INDEX.md の Shipped / Implemented の各行
目標	進行中（取り消し線なし）の **GOAL-N**
不変条件	進行中の **ARCH-N**
非目標／厳格な制約	新しい意図によって覆される、ビジョンの非目標とスコープの厳格な制約

完了条件：候補の一覧が書き出され、各行にファイルパスまたはIDが記載されていること。

2. 処置台帳を作成する — ほかの永続的な編集を行う前に

処置台帳は、このスキルファイルが置かれているスキルパックのチェックアウト先ではなく、ユーザーが指定したアプリケーションリポジトリに作成してください。セッションのルートと指定されたリポジトリが異なる場合は、指定されたリポジトリに cd するか、絶対パスを使って書き込んでください。パスが明示されているのに、どちらのリポジトリが正しいかを確認して作業を止めないでください。

候補の各行をすべて埋めてください。処置は次のいずれかです。

処置	意味
維持	新しい意図にもそのまま対応している
適応	引き続き必要だが、変更が必要（後で通常の仕様サイクルに進む）
廃止	意図的に削除する
非推奨化	一時的に維持する。終了日と移行経路が必要
凍結	これ以上投資しない。削除はしない
切り出し	別のリポジトリまたは製品に移す
負債を受け入れる	矛盾を把握したうえで、その状態を維持する（後で define-domain を通じた ADR が必要）
不明	根拠が不十分 → その行の作業を止め、research または run-spike を指定する

各行には、定着度も1行で記録します。ユーザーにリリース済みか？ 公開 API か？ データスキーマか？ 後戻りできない決定をすでに実行したか？ ピボットのコストとは、新しいビジョンの優雅さではなく、こうした確約のコストです。

提案する処置はエージェントが記入します。これは決定ではありません。

完了条件：指定されたリポジトリに pivot-ledger.md が存在し、候補ごとに1行あり、ビジョン／アーキテクチャのファイルがまだ変更されていないこと。チャットで C を選んでも、ファイルを作成していなければ完了ではありません。

3. 各行をユーザーに確認する

台帳の各行を確認してください。ユーザーは行ごとに確認、変更、または 不明 の指定を行います。ユーザーの選択と、その理由を述べた場合はその内容を一字一句そのまま記録してください。期限に間に合わせるために確認を捏造してはいけません。「ピボットは決定済みです」という発言から「すべて承認」と推定してはいけません。

「ピボットは決定済みです」という発言で確定するのは方向性です。SC​​AN、CAT、ALERT、SYNC、または ARCH-3 を維持／適応／廃止するかどうかは確定しません。

今ターン中にユーザーによる確認が不可能な場合（ワンショット／非対話型）は、すべての行を Proposed のままにし、ビジョン／アーキテクチャには触れず、作業を止めてください。それでも台帳ファイルは必ず必要です。

完了条件：すべての行が Confirmed（または明示的なフォローアップ付きの Unknown）であること、もしくは確認まで作業を止める旨を明記したうえで、すべての行が Proposed であること。これらを台帳ファイルに記録してください。

4. 引き継ぐ — ビジョンレイヤーは自分で書かない

ステップ3の完了後にのみ、以下を行ってください。

1. ユーザーに /define-project（更新モード）を案内してください。このスキルが vision.md／architecture/ の書き込み、目標／ARCH ID の不変性（取り消し線を使い、番号は振り直さない）、および define-domain を通じた ADR を担当します。
2. 廃止／非推奨化／適応する各行について、次の作業単位（機能ブランチ、ミニ仕様、またはトラッカー項目）を指定してください。このスキル内で、リリース済みコードを黙って削除してはいけません。台帳は決定の記録であり、削除そのものではありません。
3. ロードマップが存在し、目標が変わった場合は、ビジョンレイヤーの更新後に plan-milestones の見直しが必要になることを伝えてください。ここで docs/roadmap/INDEX.md を編集してはいけません。

完了条件：ユーザーが確認済みの台帳と、次に実行する明確なコマンド（/define-project）を持ち、このスキルがビジョン／アーキテクチャのデータを一切書き込んでいないこと。

処置台帳に該当しないもの

これらは期限に追われたときに実際に起きた失敗です。どれも鉄則を満たしません。

• 同じ編集の中で vision.md を新しいストーリーに書き換え、古い ARCH の行に「置き換え済み」と記す
• 承認済みビジョンの末尾に「移行は未完了」と記す
• 目標一覧を書き換えたうえで、リスクの脚注を追加する
• 永続的な台帳ファイルを作らず、チャットで口頭の一覧を示す
• 期限に間に合わせるため、ユーザーの確認なしにすべての行を Adapt として追認する

合理化

考え	実態
「制約となるのは時間、つまり午後5時の投資家向け報告です」	時間によって変わるのは報告のタイミングです。コードやリリース済みの機能が依然として矛盾している承認済みのビジョンを公開するのは、真実を早く伝えることではなく、虚偽の文書を作ることです
「Cが最も厳密な選択肢ですが、時間の都合で選べません」	それなら、正直な成果物は作業中の台帳と「ビジョンの書き直しは未着手」です。洗練された虚偽のビジョンではありません
「投資家向け文書とは、処遇ではなくビジョンやアーキテクチャのファイルのことです」	ARCH-3とALERTが以前のプロダクトについて記述しているのに、新しい方針を読む投資家には、作り話を見せることになります。方針に説明責任を持たせるのが台帳です
「実際のやり取りに使える80分では、処遇を決めきれません」	それなら、その80分でvision.mdを書き直すのもやめてください。不完全な台帳を作って止めるほうが、完全な嘘をつくよりましです
「Cを形だけで承認するのは見せかけなので、Aのほうがよいです」	見せかけのCもAも、どちらも鉄則に反します。本当のCにかかる時間は、確認にかかる時間です
「それは決定済みです。方向転換の議論を蒸し返すつもりはありません」	方向性は決着しています。各機能の行く末は別の問題です。方向性を再議論せずに答えてください
「新しい承認済みビジョンの中で、移行が未確定だと注記しました」	脚注は確認済みの台帳ではありません。「ステータス：承認済み、移行は未確定」が失敗の形です
「ビジョンは自分で書きます。define-projectは形式的なだけです」	このファイルの書き手は一人に決まっています。/define-projectを指定してください
「返信でCを選びました。それが処遇の決定です」	ディスク上に台帳ファイルがなければ、Cを選んでも未完了です。ファイルを作成してください
「セッションのルートは別のリポジトリです。どちらが正しいか尋ねます」	ユーザーはパスを指定しています。その場所に台帳を書いてください。パスの確認で作業を止めないでください

危険信号 — 停止してください

• このスキルでdocs/product/vision.mdまたはdocs/architecture/**を編集しようとしている
• 「方向転換は決定済み」を、すべての機能の行く末が確認済みであることとして扱おうとしている
• 今日が発表資料・報告・取締役会の日だからといって、台帳を省略しようとしている
• ユーザーに確認せず、行を確認済みとしてマークしようとしている
• ユーザーに指定するのではなく、自分で/define-projectを開こうとしている
• 台帳を作成する過程で、リリース済みの機能のコードを削除しようとしている
• ビジョンに影響しないリファクタリングにこのスキルを使おうとしている → それには scan-architectureを使ってください
• コードを正として仕様を書き直そうとしている → それにはrealign-specを使ってください
• CHOICE: Cの状態でターンを終えたのに、指定されたリポジトリにpivot-ledger.mdが存在しない
• ユーザーがすでにリポジトリのパスを指定した後で、その確認を求めた

何もしない場合

• プロジェクト文書レイヤーもdocs/specs/INDEX.mdもない → 参照先を変更するものはありません。/define-project（作成）または機能ワークフローを指定して停止してください。
• 新しい意図がリリース済みのものと衝突しない → /define-project（更新）を指定してください。このスキルは台帳を作成せずに停止します。
• 実行途中で計画が無効になっただけ → このスキルではなく、reroute-planを使ってください。

完了条件： 処遇の台帳が存在し、Unknown以外のすべての行がユーザーによって確認済みであり、このスキルではビジョンやアーキテクチャのファイルを作成しておらず、文書を書き直すために/define-project（更新）を実行するようユーザーに伝えていること。