Brief Yourself 1.0.1｜Personal Context Layer

Brief Yourself 1.0.1 は現在のプロダクト、Skill エントリポイント、Agent アイデンティティ、アクティブスキーマアイデンティティです。現在の schema_version は 1.0.1 です。過去の 0.4 は古いアーティファクトと過去の説明にのみ残されており、アクティブスキーマではありません。

トリガーと位置づけ

ユーザーが自分自身を知りたい、Agent にもっと自分を理解させたい、最近の変化を確認したい、または調整済みの個人情報を下流タスクで使用したい場合に、この Skill を起動します。

Brief Yourself は、ユーザーが校正に参加し、用途に応じてコンパイルされ、様々な Agent harness に持ち運べる Personal Context Layer です。Personal Context Store は個人コンテキストの canonical source です。Context View は特定タスクへの凍結入力、Context Patch はタスク終了後にユーザーに確認される候補還流です。

Codex Memory、rollout、プロジェクトドキュメント、その他 harness memory は、明示的な許可を得た場合にのみ候補 evidence として使用できます。これらは自動で Store にインポートされたり、confirmed Claim としてカバーされたり、canonical source になることはできません。Brief Yourself は rollout、consolidation、retrieval、thread、汎用メモリ注入プロセスを複製しません。

非目標とハードバウンダリ

汎用履歴ライブラリ、ベクトル検索、心理診断、または「真の人格」判定は行いません。
Harness Memory を Personal Context に変換したり、静かな双方向同期を行ったりしません。auto_import_harness_memory は false でなければなりません。
1.0.1 の現在のバージョンでは subject.type = person のみ実装されています。Organization Context は共通の Envelope による隔離境界のみ予約されており、この Skill 内で Team Context Store は実装しません。
個人プロファイルを許可なく雇用、信用、保険、医療、その他高影響の自動意思決定に使用してはなりません。
実際の Personal Context、プライベートテストデータ、または履歴資料は、ユーザーが最初にこの会話で明示的なソース承認を完了しない限り読み取りません。
個人情報は宣言的 Claim として書き、将来の指示を上書きするコマンドとしては書きません。プロセスと操作ルールは Skill またはプロジェクトドキュメントに属します。

Session Contract：まず約束し、それから探索

プロファイル作成または更新時には、まず Depth、Evidence、Pace を選択します。最初の探索質問の前に、この Session Contract を完全に表示し、ユーザーが受け入れるか調整するのを待ちます。受け入れ前に経歴、価値判断、その他探索内容を要求してはいけません。

Contract は最低限以下を説明します：目標；Depth、Evidence、Pace；カバーする次元と除外する次元；最大プロンプト数、ユーザーラウンド数、予想所要時間；読み取り予定のソースとその範囲；成果物；Personal Store をアーカイブするかどうか、下流で別名保存可能かどうか；一時停止、スキップ、削除の方法。ユーザーが「開始」と言った場合は推奨値を使用します。現在の Session は上限または停止条件のいずれかに達した時点で終了します。探索を継続するには新しい Contract を結ぶ必要があります。

Depth	最大プロンプト	ユーザーラウンド	予想時間
Quick	5	2–3	5–10 分
Standard（デフォルト）	8	3–4	15–25 分
Deep	12	4–5	30–45 分

History-assisted は Evidence modifier に過ぎず、選択された Depth の上限を全て継承する必要があります。第 4 の深さになったり、Session を延長したりできません。ユーザーが疲労を表明した場合、残り問題数を尋ねた場合、長すぎるとフィードバックした場合、または既存の資料で最低限十分なプロファイルが形成できている場合は、ただちに新たな質問を停止して統合し、スクリプトを完了するために追及し続けてはいけません。

実行フロー

操作の決定。 プロファイル作成/更新、Task View 生成、Patch レビュー、または Inspect/Export を選択。最初に今回の用途と必要最小限の範囲を説明します。
読み取り承認の取得（承認カード）。 履歴、プロジェクトファイル、履歴書、公開資料または Harness Memory を読み取る前に、references/source-consent-and-disclosure.md に従ってソース、範囲、目的、外部転送、保存場所、削除方法を表示し、明示的な承認を待ちます。承認カードは読み取り前の同意画面であり、この reference によって制約されます。register-source コマンドとは別物です—register-source は読み取り後、ユーザー承認を得た長期的ソース登録の入口です。現在の会話とユーザーが自発的に提供した資料についても、実際の使用範囲を記録します。
必要に応じた証拠収集。 まず現在の回答とユーザーが自発的に提供した資料を使用します。履歴は既知のギャップのみ必要に応じて読み取り、バッチインポートはしません。Harness Memory からの内容は候補 evidence のみを形成し、校正待ちとしてマークされなければならず、直接 confirmed Claim にはできません。
インタビューと校正。 references/interview-and-calibration.md に従って予算を管理します。具体的な経験、選択、行動から始め、段階的に Calibration Card を表示し、ユーザーに確認、書き換え、拒否、または未決のままにすることを許可します。
フラットな Claim 候補の形成。 Store には claims[] のみがあります。domains[] はラベルであり、物理的な階層ではありません。新しい認識はデフォルトで user_status: unreviewed の Domain 候補であり、一度の Session で Core に昇格しません。Core Summary は確認済み、有効、かつクロスシナリオでのサポートがある Claim からのみ導出され、個別に保存されることはありません。
凍結 View の生成。 用途、正確な主体/実行者/オーディエンス、必要最小限の Claim に基づいて View をコンパイルします。完全オブジェクト、source_revision、作成時刻、TTL、権限を一緒に凍結します。その後の Store の変更が既存の View を静かに変更することはありません。
Patch は一時保存のみ。 タスクで得た新しい認識は pending Patch のみ生成し、戦略や単発のトークは task_strategies_not_for_merge に置きます。references/context-view-and-patch.md に従って項目ごとにレビューします。ユーザーが特定の patch_id と Proposal を明示的に承認して初めて、runtime は apply できます。

証拠と認識の最低ルール

fact、self_report、observation、inference は別々に記録します。推論を事実に書き換えてはいけません。
証拠ソース、反証、適用範囲、変化、矛盾（Tension）、不明を保持します。記録がないことは、発生しなかったことを意味しません。
Tension と Unknown は依然として現在の canonical Store のトップレベルエンティティであり、View への完全凍結オブジェクトとしても入ります。これらは永続的な session-only ではありません。現在の Patch schema/runtime の Proposal は Claim の add、update、challenge、retire のみをサポートし、Tension/Unknown の追加または更新エントリはありません。セッションで新たに発見されたものは「未永続化候補」として提供され、将来の明示的な合意を待ちます。Store に静かに書き込んだり、Claim に偽装したり、task_strategies_not_for_merge に詰め込んだり、長期保存されたと主張したりしてはいけません。既存の移行/Store 中の Tension/Unknown は読み取り可能であり、必要に応じて View に入れることができます。将来の書き込みエントリは別途 schema/runtime/approval を必要とし、このラウンドでは実装しません。
MBTI、DISC、または一度の回答を証拠の代わりにしてはいけません。一度のタスクの進行状況、JD キーワード、一時的な戦略、Agent 操作の好みを長期 Claim に書き込んではいけません。
新しい認識はまず候補 Domain に入ります。Core は派生サマリー資格としてのみ機能し、一度のタスクで直接昇格することはできません。長期書き戻しは常にユーザーレビューを経ます。
sensitivity は内容の機密性を説明します。disclosure はオーディエンス、目的、および下流での永続化許可を説明します。これらは互いに代替できません。デフォルトでは private と restricted を除外します。
subject は person に固定されます。team-agent またはその他明示的に承認されていない実行者/オーディエンスはデフォルトで拒否されます。「同じワークスペース」であることを理由に個人の承認を推測してはいけません。

Runtime コマンド

runtime は 17 個の操作名を登録しています：14 個の正式な V0.4 操作は以下の 5 つのグループにルーティングされます。2 個の移行コマンドは移行シナリオでのみ使用されます。list は list-patches の互換エイリアスであり、独立した機能ではありません。パラメータは常に --help を優先します。このエントリは未確認の flags を前提としません。これらのコマンドを実際の Store の移行や dogfood に使用してはいけません。別途許可がない限り。詳細なパラメータと副作用については references/store-operations.md を参照してください。

Store ライフサイクル

python scripts/context_store.py init --help
python scripts/context_store.py validate --store <store>
python scripts/context_store.py inspect --store <store>
python scripts/context_store.py derive-core-summary --help

init は新しい Store を作成します。validate は完全検証を行い、静かに修正しません。inspect は revision、カウント、および未レビューの Patch を表示します。derive-core-summary は条件を満たす確認済み Claim からのみ非 canonical サマリーを導出します。

Source 登録

python scripts/context_store.py register-source --help

register-source は Evidence Source の唯一の書き込みエントリであり、consent は explicit でなければなりません。これは読み取り承認画面ではありません。読み取り前の承認カードは references/source-consent-and-disclosure.md によって制約されます。ユーザーが読み取りを承認し、長期登録を承認した場合にのみ、このコマンドを実行します。

View

python scripts/context_store.py create-view --help
python scripts/context_store.py validate-view --help

create-view は凍結 View をコンパイルします。機密範囲と制限はこの段階で disclosure とユーザー承認によって決定されます。validate-view は検証のみを行います（期限切れ、用途、機密レベル、権限構造）。変更も制限の作成も行いません。作成後はリフレッシュしません。

Patch

python scripts/context_store.py stage-patch --help
python scripts/context_store.py list-patches --help
python scripts/context_store.py apply-patch --help
python scripts/context_store.py reject-patch --help

stage-patch は pending のみ書き込みます。apply-patch は具体的な Patch レビュー、--approve、および actor 確認が必須です。reject-patch は Canonical Context を変更しません。

エクスポートと削除

python scripts/context_store.py export --help
python scripts/context_store.py purge-plan --help
python scripts/context_store.py purge --help

export はデフォルトで public のみエクスポートします。purge は不可逆的な忘却です。まず purge-plan でプレビューし、--plan-token を取得します。実行時には --confirmed-by と --approve も必要です。プレビュー後に Store に変更があると token は無効になります。このエントリはこれらの制約を回避する実行可能な削除例を提供しません。完全な境界については references/store-operations.md を参照してください。

履歴移行ルート（移行シナリオのみ読み取り）

python scripts/context_store.py migrate-v02 --help
python scripts/context_store.py preview-migrate-v03 --help

これら 2 つのコマンドは V0.2→V0.3 および V0.3→1.0.1 の履歴移行のみにサービスし、通常タスク機能には属しません。まず references/migration-v0.3-to-v1.0.1.md を読み、そのプレビュー、レビュー、別名保存、ロールバックの境界に従って使用します。migrate-v02 は入力パスを書き換えるため、ユーザーが作成した明示的なコピーに対してのみ実行します。V0.3→1.0.1 は読み取り専用プレビューのみ許可します。

C File Adapter：凍結 View のみ受信

C パッケージの scripts/adapters/codex_file_adapter.py は単方向の File Adapter です。既に生成された凍結 View JSON のみを読み取り、Envelope、TTL、主体、用途、allowed_use、および各含まれる Claim が principal.id と audience[] 内の各受信者の両方を許可しているかを検証します。失敗時は fail-closed し、拒否された個人の本文は印刷しません。Personal Context Store、Codex Memory、rollout、ネットワークリソースを読み取らず、Store、Harness Memory、または長期 Context に書き戻さず、オプション出力も入力 View を上書きできません。

C の実際の --help に従って、以下の概念コマンドを確認しています。--expected-audience は呼び出し側が提供する繰り返し可能なサブセットバインディング（repeatable subset binding）です。各期待される type:id は凍結された view.audience に存在しなければなりませんが、呼び出し側が全 audience を列挙する必要はないため、audience equality/exhaustive assertion ではありません。この呼び出し側バインディングはセキュリティ不変条件を変更しません。このパラメータが渡されるかどうかに関わらず、adapter は各含まれる Claim について、disclosure が principal.id、View Envelope 内の全ての audience recipient IDs、目的をカバーしているかをチェックしなければなりません。サブセットパラメータは disclosure を緩和できません。--purpose-approved は今回の具体的な目的が明示的に承認されたことのみを示します：

python scripts/adapters/codex_file_adapter.py --view <view.json> --expected-purpose <purpose> --expected-task <task> --expected-principal-id <principal-id> --expected-audience type:id --allowed-use <allowed-use> --purpose-approved

Adapter の出力は現在のタスク向けの Markdown/JSON 適応結果であり、新しい Store、Memory、または書き戻しの資格情報ではありません。タスク終了時も pending Patch のみ生成されます。Markdown コンパクト出力は、各 Claim の user_status、confidence、status、該当する scope、evidence_refs、counterevidence_refs、および空でないキーとなる時間フィールドを保持します。ソース ID のみ表示し、証拠原文、notes、source raw は展開しません。未レビューの Claim は review=unreviewed / review=unresolved として明示的に表示され、無条件の確定事実に圧縮されません。Store と Adapter は scripts/view_validation.py の Store なし View 検証カーネルを共有します。それぞれがその上で Store ソース参照または呼び出し側バインディングチェックを追加します。

References ルート

正式パッケージは以下の 7 つの reference のみを保持し、それぞれこのエントリから到達可能です。読み取りのタイミングは以下の通りです：

references/interview-and-calibration.md：インタビュー開始前に読む。Session Contract、3 段階の予算、Question Map、Calibration Card、疲労停止、Claim 分類。
references/source-consent-and-disclosure.md：履歴/プロジェクト/履歴書/Harness Memory の読み取り前に読む。現在唯一の同意と開示に関する事実源：承認カード、候補 evidence、機密度、開示、person/team 分離、高影響境界。承認カードはここに属し、register-source には属しません。
references/context-view-and-patch.md：View のコンパイルまたは Patch のレビュー時に読む。現在のバージョンの Context Envelope、完全凍結オブジェクト、TTL、開示マッチング、Patch の一時保存と承認。
references/harness-boundaries.md：Harness Memory 境界または File Adapter が関係する場合に読む。Harness Memory、Personal Context、Task Context の境界、および File Adapter の envelope/disclosure と expected-audience バインディングルール。
references/personal-context-model.md：Store 構造のセマンティクスを確認する必要がある場合に読む。Personal Context Store のトップレベルエンティティ、証拠モデル、View/Patch の還流境界、バージョンセマンティクス。
references/store-operations.md：runtime コマンドを実行する前に読む。14 個の 1.0.1 操作と 2 個の移行コマンドのパラメータ、副作用、ファイルシステム制限、purge 境界、復元方法。
references/migration-v0.3-to-v1.0.1.md：履歴 V0.3→1.0.1 移行シナリオのみで読む。読み取り専用、metadata-only preview、no-chain 移行ルート。古い 0.4 は履歴入力と古いアーティファクト識別子としてのみ残されています。

Assets ルート

3 つの 1.0.1 テンプレートと同名スキーマがペアになっており、対応するオブジェクトを構築または検証する際に読み取ります：

assets/templates/personal-context-store-v1.0.1.json：Store 構造ベースライン。assets/schemas/personal-context-store-v1.0.1.schema.json と組み合わせて使用。init 後に Store を手動で構築または検証する際に参照。
assets/templates/context-view-v1.0.1.json：凍結 View 構造ベースライン。assets/schemas/context-view-v1.0.1.schema.json と組み合わせて使用。View をコンパイルまたは検証する際に参照。
assets/templates/context-patch-v1.0.1.json：Patch 構造ベースライン。assets/schemas/context-patch-v1.0.1.schema.json と組み合わせて使用。Patch を一時保存またはレビューする際に参照。

過去の V0.3 テンプレートと旧 references は正式パッケージから移動され、プロジェクト archive/1.0.1-moved-out/ に保存されています。古い 0.4 アーティファクトも releases/ にのみ残されており、現在のプロトコルの一部ではなく、リリース ZIP に戻してはいけません。

成果物と終了の言葉

操作に応じて、Human Brief、候補 Claim、Tension/Unknown、凍結 View、または pending Patch を成果物として提供し、ソース範囲、カバーされていない項目、機密境界、次回検証すべき質問を列挙します。終了時には明確に述べます：これは現在の承認済み資料に基づく、現時点での作業用プロファイルです。ユーザーはいつでも修正、使用制限、拒否、削除が可能です。

Bagel-EW/brief-yourself

brief-yourself とは？

お気に入りのAIに質問する

ドキュメント