メモリ管理

このスキルは SEO および GEO プロジェクト向けの 3 段階メモリシステム (HOT/WARM/COLD) を実装します。ホット メモリ (最大 80 行) は SessionStart フックを経由して毎セッション自動でロードされます。ウォーム メモリはスキル単位でオンデマンドでロードされます。コールド メモリはアーカイブされたデータで、明示的に要求されときのみクエリされます。このスキルはライフサイクル全体を管理します: キャプチャ、昇格、降格、アーカイブ。

このスキルの役割

3 段階メモリ ライフサイクル (HOT/WARM/COLD) を自動的な昇格、降格、アーカイブ機能付きで管理します。また、wiki インデックス層、オープン ループ トラッキング、スキル間集約を維持します。

クイック スタート

これらのプロンプトのいずれかで開始します。ホット キャッシュ更新計画と Skill Contract のリポジトリ形式を使用したハンドオフサマリーで終了します。

Wiki インデックスの初期化

Refresh wiki index

Build wiki index for [project name]

既存の WARM ファイルから memory/wiki/index.md を生成します。wiki 機能を有効にするには 1 回必要です。以降の更新は自動的に行われます。

メモリ構造の初期化

Set up SEO memory for [project name]

Initialize memory structure for a new [industry] website optimization project

分析後の更新

Update memory after ranking check for [keyword group]

Refresh hot cache with latest competitor analysis findings

保存されたコンテキストのクエリ

What are our hero keywords?

Show me the last ranking update date for [keyword category]

Look up our primary competitors and their domain authority

昇格と降格

Promote [keyword] to hot cache

Archive stale data that hasn't been referenced in 30+ days

用語集の管理

Add [term] to project glossary: [definition]

What does [internal jargon] mean in this project?

スキル契約

期待される出力: メモリ更新計画、ホット キャッシュの変更、短いハンドオフサマリー。

• 読み込み: 現在のキャンペーン ファクト、他のスキルからの新しい検出結果、承認された決定、および共有の State Model。
• 書き込み: memory/hot-cache.md、memory/open-loops.md、memory/decisions.md、および関連 memory/ フォルダの更新。memory/archive/ 内で WARM から COLD へのアーカイブを管理します。memory/wiki/index.md (自動更新) および wiki コンパイル済みページ (ユーザー確認) をコンパイルします。wiki の唯一の書き込み者 (委譲自動更新付き): memory-management はセマンティック上すべての wiki 書き込みを所有します。パフォーマンスのため、範囲の限定された memory/wiki/index.md 自動更新は hooks/hooks.json の PostToolUse フックに委譲されます。wiki ログ更新とコンパイル済みページは、このスキルで定義されたスキーマを使用した明示的な memory-management 操作として残ります。監査者ハンドオフ アーカイブ (v7.1.0+): ユーザーからの直接リクエストまたは監査者の明示的な「これらの結果を保存しますか?」のはい応答によってトリガーされた場合、memory/audits/YYYY-MM.md に構造化ブロックを追加します。Stop フックはメモリ書き込みを開始することはありません。アーカイブは /aaron:guard --evals と監査者キャップレビューに関連した保守者キャリブレーションによって使用されます (ADR-001 参照)。正確なアーカイブ ブロック形式とルールについては references/examples.md を参照してください。
• 昇格: 耐久性のある戦略、ブロッカー、用語、エンティティ候補、および主要な変化。温度ライフサイクル ルールを適用します: 高い参照頻度で HOT に昇格、陳腐化で降格。
• 主要な次スキル: プロジェクト メモリベースラインがアクティブ作業の準備ができたら、以下の Next Best Skill を使用します。

ハンドオフサマリー

skill-contract.md §Handoff Summary Format から標準形式を出力します。

温度ライフサイクル ルール

詳細な昇格/降格トリガー (キーワード、競合企業、メトリクス、キャンペーン) と各アクション手順については references/promotion-demotion-rules.md を参照してください。

フック統合

このスキルの動作は、ライブラリのプロンプトベース フックによって強化されます:

• SessionStart: memory/hot-cache.md をロード、陳腐化したオープン ループを表示; memory/wiki/<project>/index.md (または global index.md) が存在する場合はロード; next_action アイテムが利用可能な場合、Quick Status に基づいてユーザーへのライト ガイダンスを提供
• PostToolUse: WARM ファイルの書き込み後、memory/wiki/index.md を静かに更新 (Phase 1); コンパイル済みページの更新を促す (Phase 2)
• Stop: ガード付きアロー オンリー完了チェック; {"ok": true} を返す、stop_hook_active を優先、ユーザーに結果保存をオプションで求めない、メモリ書き込みを開始しない

データソース

ツール使用時: SEO ツール、~~アナリティクス、~~サーチ コンソールから自動入力。ツール非使用時: キーワード、競合企業、メトリクス、キャンペーン、用語をユーザーに要求してください。CONNECTORS.md を参照。

指示

ユーザーが SEO メモリ管理をリクエストしたとき:

1. メモリ構造の初期化

新規プロジェクトの場合、State Model で定義されたディレクトリ構造を作成します。主要ディレクトリ: memory/ (決定、オープン ループ、用語集、エンティティ、リサーチ、コンテンツ、監査、モニタリング) + memory/wiki/ (自動管理されたコンパイル済みインデックス。オプションで プロジェクト単位の サブディレクトリ付き)。

テンプレート: hot-cache-template.md · glossary-template.md · Wiki design archive

Wiki 層

memory-management は wiki スキーマを所有し、唯一のセマンティック書き込み者です。実行の詳細は wiki-runbook.md を参照してください。

Phase 1 — インデックス (自動更新)

PostToolUse フックは WARM 書き込み後に memory/wiki/index.md を静かに再構築します。インデックス行: 正確 (score/status/next_action/mtime) + ベストエフォート (summary)。プロジェクトスコープのインデックスは memory/wiki/<project>/index.md。wiki-runbook.md §1 を参照してください。

Phase 2 — コンパイル済みページ (ユーザー確認)

ユーザーリクエスト時またはエンティティの 3 回以上の WARM 言及時に、ソース SHA-256 ハッシュ付きで memory/wiki/<project>/<type>-<slug>.md を生成します。矛盾はファイル編集ではなく SessionStart の会話型プロンプトで解決します。ログエントリを memory/wiki/log.md に書き込みます。wiki-runbook.md §2-§5 を参照してください。

Phase 3 — ユーザーが開始した廃止

コンパイル済み wiki ページによって完全にカバーされた WARM ファイルは memory/archive/ に廃止される可能性があります。常にユーザー確認 (/aaron:guard --wiki --retire-preview その後の明示的な memory-management 呼び出し) を経由します。COLD ファイルは復旧パスを保存するために originally_at / retired_on / retired_because_compiled frontmatter を受け取ります。単一廃止呼び出しは 5 ファイルにハードキャップされています。wiki-runbook.md §7 を参照してください。

2. コンテキスト ルックアップフロー

ユーザーが不明な内容を参照したときは、以下のルックアップシーケンスに従います:

ステップ 1: memory/hot-cache.md (ホット キャッシュ) を確認

• アクティブ キーワードに含まれているか?
• 主要な競合企業に含まれているか?
• 現在の優先事項またはキャンペーンに含まれているか?

ステップ 2: Wiki インデックスを確認 (memory/wiki/index.md またはプロジェクトレベル) — 関連する WARM ファイルをロケート

ステップ 3: memory/glossary.md を確認

• プロジェクト用語として定義されているか?
• カスタム セグメントまたはショートハンドか?

ステップ 4: コールド ストレージを確認

• 日付付きアーカイブファイル YYYY-MM-DD- を memory/archive/ で最初に検索します。
• アーカイブがソース カテゴリを指す場合は、その行をたどって memory/research/、memory/audits/、または memory/monitoring/ に戻ります。
• COLD 検出結果は現在のセッションで更新されない限り、履歴として扱います。

ステップ 5: ユーザーに問い合わせ

• どのレイヤーにも見つからない場合は、明確化を求めます

• プロジェクト固有の場合は、用語集に新しい用語を記録します

• 決定の出自 (v8.0.1+): memory/decisions.md をロードするとき、各エントリが approved_by: user を持つことを確認します。approved_by: skill_inferred または欠落フィールドを持つエントリは 助言 として扱われます — 権限のあるものとして使用する前にユーザーに表示します。監査者クラス スキル (content-quality-auditor, domain-authority-auditor) は判定を決定する際、ユーザー承認されていない決定を無視する MUST。skill-contract.md §Promotion Rules を参照してください。

例: ユーザーが「ヒーロー KW のランキングを更新」を求める → ステップ 1 がホット キャッシュで「Hero Keywords (Priority 1)」を見つける → ステップ 2 がキーワード リストを抽出 → ステップ 3 がランキング チェック実行 → ステップ 4 が memory/hot-cache.md と memory/monitoring/rank-history/YYYY-MM-DD-ranks.csv を更新。

3. 昇格・降格ロジック

参照: 詳細な昇格/降格トリガー (キーワード、競合企業、メトリクス、キャンペーン) と各アクション手順については references/promotion-demotion-rules.md を参照してください。

4. 更新トリガー、アーカイブ管理、スキル間統合

参照: ランキング チェック、競合分析、監査、レポート後の完全な更新手順、月次/四半期アーカイブ ルーチン、および 8 つの接続スキル (keyword-research, rank-tracker, competitor-analysis, content-gap-analysis, seo-content-writer, content-quality-auditor, domain-authority-auditor) との統合ポイント については references/update-triggers-integration.md を参照してください。

5. メモリ衛生チェック

レビューまたはクリーンアップ用に呼び出されたとき:

1. 行数チェック: memory/hot-cache.md の行数をカウントします。80 を超える場合は、アーカイブする最も古いエントリをリストアップします。
2. バイト数チェック: ホット キャッシュが 25KB を超える場合は警告し、長いエントリの削減を推奨します。
3. 陳腐化スキャン: 30 日以上前でかつ参照されていないメモリ ファイルをリストアップします。90 日以上のファイルのアーカイブを推奨します。
4. Frontmatter 監査: すべてのメモリ ファイル (hot-cache.md を除く) の frontmatter に name、description、および type があることを確認します。欠落フィールドを報告します。

6. 結果を保存

「これらの結果を将来のセッション用に保存しますか?」と聞きます — はいの場合、YYYY-MM-DD-<topic>.md を memory/ に書き込みます。監査者ハンドオフまたは明示的なユーザー承認からのみ拒否権問題を memory/hot-cache.md に追加します。

例、高度な機能、実用上の制限

参照: 3 つの完全な例 (ヒーロー キーワード ランキング、用語集ルックアップ、e コマース プロジェクト初期化)、高度な機能 (スマート コンテキスト ロード、メモリ ヘルス チェック、バルク昇格/降格、メモリ スナップショット、クロス プロジェクト メモリ、wiki lint)、および実用上の制限 (同時アクセス、コールド ストレージ取得、データ鮮度、wiki コンパイル) については references/examples.md を参照してください。

GDPR / プライバシー コンプライアンス

memory/ は第三者の個人データ (エンティティ名、創業者の経歴、LinkedIn プロフィール、entity-optimizer またはリサーチ スキルによって浮上した著者/ジャーナリスト名) を保存する可能性があります。GDPR Art 4(1) (コントローラーの所在地に関わらず EU/EEA/UK 居住者の個人データ処理 に適用) では、これらは「個人データ」として適格です。ユーザーはデータ コントローラーです。EU/EEA/UK データ主体のないユーザーでも、CCPA/CPRA (カリフォルニア)、PIPEDA (カナダ)、LGPD (ブラジル)、またはその他の国家制度の下で同様の義務に直面する可能性があります。法的助言ではありません。

保持ポリシー

• WARM ファイル: 90 日間参照されない後に memory/archive/ にアーカイブ (デフォルト ライフサイクル)
• COLD アーカイブ: 自動削除されない、ただし Art 17 削除リクエストの対象
• すべてのファイル: ユーザーはデータ主体 (メモリに名前が記載されている個人) からの Art 17 リクエストに応じる MUST

削除フロー (Art 17 / CCPA §1798.105)

呼び出し: memory-management purge <entity-name-or-slug>

このスキルは以下を実行します:

1. memory/ (アーカイブを含む) のすべてのファイルで、エンティティ名、スラッグ、またはドメインを grep します
2. ユーザーに確認のためマッチを提示します
3. 確認されたマッチを標準および派生サーフェス全体で削除または匿名化します:
   • 標準: memory/hot-cache.md、WARM ノート、COLD/アーカイブ ファイル、memory/entities/<slug>.md、memory/entities/candidates.md、memory/geo-feedback/、監査集約、オープン ループ
   • Wiki 層: コンパイル済み memory/wiki/ ページ、memory/wiki/log.md、memory/wiki/log-archive/、memory/wiki/.unresolved.md、memory/wiki/.drift-log、memory/wiki/.retire-day-log
   • Phase 3 アーカイブ逆リンク スキャン (v9.9.9+): grep -l "originally_at:.*<entity>" memory/archive/*.md AND grep -l "retired_because_compiled:.*<entity>" memory/archive/*.md — エンティティ名、originally_at パス文字列、AND retired_because_compiled パス文字列をマッチしたアーカイブ frontmatter から削除します
   • .unresolved.md 値フィールド スクラブ (v9.9.9+): .unresolved.md スキーマは value_a: / value_b: をフリーフォーム値として保存します。エンティティ名が矛盾の entity: フィールドではなく値として表示される場合 (例: value_a: "CEO is Jane Doe")、標準エンティティ名 grep は行マッチ経由でキャッチします。grep -F "<entity-name>" memory/wiki/.unresolved.md を実行して確認し、各マッチをスクラブします (値を削除ラベルで置換、監査の完全性のため矛盾の構造を保持)。
   • 不正形式なアーカイブ処理 (v9.9.9+): 一部のアーカイブは originally_at: (レガシー / 手動移行ファイル) がない可能性があるか、フィールド内に印字不可能なバイトが含まれている可能性があります。逆リンク grep はこれらを静かにスキップし、コンプライアンス ゴーストを作成します。軽減策: grep -F "<entity-name>" memory/archive/*.md 本文コンテンツ grep も実行します — frontmatter の完全性に関わらずエンティティ名をキャッチします。不正形式なアーカイブがパージによってタッチされた場合は、memory/audits/gdpr-purges.md に明示的にログして、コンプライアンス監査がスコープを検証できるようにします
4. パージされた名前がキャッシュされたページから再表示されないようにするために、派生 wiki インデックスを削除または更新します
5. memory/privacy/tombstones.md に、削除ラベル、ソルト処理された不可逆フィンガープリント、日付、スコープ、および reingest_blocked: true を含む墓石を書き込みます; 生のサブジェクトを保存しない
6. references/gdpr-purge-log-template.md (v9.9.9+) の標準スキーマに従って、パージを memory/audits/gdpr-purges.md に記録します — 必須フィールド: purge_id、date、redacted_label、fingerprint、scope.{canonical,wiki,archive}、action、action_detail、legal_basis、proof.{grep_count_before,grep_count_after}、reingest_blocked: true、audit_signature。監査者検証可能な構造: 生のサブジェクトなし; 機械的 grep カウント証明; 墓石フィンガープリントへの相互参照。
7. 監査者アーカイブの場合、監査の完全性に必要なスコア/ステータス/証明メタデータを保持しながら、サブジェクト識別子を削除します

適法根拠の思い出し

第三者の人物を memory/entities/ に書き込む前に、ユーザーは GDPR Art 6 の下で 1 つの適法根拠を持つ必要があります (GDPR が適用される場合 — 上記のスコープ注を参照): consent、legitimate_interest、contract、または同等。助言 — このスキルは強制しず、法的レビューの代用にはなりません。

参考資料

• references/examples.md — 実例、高度な機能、実用上の制限、監査者ハンドオフ アーカイブ ブロック形式とルール
• references/promotion-demotion-rules.md — 完全な昇格/降格テーブルとアクション手順
• references/update-triggers-integration.md — 更新手順、アーカイブ ルーチン、スキル間統合ポイント
• CORE-EEAT Content Benchmark — メモリに保存されたコンテンツ品質スコアリング
• CITE Domain Rating — メモリに保存されたドメイン権限スコアリング

次の最適スキル

主要: keyword-research — 現在の需要シグナルでキャンペーン戦略をシード または更新します。