frame-change

Frame Change

コードではなく対話を通じて、生のアイデアを合意された形にまとめます。未確定事項を明らかにしたら、プロダクト判断を信頼してください。インタビューを旅程のように台本化してはいけません。

**この工程の位置づけ：**最初の段階です。Tier 0 は test-first に進み、Tier 1 は specify-behavior のミニ仕様に進みます。Tier 2 では3つすべてを順に進めます。後続のチェックリストを先回りして読み込んではいけません。すでにリリース済みで仕様化されている機能に対する、小規模かつ対象範囲内の変更は amend-feature の対象です。そちらに引き継いでください。

このチェックリストを実施し、セレモニーのTierを声に出して述べるまでは、コードを一切書かず、何もスキャフォールドせず、実装スキルも一切呼び出してはいけません。Tier 0で許可される終了先は `test-first` のみで、Tierを声に出して述べた後に限ります。Tier ≥1では、要件を先に作成して承認を得る必要があります。このスキルが触れてよい成果物は、メモ、用語集（CONTEXT.md）、ADR、ロードマップ（`docs/roadmap/INDEX.md`。ステップ5で `plan-milestones` を介する場合のみ）、およびサブスキルを介した調査メモ、明示的に一時的と記された実行スパイク、リバース機能オーバーレイのみです。どれほど単純に見えるリクエストでも、すべてに適用されます。

考え方	実態
「1行で済む変更なのに、設計するのは手間がかかる」	Tier 0と判断すること自体が設計ステップです。そう述べて先に進んでください。
「考えを整理するために、少しコードを書いてみる」	それは実行スパイクです。契約上、使い捨てにするため、必須のサブスキル run-spike を使用してください。
「スキャフォールドは実装とは違う」	リポジトリの骨組みを作るのは技術スタックの決定です。実装にあたります。
「ほかのサブ機能は対象外だから、Out-of-Scopeにする」	Out-of-Scopeは却下を記録する項目です。後で行う予定の作業は plan-milestones を使って先送りしてください。
「自分で /map-features を呼び出そう」	/map-features はユーザーが呼び出すものです。名前を挙げるだけにしてください。
「INDEXは短いから、120行すべて貼り付けよう」	カタログはクエリ優先です。catalog-query.md が唯一の保存先です。

チェックリスト

まずToDoを作成 — ゲート。 CONTEXT.md を読む、または質問する前に、このスキルの6つのステップを見えるリストに追加してください（ハーネスのToDoツールを使うか、それがなければ最初の返信にチェックリストを記載します）。後続の段階では、それぞれの段階が独自のリストを管理します。各項目は、その 完了条件 を満たしたときにのみチェックしてください。

適切な規模に調整する。 ステップ1の後、明らかにTier 0（誤字、色の変更、文言の変更、動作変更なし、未確認の前提なし）なら、ステップ2を簡潔に行い、ステップ3～4を省略してからステップ5に進みます。それ以外は全工程を進めてください。ステップ2で動作変更が判明した場合は、Tierを引き上げてください。

1. プロジェクトのコンテキストを調べる

CONTEXT.mdを読みます。docs/specs/INDEX.mdはコンテキストに貼り付けないでください。load-subgraphのcatalog-query.mdを読み込み、実行します（モード、クエリのレシピ、コンテキストの上限、正確なCODE検索）。有効なOBSがあれば、それも含めます。

docs/agents/project.mdがある場合は、Project postureを読みます。Project postureまたは## Teamがある場合は、このファイルと同じ場所にあるproject-posture.mdを読み、厳密に従います。Postureがない場合は、規模の調整をせずに進めます。BandによってtierのルールやIron Lawsが変わることはありません。docs/product/vision.mdがある場合は、そのアイデアがプロダクトの対象範囲内かどうかを明示します。

アイデアがユーザー、成功基準、またはプロダクト原則に関わる場合は、このファイルと同じ場所にあるproduct-context.mdを読み、厳密に従います。

アイデアに関連するコード、ドキュメント、最近のコミットについて、scanサブエージェントを起動します → .skills/<CODE>/scan.md（CODEが決まる前は.skills/_pending-<slug>/scan.md）。 ダイジェストをもとに作業します。サブエージェントを使えない場合は、関連するファイルを少数読みます。docs/agents/project.mdがない場合は、その旨を伝え、configure-repoを提案してから続行します。

ダイジェストにはBlindspotセクションを必ず含めます。具体的には、このリポジトリに根拠を置いた、領域固有の落とし穴、過去の制約、新参者には思い浮かばない質問を記載します。リポジトリへの理解が浅い場合は、ステップ2で最初の希望確認をする前にBlindspotを提示します。

保証の確認 — 安全性を示す言葉をユーザーに伝える前に必須です。すでに依頼に含まれている言葉も対象です。 Safe、atomic、idempotent、exactly-once、never double-、ordered、uniqueについて、各語が耐えなければならない障害と、それに耐えられる根拠となる**file:lineを示します。対象のコードパスで観測可能になる障害（タイムアウト、書き込み途中のクラッシュ、再試行、2人目の呼び出し元）を選び、それ以外は未検証とします。根拠となる行がなければ、その語を述べる際に未検証**と明記し、既知の不明点として記録します。仕組みを説明することは、確認したことにはなりません。3回の実行で、例外処理からキーを削除し、PSPのタイムアウト時にキーを失うidem.release(key)を引用しながら、「返金が二重になることはない」と判断した例があります。

次に、そのアイデアがすでに存在するかを確認します。必須サブスキル：アイデアのキーワードと、スキャンで見つかった候補パスを使ってload-subgraphを実行します。スキーマ1.1の近接カードを提示し、**owns_coverage**を明示します。根拠に基づく主張は、skills/execution/load-subgraph/references/grounded-claims.mdに従います。ネストされたclarify-decisionsのために、有効な取得パッケージを保持します。 完了条件：近接カードとOWNS coverageを提示するか、grounded-claims.mdに従って、空であることとcoverageを明記した「重複なし」を明示します。

**既知事項の一覧（ステップ2の前に必須）。**簡潔な箇条書きを4つ（チャットに記載してもかまいません。.skills/<CODE>/knowns.mdは任意）：

• 既知の既知事項／確定事項 — 決定済みの制約と、必ず維持する振る舞い。
• 既知の未知事項 — 調査、実験、またはユーザーの判断が必要な未解決の質問。
• 未知の既知事項 — ユーザーが好みを認識しているものの、まだ具体化できていない事項。
• 仮定（確定事項ではない） — ユーザーが提案した解決策の形。確定事項として選ばれるまでは、仮定を要件のSHALLに昇格させないでください。

**完了条件：**プロジェクトの概要、アイデアの近くにすでにあるもの、該当する用語集の用語、同じ領域を共有する機能（または該当なし）を1段落で説明し、さらに既知事項の一覧とBlindspotの一覧があること。

2. ヒアリング

このチェックリストに沿って進めます。単一の質問チャネルには、clarify-decisionsのプロトコルを適用します。簡略化したヒアリングを独自に作らないでください。

必須サブスキル：clarify-decisionsを使用します。define-domainは受動的な副作用として維持します（必須サブスキル：define-domainを使用）。

暫定tier 0の場合：ネストされたヒアリングにbrief / tier-0の印を付け、coverageをOFFのままにします。課題、制約を1つ、必ず動作し続ける必要があるものを確認し、新たな事項がなければステップ5に進みます。

依頼が複数の独立したサブシステムにまたがる場合は、詳細化を止め、ステップ5で分解します。

**完了条件：**未解決事項に影響の大きい判断が残っておらず、clarify-decisionsの終了パッケージが確認済みであること。

3. 質問に根拠が必要な場合は寄り道する

フルパスのみ。ティア 0 では省略します。

• 外部の事実、API、ライブラリ、標準、または対象の機能をリリース済み製品がどのように実現しているか → 必須サブスキル：research を使用します（最新のライブラリドキュメントには Context7 MCP を使用します）。
• 「このモデル／フローは実際に適切な使い心地か？」→ 必須サブスキル：run-spike を使用します。

根拠を添えて戻り、判断をユーザーに委ねます。 完了条件： 未解決の質問に、推測で答えていないこと。

4. アプローチを提案する

フルパスのみ。ティア 0 では省略します。 トレードオフのある、実質的に異なるアプローチを 2～3 案提示します。推奨案を最初に示します。YAGNI の観点から不要なものを削ります。選択するのはユーザーです。 アイデアが、リリース済み製品にすでにある機能の場合、最初のアプローチは、その機能を提供する製品とします。research で確認するか、記憶に基づく未検証の情報であることを明記し、その製品が提供する要素をすべて列挙したうえで、このリポジトリでは不要な要素をそれぞれ理由を添えて削除します。過剰な構築につながるのは、何もないところから設計することです。 完了条件： ユーザーがアプローチを選択していること（ハイブリッドも可）。

5. セレモニーのティアを声に出して決める

ティア	該当する場合	その後に行うこと
0	タイポ程度で、動作の変更なし	仕様書なし — test-first
1	半日以内の動作変更	ミニ仕様：修正する REQ + SHALL-CONTINUE-TO ガード
2	複数タスクにまたがる機能	要件 → 設計 → 計画の一式

作業が複数の独立したサブシステムにまたがる場合は、ここで分解します。サブ機能が 2 つ以上ある場合：必須サブスキル：plan-milestones を使用し、すべてのサブ機能を ROAD-N として定義します。却下ではなく、後回しにします。

完了条件： 「これはティア N です。なぜなら……」と述べていること。分解した場合は、すべてのサブ機能を ROAD-N として定義し、最初に着手するものを明示していること。

6. 最終状態

• ティア ≥ 1： 必須サブスキル：specify-behavior を使用します。これ以外の終了方法はありません。
• ティア 0： ティアを述べてから、必須サブスキル：test-first を使用します。

完了条件： specify-behavior を呼び出している（ティア ≥ 1）、またはティア 0 の書き込み引き継ぎが明示されていること。