stow

stow

この会話を見直し、現時点ではチャットにしか存在しない、長期的に役立つ知識を拾い出し、ユーザーの明示的な指示、プロジェクトに既存のローカル規約、または現在のディレクトリにある非公開の .stow-notes.md フォールバックを通じて記録します。 目標は、蓄積し続ける日誌ではなく、次のセッションに向けた簡潔で最新の運用マップを残すことです。長期的に役立つ知見はすべてディスクに記録し、このスキルが変更するすべてのファイルを、単に長くするのではなく、より正確な状態にします。 エントリには重要度が設定され、記録を重ねるごとに古くなります。古くなった情報は削除せず、ローカルアーカイブに移します。 デフォルトではすべてローカルに記録します。課題追跡システムなどの外部システムを利用するのは、ステップ 3 の明示的な指示ルールに従う場合に限ります。

機能

1. 会話を見直し、まだ記録されていない長期的に役立つ知識を拾い出します。 セッションを読み返し、次のような項目を探します。

   • ユーザーの好み：設定ファイルではなく、会話の中でユーザーがさりげなく述べた作業スタイル、ツール、書式、承認に関する好み。
   • プロジェクトの事実：後から作業する人やエージェントに役立つ、現在のプロジェクトのビルド、テスト、デプロイ、アーキテクチャ、規約に関する情報。
   • 運用上の注意点：このプロジェクトで発見された、陥りやすい問題、回避策、繰り返し起きるミス、または自明でない原因。
   • 継続中の決定事項：採用した方針、却下した選択肢、合意した規約など、このセッション後も有効であるべき決定。
   • 未完了の次の作業：まだどこにも書かれていない、未解決のまま残された項目や合意事項。 知見を記録する前に、README、設定ファイル、既存のドキュメント、コードなど、権威ある情報源にすでに記載されていないか確認します。 すでに記載されている場合は複製せず、情報源と個別に古くなることを防ぐため、その情報を管理するファイルへの一行の参照を記録します。

2. 記録先を決める前に、既存のプロジェクト内規約を確認します。 記録先を決めつけず、実際に存在するものを、おおむね次の順序で確認します。

   • プロジェクトルートまたはその近くにある、CLAUDE.md、AGENTS.md などのプロジェクトレベルのメモリファイル。
   • 実行中のエージェントが複数のプロジェクトで参照する、ユーザーレベル（グローバル）のメモリファイルがあり、読み取り可能な場合はそのファイル。
   • プロジェクトですでに追跡されている、TODO、BACKLOG、NOTES など、またはそれに類する名前の通常のファイル。 このステップの対象はローカルファイルのみです。ここでは課題追跡システムを探したり、その利用を推測したりしないでください。外部への振り分けはステップ 3 で扱います。

3. 各所見は、この固定の優先順位に従って、ローカル優先でルーティングします。

   1. 最優先 - 明示的な指示が勝ちます。 ユーザーがこの会話の前半で、または発見されたユーザーレベルのメモリファイル（手順 4 を参照）に以前記録された継続的な選択として、この種の所見には特定のシステムを使うと明示的に述べている場合は、そこへルーティングします。 これが、イシュートラッカー、ホスト型プロジェクトボード、チケットシステムなどの外部または公開システムへの唯一の経路です。 設定された git ホストのリモート、.github/.gitlab フォルダー、その他トラッカーが存在していそうなシグナルは、それだけではそこに何かを登録する根拠にはなりません - 推測で外部へルーティングしてはいけません。
   2. そうでなければ - プロジェクトまたはユーザーがすでに持っているローカルの慣例。 プロジェクトの事実、運用上の注意点、継続的な決定事項については発見されたプロジェクトメモリファイル。未完了の次のステップについては既存の TODO/BACKLOG/NOTES ファイル。ユーザー設定については発見されたユーザーレベルのメモリファイルをアクセスできる場合に使用します - 到達できればボーナスであり、決して前提や要件ではありません。 これが、所見を追跡対象の共有ファイルまたは現在のディレクトリの外に書き込む唯一の階層であり、それはユーザーがすでにその保存先を確立している場合に限られます。
   3. フォールバック - 現在のディレクトリの .stow-notes.md、すべての所見の種類に対して。 既存の慣例がどれも当てはまらない場合は、場当たり的に場所を決めたり、その場限りのファイル名を考案したりしないでください。 git ワークツリーでは、まず .stow-notes.md がすでにインデックスで追跡されていないか確認します。追跡されている場合は、そこにプライベートな所見を書き込まないでください - ユーザーが安全な保存先を選ぶまでフォールバックはブロックされていると報告します。 そうでなければ、現在の作業ディレクトリに .stow-notes.md を作成または更新します - ユーザーレベルやホームディレクトリのパスには決してしないでください。そうすることで、現在のディレクトリにサンドボックス化されたエージェントでもフォールバックが機能します。 次に、それを git から除外します。現在のディレクトリの .gitignore ファイルに .stow-notes.md の行を追加します - そのパスにある通常のファイルであり、リンクされたワークツリーでは作業ディレクトリの外に解決される可能性がある git の内部除外メカニズムではありません。 その .gitignore の行をステージングまたはコミットするのはユーザーに任せます。このスキルが書き込む他のすべてと同じです。 .gitignore への書き込みすら失敗した場合でも、ブロックしたりエラーにしたりしないでください - それでも .stow-notes.md を書き込み、手動で無視するようユーザーに伝えます。

4. 2 つの既存の慣例の間で本当に曖昧な場合は、一度だけ質問し、その後その回答を覚えておきます。 発見された複数のローカル慣例が所見に当てはまりそうな場合は、その種のメモを今後どこに置きたいかを、ユーザーに一度、率直に尋ねます。 同じことは、ユーザーが 1 つの項目だけでなく今後トラッカーやその他の非ローカルシステムを使うよう明示的な指示を与えた場合にも当てはまります。 回答が得られたら、それを覚えておくことを提案します。ユーザーの明示的な許可を得て、その選択についての短い継続的なメモを、発見された（または新たに合意された）ユーザーレベルのメモリファイルに記録し、このプロジェクトで同じ質問を繰り返さなくて済むようにします。 そのメモを追加する前には必ず尋ねてください - 決して暗黙のうちに慣例を確立しないでください。 既存のものがまったく当てはまらない場合（単に曖昧なだけではない場合）、それは手順 3 のフォールバックであり、質問ではありません。

5. 既存の慣例として実在する場所、ステップ3のフォールバック（およびその .gitignore の行）、またはステップ4でユーザーが承認した保存先にのみ書き込んでください。 プロジェクトに既存の慣例がない共有ファイルやフォルダー、トラッカーカテゴリーを新たに作らないでください。 調査結果の保存先として、スキルを保存、作成、編集してはなりません。「これをスキルに昇格する」という移行方法はありません。既存の .claude/skills/ または skills/ ディレクトリが慣例のように見えるリポジトリでも同じです。 ステップ7のオフロード終了手順によって、このルールが緩和されることはありません。このスキルが提案するのはそのような移行だけです。オンデマンドの保存場所は、スキルによる書き込みではなく、ユーザー自身の変更プロセスを通じて作成します。 フォールバックに書き込めず、ユーザーが新たな慣例を望まない場合は、その旨を明確に伝え、保存先をでっち上げずに調査結果を未記録のままにしてください。

6. 書き込む前に保存先を読み込んでください。必ず内容を確認してから更新し、確認せずに追記してはいけません。 調査結果を書き込む前に、保存先ファイルの現在の内容をすべて読み込んでください。TODO／BACKLOG／NOTES の項目については、タイトルだけでなく既存項目全体を読み込んでください。 次に、既存の内容に照らして調査結果を分類します。新規、重複、既存項目の置き換え、または既存項目が不要になった証拠のいずれかです。 分類に応じた置き換え内容を検討して書き込みます。重複する内容は、すでに記載されている項目に統合します。既存項目を置き換える調査結果は、その項目を書き換えます。不要になった項目は、同じ処理の中で事実が保持されるように更新、アーカイブ、または置き換えます。新しい項目をむやみに追記したり、ファイル全体を無条件に上書きしたりしてはいけません。 ほぼ同じ内容の項目を二つ並べるより、既存項目を一文で書き換えることを優先してください。 置き換えられた本文のうち残す価値があるものは、ステップ7のいずれかの終了手順を通じて保存先から移し、書き換えによって黙って失われず、復元可能な状態にしてください。 メモリーファイルまたは .stow-notes.md に書き込む各項目には、以下の階層契約に従ってマークを付けてください。ただし、既存の TODO／BACKLOG／NOTES ファイルに階層マーカーを追加してはいけません。 実行されていない次のステップが、何かを待っているために本当にブロックされている場合は、何を待っているのかを記録してください。

7. 今回開いたすべてのメモリーファイルを整理してください。調査結果の保存先となったファイルだけではありません。 日付付きの各項目を、以下の階層契約に定める期間に照らして評価します。現在の証拠によって再確認された内容は更新し、古くなったままの内容はアーカイブしてください。 完了済みの時系列情報、古くなったバージョンやパス、一時的なタスク状態、解決済みの選択肢、古い指標、レポート規模の手順など、現在の情報ではなくなったものをアーカイブしてください。置き換えられた主張や重複は、事実が別の場所に保持される場合に限り、統合または削除してください。 重複した文章を残すより、簡潔で最新のルール一つ、または信頼できる情報源へのポインターを優先してください。 現在も有効な固有の事実を、単純に削除してはいけません。そのような情報は、復元可能なコールドティアに出所情報とともにアーカイブするか、オンデマンドで読み込まれる保存先に移すか、その事実を保持する統合によって、必ず保存してください。 これは正確さを保つための規律であり、文章を短くすることが目的ではありません。古い項目は次のセッションに誤解を与え、現在も有効な項目には残す価値があります。 .stow-notes.md のメモに認められる終了方法は、次の5つだけです。ユーザーが承認した共有の追跡対象ファイルへの昇格、見つかったユーザーレベルのメモリーファイルへの統合、ローカルの読み込み対象にならないアーカイブファイルへのアーカイブ、ユーザーが承認したオンデマンド読み込み先（スキルまたはスコープ付き指示ファイル）への移動（スキルではなくユーザー自身の変更プロセスを通じて実行）、または上位の保存先ですでに保持されている重複の削除です。これ以外の方法を新たに設けてはいけません。

8. 正直に「終了して安全」かどうかを伝え、次回セッション用の再開ポインターで締めくくります。 この一巡で確認または検討したファイルごとに、1つの対応を報告します。対応は unchanged、added、rewritten、pruned、archived（項目をローカルアーカイブに移動）、routed（調査結果を別の担当者に引き渡し）のいずれかです。 オンデマンドの保存先への移動を提案していて、まだユーザーの承認待ちである場合は、その旨を明記します。これにより、作業が完了したと誤解されるのを防ぎます。 次に、何をどこに記録したか、何を記録できなかったか（その理由も含む）、会話を終了またはリセットしても安全かどうかを、わかりやすい言葉でユーザーに伝えます。つまり、この一巡で得られた永続化すべき情報がすべてディスク上、または明示的に指定されたトラッカーに保存されており、このチャット内にしか残っていない状態ではないかどうかを伝えます。 まだ記録できていないものがあれば、セッションを完全に安全な状態だと報告せず、その旨を明確に伝えます。 .stow-notes.md に記録した内容がある場合は、その旨を伝えます。また、このファイルは非公開で、このプロジェクト内に限定されることを明記し、ユーザーがより広く共有したい場合にステップ 7 からどこへ移せばよいかを示します。 Git リポジトリでは、実際の無視設定の状況を報告します。.gitignore に行を追加してあり、ユーザー自身によるコミット待ちであるか、書き込みに失敗しているため、.stow-notes.md を Git に無視させるにはユーザーが手動で設定する必要があるかのどちらかです。 .stow-notes.md がすでに追跡対象で、フォールバックが使えなかった場合は、非公開のフォールバックは書き込まれておらず、ユーザーが別の保存先を選ぶか、その追跡対象ファイルを受け入れるまではセッションを安全にリセットできないと伝えます。 ユーザープリファレンスが、ユーザーレベルのメモリファイルが見つからなかったために .stow-notes.md に記録された場合は、さらに次の注意事項を加えます。このプリファレンスはこのプロジェクトにのみ適用され、プロジェクトをまたいで引き継ぎたい場合は、ユーザー自身のグローバルメモリファイルにユーザー自身でコピーする必要があります。 記録を残す本当の利点は今回のセッションではなく、次回のセッションにあります。どのファイルを読み込めば新しいセッションで中断したところから再開できるかを正確に指定した、短くコピー＆ペースト可能な RESUME POINTER で締めくくります。例：To pick this back up in a new session, load: CLAUDE.md (project conventions), .stow-notes.md (private notes, not shared)。 この一巡で実際に書き込みまたは更新したファイルだけを列挙します。何も書き込まなかった場合は、ポインターを省略します。

ティア制：時間とともに失効する項目

マーカーは末尾に付ける簡潔な HTML コメントです。このスキルが扱うすべてのファイルを簡潔に保つため、マーカーのバイト数も意図的に最小限に抑えています。

• `` - aging 項目です。埋め込まれた日付は、最後に再確認された日付です。
• `` - perishable 項目です。埋め込まれた日付は、最後に再確認された日付です。
• `` - 以下のパスの期間設定に対応するヘッダーポインターがあるファイルでのみ使います。いずれかの日付マーカーに /N を付けられます。これは、その項目を再確認せずに評価したパスの回数です。 /N がない場合はゼロです。そのため、継続して確認している項目にはカウンター用のバイト数が一切かかりません。また、期間設定を有効にしていないファイルでは、このマーカーは記録されません。
• `` - デフォルトのティアが pinned ではないファイル内で、明示的に pinned にした項目です。
• `` - 移行専用です。猶予期間を1サイクル使い切った、未確認のレガシー項目を表します。猶予期間は再確認ではないため、日付は付きません。

- The staging deploy needs the VPN profile active or the smoke test hangs. 
- CI is red on the flaky auth test until the pinned runner image updates (tracked in TODO). 
- Always run the schema linter before touching migrations. 
- The staging seed script must run before the fixture import. 

ティア名は、このスキルが各項目をどのように扱うかを示します。

• pinned - 失効せず、ファイルを短くするために削除されることもありません。ユーザーまたは現実の状況が変わった場合にのみ変更されます。
• aging - 有効性を再確認する必要がある項目です。最後に再確認された日付から30日以上経過すると古くなります。古くなった項目は再検証して日付を更新するか、アーカイブします。慣例だけで残すことはありません。
• perishable - 破棄することを前提に記録する項目です。最後に再確認された日付から7日以上経過すると古くなります。また、チケット、バージョン、日付入りの予定など、確認可能な失効条件を本文に記載する必要があります。 確認可能な条件を記載できない項目は perishable ではなく、aging です。

ルール：

• ファイル独自のヘッダーポインターで別のデフォルトが指定されていない限り、ユーザーレベルのメモリファイルのデフォルトは pinned、プロジェクトのメモリファイルと .stow-notes.md のデフォルトは aging です。
• ファイルの pinned デフォルトと一致するエントリにはマーカーが一切付きません。すべての aging および perishable エントリには、ティアを示す文字が付いた日付マーカーが必ず付きます。そのため、時計情報を持つエントリが、マーカーのないレガシー情報と曖昧になることはありません。
• マーカーとポインターのバイト数もファイルのコストに含まれるため、設計上、記録管理は最小限に抑えられています。
• このスキルが管理するすべてのメモリファイルには、このスキルを方式の所有者として示す1行以内のヘッダーポインターが付いています。たとえば のようになります。必要に応じて、そのファイルのデフォルトから異なるティアや、ファイルがオプトインする場合のパスの上限も指定できます。たとえば のようになります。 ティアの意味、マーカーの表記、時計の設定はこのスキル内にのみ記載し、ファイルのヘッダーでは繰り返しません。ヘッダーにはオプションを記載しますが、その数値は記載しません。 一度限りの移行時には、マーカーのないエントリしか含まないデフォルトが pinned のファイルにもポインターを追加し、管理対象のすべてのファイルで方式の所有者を明示します。
• エントリの最終補強日を更新するのは、現在のセッションでその事実が使用、確認、または再導出されたという実際の証拠がある場合に限ります。 ファイルに存在するだけでは証拠にならず、メモリを読み直すことも補強にはなりません。
• 上記の日付がデフォルトであり、唯一の時計です。ファイルのヘッダーポインターがパスの上限をオプトインしない限り、各ファイルにはこれらの日付のみを適用します。 日付の時計が一度も作動しないほど頻繁に情報を保存するファイルでは、オプトインしてください。情報の追加はパスごとに発生するため、繰り返し使うエントリは30暦日間補強されずに放置されることがなく、ファイルだけが増え続けます。一方、まれにしか情報を保存しないプロジェクトでは、1回のパスで日付の上限をすでに超えているため、何も得られません。 自分の判断でこのオプトインを追加してはいけません。ユーザーがファイルごとに選択します。
• ファイルがオプトインしている間、そのファイルの aging エントリは、補強されずに評価された10パス、または30日のうち、先に到達した時点で古くなります。perishable エントリは、補強されないまま3パス、または7日のうち、先に到達した時点で古くなります。 そのパスで補強されなかった日付付きエントリはすべて、古さを判定する前にカウンターを増やします。/N のない日付マーカーはカウンターがゼロとして読み取るため、移行は不要です。カウンターをクリアできるのは、実際の証拠に基づいて日付を更新した場合のみです。 オプトインしていないファイルにはカウンターを書き込まず、すでに存在するカウンターも読み取りません。既存の /N は正規化したり削除したりせず、バイト単位でそのまま保持します。
• 古くなった perishable エントリは、名前が示す条件に照らして再確認します。まだ継続中であれば日付を更新し、解決済み、期限切れ、または確認不能であれば、ただちにアーカイブします。
• 風化の判定はこのスキルの実行時にのみ行われます。パスとパスの間には何も起きないため、まれにしか情報を保存しないプロジェクトでは、情報の保存間隔に応じて時計が進みます。
• 古くなったエントリが削除されるわけではありません。古くなったエントリは、元のファイルと同じディレクトリにある .stow-archive.md に移動し、どのセッションからも読み込まれないようにします。アーカイブ記録には、元のファイル名、ティア、存在する場合は補強日、および1行の理由を含めます。 パスの上限そのものが原因でエントリが古くなった場合に限り、補強されなかったパス数のカウンターを含め、理由には正確に unreinforced <N>p を使用します。実行中のマーカーにカウンターが付いていても、暦日の上限やその他の理由でアーカイブする場合は、カウンターを省略します。 Git のワークツリーでは、アーカイブ先に書き込む前に、そのパスがインデックスで追跡されていないことを確認します。 追跡されている場合は、そこに書き込まず、安全な保存先をユーザーが選ぶまでアーカイブできないことを報告します。 それ以外の場合は、アーカイブ先のディレクトリにある .gitignore ファイルに .stow-archive.md の行を追加し、アーカイブした情報を Git で追跡されるファイルに書き込んではいけません。 復元は、検索してコピーし戻すことで行います。
• 既存のマーカーなしエントリは、そのファイルのデフォルトのティアで、年齢は不明です。年齢が不明だからといって問題があるわけではありません。デフォルトが pinned のファイルにあるマーカーなしエントリは、単に pinned であり、風化時計、レガシー猶予サイクル、年齢に基づくアーカイブの対象外です。ただし、統合の対象にはなります。
• デフォルトのティアに時計があるファイルでは、最初のパスで確認できたマーカーなしエントリに、コンパクトな日付マーカーを付けます。確認できない場合は、日付を持たない `` を追加し、存在することを補強として扱わずに、猶予サイクルを1回分記録します。 次のパスでは、現在の証拠に基づいてそのマーカーを通常の日付付きティアマーカーに置き換えます。そのような証拠がなければ、legacy-unvalidated の注記を付けてエントリをアーカイブします。 デフォルトのティアに時計があるファイルで、後から手動編集によってマーカーなしになったエントリにも、同じ移行を適用します。
• 常時読み込まれるメモリファイルが、すべてのセッションで負担するには大きくなりすぎた場合、このスキルは、名前を付けられる状況でのみ必要となる永続的なエントリを、必要に応じて読み込まれる保存先へ移すことを提案できます。ただし、実行はしません。たとえば、その状況が発生したときにのみユーザーのエージェントが読み込むスキルや、対象範囲を限定した指示ファイルなどです。 それぞれの移動にはユーザーの承認が必要です。新しい保存先は、このスキルではなくユーザー自身の変更プロセスで作成し、新しい保存先が存在するようになってから初めて、そのエントリをメモリファイルから削除します。 この作業中、必要に応じて読み込まれる保存先が使用可能になる前に、現在の唯一の事実を削除またはアーカイブすることは決してありません。

このスキルが行わないこと

新しいノート作成システムを考案したり、バージョン管理を初期化したり、ユーザーに代わって何かをステージング、コミット、プッシュしたりすることはありません。.gitignore の行も含め、書き込み内容はすべて作業ツリーに反映されるため、ほかの変更と同様にユーザーが確認してコミットできます。 認証情報、秘密情報、その他の機密情報を記録することはありません。保存先にかかわらず、プレーンテキストで安全に保存できる知識のみを扱います。 ユーザーの明示的な指示がない限り、推論だけを根拠に、課題管理システム、ホスト型ボード、その他の外部または公開システムへ情報を記録することはありません。これはステップ 3 の厳格なルールに従います。