好みロガー
人々はアシスタントと作業しながら数十の小さな決定を下します：色、ライブラリ、命名規則、「Xはしない」、「オプションB」。そのほとんどは決して書き留められないため、次のセッションで再度尋ねたり、静かに元に戻したりします。このスキルは1つのファイル PREFERENCES.md を維持し、決定が行われた瞬間にその都度記録することで、セッション、ツール、コラボレーターをまたいでも保持できるようにします。
いつ行動するか
読む PREFERENCES.md を、プロジェクトにそれが存在する場合は最初の変更の前に、またデザインや選択肢、ファイルが既に決定している可能性のあるものを提案する前に再度読みます。その内容に従ってください。ファイルに記録されていることについては、ユーザーが自ら話題にしない限り再度尋ねないでください。
書き込む 以下の場合、作業と同じターンでファイルに書き込みます：
- ユーザーが好みやルールを述べた場合（「タブがいい」「常にイギリス英語を使う」「決してmainにコミットしない」）
- あなたが提示した選択肢から選んだ場合（「A」「2番目でいこう」「AとCを混ぜて」）
- 何かのやり方を修正または却下した場合（「これは見た目が悪い」「いや、右に置いて」「それは間違い、…の場合だけ」）、ただし修正内容がどうあるべきかを示している場合に限る
- 以前の決定を変更または撤回した場合
- 試しに何かを試した場合（「これを試してみよう」）：試行中であることを明記して記録する。
記録しないもの：
- 現在のタスクにのみ適用される一回限りの指示（「この変数の名前を変更して」）
- コードや履歴に既に含まれている事実（ファイルレイアウト、インストール済みライブラリ）
- 秘密、認証情報、トークン、または個人データ（住所、ID番号、健康情報）。決定そのものは記録しても、プライベートな値は記録しない：「フッターにユーザーの実名を使う」とは書いても、その名前自体が機密なら書かない
- ユーザーが受け入れていないあなた自身の提案
これが永続的な決定かどうかわからない場合は、記録してください：短い行を追加するコストは、忘れられた選択のコストよりもはるかに小さいです。
ファイルの場所
PREFERENCES.md はプロジェクトのルートに置きます。ただし、プロジェクトのエージェント指示（CLAUDE.md、AGENTS.md、または類似のファイル）が別のパスを指定している場合はその限りではありません。プロジェクトがない場合（単発のチャット）は、ファイルを作成せず、ユーザーの指示に従ってください。
まだファイルがない場合は、templates/PREFERENCES.md（このファイルの隣）から最初の決定とともに作成します。その後、プロジェクトに CLAUDE.md または AGENTS.md がある場合は、その先頭付近に次の行を追加して、将来のすべてのセッションがこのファイルを読むようにします：
PREFERENCES.mdを最初に読み、最新の状態に保ってください：決定が行われたり変更されたりするたびに、その行を編集し、同じターンで日付付きの変更履歴エントリを追加します。
フォーマット
# <プロジェクト名> — 決定事項
このファイルの目的を一行で説明。
## <トピック>
- **<決定の短い名前>:** 決定された内容を平易な言葉で。理由（ユーザーが理由を述べた場合）と日付。（以前：以前の内容とその日付）
## 変更履歴
- 2026年10月17日 — <決定または変更された内容を一行で>（ユーザーの言葉：「…」）
ファイルを有用に保つルール：
- 決定ごとに一行、トピックごとにグループ化。 プロジェクトに合ったトピックを選んでください（製品、デザイン、スタック、ワークフロー、文章作成など）。最初は少数から始め、どのトピックにも当てはまらない決定が出てきたら追加します。
- その場で編集。 決定が変わったら、その行を現在の内容に書き換え、古い選択肢を短い「以前：…」というメモとして残します。矛盾する行を二つ残さないでください。
- すべての変更に対して変更履歴エントリを追加し、最新のものを一番下に、絶対日付（「2026年10月17日」、「今日」や「昨日」ではない）を付けます。相対日付は記述時に変換します。
- 重要な部分はユーザーの言葉そのまま、引用符で短く記録します：後で意味を確定するのに役立ちます。ユーザーの言葉をねじ曲げたり、発言を実際よりも強く聞こえるようにしないでください。
- 理由を述べる ユーザーが理由を述べた場合。理由があれば、後続のセッションでルールが想定していなかったケースに対処できます。
- 決定が指しているものにリンクする： デザイン、Issue、モックアップ、コミットなど。
- 試行中および未確定のものにはマークを付ける： 「（試行中）」「（未確定）」。確定したらマークを削除します。
- 平易に書く。 短い文、ユーザーが使わなかった専門用語は避ける。その人の名前か「その人」を使い、ユーザーが代名詞を指定していない限り、名前から推測しないでください。
リクエストがファイルと矛盾する場合
最も新しい明示的な記述が優先されます。ユーザーがファイルで禁止されていることを今要求した場合は、その要求に従い、行と変更履歴を更新します。ルールを変更する意図があったのか曖昧な場合は、記録された行を引用して短い質問を一つしてください。
ユーザーに簡潔に伝える
ファイルを更新した後は、返信の最後に短い一文でその旨を伝えてください（「これをPREFERENCES.mdに記録しました」）。ファイル全体の要約は不要です。ファイル全体を見せてほしいと言われた場合のみ表示します。
例
ユーザーがあなたが示した3つのサイドバーデザインを選んでいて、「A、でもボタンはアイコンにしたい」と答えた場合。それを作成するのと同じターンで：
## デザイン
- **サイドバー:** コンパクトメニュー；フォルダ一覧は残りの高さを埋めてスクロール；設定とプライバシースイッチは一番下の行にアイコンボタンとして配置（3つの選択肢からAを選択、ボタンはアイコンに）。
## 変更履歴
- 2026年10月17日 — サイドバー：オプションA、下部アクションはアイコンボタン（ユーザーの言葉：「A、でもボタンはアイコンにしたい」）
一週間後、ユーザーが「あのボタンのラベルを元に戻して」と言った場合：
- **サイドバー:** …設定とプライバシースイッチは一番下の行にラベル付きボタンとして配置。（以前：アイコンのみ、2026年10月17日）
- 2026年10月24日 — サイドバーの下部ボタンにラベルが復活（ユーザーの言葉：「あのボタンのラベルを元に戻して」）