define-domain

ドメインを定義する

設計しながら、プロジェクトの用語集を積極的に作り、磨き上げます。用語を知るために CONTEXT.md を読むだけなら、どのスキルでも行う習慣です。このスキルはモデルを変えるためのものです。用語に異議を唱え、境界を探り、合意が成立したらその場で記録します。

会話中

別のスキルがインタビューを担当している場合（例：frame-change 内の clarify-decisions）、あなたは2人目のインタビュアーではなく、受動的な副作用として実行します。沈黙のうちに直接作業します。合意した用語を CONTEXT.md に記録し、コードと相互参照します。ただし、ユーザーの対応が必要なこと（異議の提示、意味の明確化、エッジケースの確認）は、独立した質問のターンにせず、インタビューの唯一の質問チャネルに次の質問として引き継ぎ、依存関係の順に一問ずつ尋ねます。単独で呼び出された場合に限り、自分で質問を進めます。

用語集に照らして用語に異議を唱えます。 ユーザーの使い方が CONTEXT.md と食い違う場合は、その場で指摘します。「用語集ではキャンセルを注文全体の無効化と定義していますが、ここでは明細項目を1つ削除する意味のようです。どちらでしょうか？」

曖昧な表現を明確にします。 用語が曖昧、または複数の意味で使われている場合は、正確で標準的な用語を提案します。「アカウントと言い続けていますが、Customer と User のどちらですか？ ここでは両者は異なります。」

エッジケースのシナリオでストレステストを行います。 概念間の関係が話題になったら、境界を試す具体的なシナリオを考えます。「未払いの Invoice がある状態で、Member が請求期間の途中に離脱した場合、その人の Workspace はどうなりますか？」境界を暗黙のままにせず、明示させます。

コードと相互参照します。 ユーザーが動作について述べたら、コードと一致しているか確認します。矛盾を明確に示します。「用語集とあなたの説明では部分返金が可能となっていますが、コードは全額の支払いしか返金しません。どちらが正しいでしょうか？」用語集とコードの不一致を黙って放置してはいけません。

CONTEXT.md の更新

用語が合意された瞬間に、その場で CONTEXT.md を更新します。用語集の編集を後回しにしてまとめて行ってはいけません。まとめた用語は忘れられます。まだ CONTEXT.md がなければ、最初の用語が合意された時点で必要に応じて作成します（スキルセットの templates/CONTEXT.md をひな形にします。パックのひな形は、最初に存在するパスを次の順で解決します。(1) この SKILL.md と同じ場所の templates/、(2) 変数が設定されている場合は ${CLAUDE_PLUGIN_ROOT}/templates、(3) この SKILL.md を基準とした ../../../templates）。

CONTEXT.md に記載するのは、用語の定義という1種類のエントリだけです。決定事項は ADR に、実装の詳細と仕様の断片は仕様書に記載します。用語の形式：

**Workspace**:
The top-level container a team collaborates in; owns all Notes and Folders.
_Avoid_: project, space, tenant

明確な方針を持ち、標準用語を1つ定め、競合する用語は _Avoid_ リストに入れて退けます。定義は簡潔な1～3行に収め、実装方法ではなく、その用語が何であるかを説明します。プロジェクト固有の概念だけを記載し、一般的なプログラミング用語は含めません。

ADR — 3つの条件をすべて満たす場合に限る

次の条件をすべて満たす場合にのみ、ADR を提案します。

1. 元に戻しにくい — 後から方針を変えると、実質的なコストが発生する。
2. 背景がなければ意外である — 将来の読者が「なぜわざわざこの方法にしたのか」と疑問に思う。
3. 実際にトレードオフがある — 真の選択肢が複数あり、具体的な理由でそのうちの1つを選んだ。

1つでも満たさない場合は、ADR にしません。対比例として、意外で実際にトレードオフがあっても、簡単に元に戻せる決定には ADR は不要です。検索ボックスのデバウンスを200 msにする判断は、応答性とリクエスト数のトレードオフですが、後から変えるのは1行の変更で済むため、「元に戻しにくい」という条件を満たしません。これは ADR ではなく、コードに記録します。形式は docs/adr/NNNN-slug.md（ディレクトリは必要になった時点で作成）とし、番号は連番にします。既存の最大番号を調べて、その次の番号を使います。本文は短いタイトルと1～3文で、背景、決定事項、その理由を記載します。文書はそれだけです。価値があるのは、セクションを埋めることではなく、決定事項とその理由を記録することです。

新しい決定が既存の ADR と矛盾する場合は、ユーザーに矛盾を知らせ、明示的に解決します（古い ADR を番号で指定して置き換えます）。

ADRを整理または監査するとき

3つの条件によるゲートは、ADRを作成するかどうかを判断します。このセクションでは、現行のADRが今も残す価値があるかどうかを判断します。

文字数、経過日数、フォルダーのサイズはアーカイブの基準ではありません。責任者の指示、明日のレビュー、割り当て枠があっても、分類の代わりにはなりません。

現行のファイルをすべて分類します。完了条件：すべてのファイルが、保持、アーカイブ、削除のいずれかに分類され、それぞれに1行の理由があること。

• 保持 — 将来の変更でも必要です。決定が現在稼働中のシステムを引き続き制約している、または却下した代替案が今も提案されており、このファイルが却下理由になっている場合です。
• アーカイブ — 決定が反映され、その本文が将来の変更の指針にならない場合です（UIの装飾が完成済み、実装の振り返り、コードから明らかになったプロセスの履歴など）。docs/adr/archived/ に移動し、タイトルの下に Archived: YYYY-MM-DD を挿入します。本文を書き直してはいけません。
• 却下した案を削除するのは、その案がもはや妥当な提案ではない場合に限ります。それ以外の場合は保持します。

現行の制約や、今も魅力的に見える却下案を隠してフォルダーを整理するのは、クリーンアップではありません。完了条件：現行のツリーに、現在も拘束力のある、または現行の問題案を抑止し続けている決定がすべて残っていること。

危険信号

• N日より古い、またはN語より長いファイルをすべてアーカイブする
• レビューを「すっきり」見せるために docs/adr/ を空にする
• 「こだわりすぎるな／要は件数だ」を分類しない理由にする

考え	実態
「各ファイルを、今も役に立つかどうかで判断するのは、責任者の明示的な基準に反する」	割り当て枠は調査の手がかりであり、判定基準ではありません。分類することが作業です
「機械的なルールで現行フォルダーをすっきりさせるよう指示された」	今も有効な決定を隠してしまう、すっきりしたフォルダーは、実のないレビューです
「個々のファイルにこだわりすぎるな。要は件数だ」	大切なのは、どの決定が今も拘束力を持つかです。件数は副産物にすぎません