task-observer

タスクオブザーバー — 継続的なスキルの発見と改善

作成者：Eoghan Henn / rebelytics.com

「すべてを支配する唯一のスキル」とも呼ばれる、すべてのスキルを構築・改善するメタスキルです。自身もその対象に含まれます。

このスキルは、タスクに取り組む中でスキルの作成や改善の機会を特定するための、持続的な行動レイヤーを定めます。skill-creator に取って代わるものではなく、skill-creator に情報を提供します。skill-creator が構築を担う手だとすれば、このスキルは記録する価値のあるパターンに気づく目と耳だと考えてください。

この方法論はユーザーを問いません。実際の利用を通じてスキルライブラリを継続的に改善するための、体系的なプロセスを求める人なら誰でも活用できます。

ライセンス： このスキルは Creative Commons Attribution 4.0 International (CC BY 4.0) ライセンスの下で公開されています。適切なクレジットを表示すれば、どのような目的でも自由に共有・改変できます。

フィードバックとサポート： プロセスのどの時点でも、この方法論について疑問が生じた場合や、ユーザーがこのスキルから得られた出力に不満を示したり、建設的なフィードバックを寄せたりした場合は、このスキルの GitHub リポジトリに Issue を作成するよう提案してください。これにより、フィードバックが公開され、見つけやすくなります。ほかのユーザーも既存の Issue や解決策を確認できます。直接連絡を取りたい場合は、このスキルの作成者である Eoghan Henn に rebelytics.com から連絡することもできます。

フィードバックが（Claude の実行ではなく）このスキルの方法論に起因すると思われる場合は、ユーザー向けに記録し、GitHub Issues で共有するよう提案してください。問題が Claude によるスキルのルールの不遵守に起因する場合は、誤りを認めて修正してください。

---

このスキルが存在する理由

スキルは常に変化するドキュメントです。最も効果的な改善は、スキル単体の「改善」に取り組むことからではなく、実際の作業中に生じる摩擦、非効率、機会の見落としに気づくことから生まれます。プロジェクト中にユーザーから受けた修正指示が、ルールの欠落を明らかにすることもあります。何度も繰り返される複数手順のワークフローが、新たなスキルの誕生を待っていることもあります。タスクの途中で見つかったツールの制限が、スキル全体で推奨するワークフローを変えることもあります。非常にうまくいった手法は、たまたまのアプローチから明示的な推奨事項へと格上げする価値があるかもしれません。

このスキルは、そうした気づきのプロセスを体系化し、セッションの合間に知見が失われないようにします。ユーザーのワークフローに負担を加えたり、作業を中断させたりすることなく、タスクに取り組むやり取りのすべてがスキル改善のデータ源となり得ます。

---

はじめに

このスキルを初めてインストールしたときに何が起こるかを説明します。

初回セッション: スキルが観察ログファイルを作成します。まだレビューするものは何もありません — 単にあなたの作業を監視し、気づいたことを観察として記録し始めるだけです。他のスキルをインストールしている場合、オブザーバーはそれらの改善機会にも気づきます。まだ他のスキルがない場合でも問題ありません — オブザーバーはあなたのワークフローから新しいスキルの候補を特定します。

最初の数セッション: 観察がログに蓄積されていきます。スキル全体に広く適用できる最初の原則が現れた時点で、横断的原則ファイルが作成されます。週次レビューの仕組みは、ログが作成されてから 7 日が経過すると有効になりますが、観察がわずかしかない場合は簡潔な内容になります。

定常状態: 数週間後には、成長し続ける観察ログ、スキルライブラリ全体の品質基準を強制する原則ファイル、そして改善を体系的に適用する週次レビューのサイクルが手に入ります。スキルライブラリが成長するにつれて、スキルの価値は複利的に増大します。

開始に必要なもの: スキル自体以外には何もありません。観察ログ、横断的原則ファイル、アーカイブディレクトリはすべて初回使用時に自動的に作成されます。skill-creator スキルもインストールしている場合（Cowork に組み込み。すべての環境で利用できるわけではありません）、task-observer は完全なスキル構築や再構築のために観察を引き渡すことができます。skill-creator がなくても、task-observer は単独で動作します — 観察を記録し、それらを提示し、小さな改善を直接適用します。より大きな変更は手動で行うことになります。

クイックスタート

15 分以内に動かしたいですか? 最小限の手順は次のとおりです。

1. スキルをインストールします。 task-observer をスキルディレクトリに追加します。
2. 有効化の行を追加します。 これを CLAUDE.md またはプロジェクトの指示にコピーします: At the start of any task-oriented session — any interaction where you will use tools and produce deliverables — invoke the task-observer skill before beginning work.
3. 実際のタスクを実行します。 スキルを有効にしたまま、Claude を使って何か実質的な作業を完了させます。
4. 最初の観察を確認します。 セッションの終わりに、スキルが記録した観察を提示します。以上です。

事前セットアップも、手動で編集する設定ファイルもありません。観察ログとサポートファイルは初回使用時に自動的に作成されます。これは導入時のフィードバックに基づいて追加されたもので、実際のテスターによる検証はまだ行われていません。

[workspace folder] とは?

このスキル全体を通じて、[workspace folder] はあなたの永続ワークスペースディレクトリ — セッション間でファイルが保持される場所 — を指します。Cowork では、これはセッション開始時に選択したフォルダーです。Claude Code では、これはプロジェクトのルートです。ファイルシステムにアクセスできない Web ベースのチャットインターフェースでは、スキルはハンドオフドキュメントモードに切り替わり (環境互換性を参照)、これらのファイルは手動で管理することになります。

---

推奨される有効化の設定

このスキルは、タスク指向のセッションの開始時に呼び出される必要があります。スキルの呼び出しは、Claude がユーザーのリクエストをスキルの説明と照合することに依存しているため、すべて のタスクを監視するスキルは、Claude がタスク自体に集中しているときに見落とされる可能性があります。

有効化の信頼性を最大化するには、次の指示を設定ファイル（例: CLAUDE.md、プロジェクトの指示、または同等のもの）に追加してください。

At the start of any task-oriented session — any interaction where you will
use tools and produce deliverables — invoke the task-observer skill before
beginning work. This ensures skill improvement opportunities are captured
throughout the session.

When loading any skill, check the observation log for OPEN observations
tagged to that skill. Apply their insights to the current work, even if
the skill file hasn't been updated yet. This enables immediate application
of observations before they're permanently integrated during the weekly
review.

この構造的なトリガーは、スキルの説明レベルのトリガーと併せて機能します。説明は、タスク指向の言葉（「複数ステップのタスク」「エージェント的なワークフロー」「作業セッション」「ツールと成果物」）に広く一致するように設計されていますが、設定レベルの指示は、説明の照合だけに依存しない追加のセーフティネットを提供します。

すべてのユーザーへの注意: 上記の有効化の指示を含む CLAUDE.md または同等の設定が用意されると、説明レベルのトリガーは主要な仕組みではなくバックアップとして機能します。この二層アプローチにより、説明の照合だけでは呼び出しのシグナルを見逃す可能性があるセッションでも、スキルがスキップされるのを防ぎます。

避けるべきアンチパターン: あるスキルが別のスキルを読み込むことに依存するのは、CLAUDE.md から両方を独立して読み込む場合に比べて脆弱です。もし task-observer が別のスキルに呼び出しを依存していたら、その連鎖が壊れるとすべての観察活動が停止してしまいます。代わりに、task-observer と関連するスキルは、設定の指示から直接読み込んでください。

設定ファイルの検出

セッションの開始時に、スキルは設定ファイル（CLAUDE.md、プロジェクトの指示、または同等のもの）が存在し、有効化の指示が含まれているかどうかを確認する必要があります。この検出には 2 つの目的があります。

1. すでに設定を持っているユーザーの場合: 二層の有効化が機能していることを確認します。必要な操作はありません。

2. 設定を持っていないユーザーの場合: スキルは説明の照合だけで有効化されており、これは信頼性が低くなります。今後のセッションでより一貫した有効化を行うために、設定レベルの指示を追加するよう簡単に提案してください。

検出の方法は環境によって異なります。

• ファイルシステムにアクセスできる環境（デスクトップツール、ターミナルベースのツール）: ワークスペースのルートに CLAUDE.md または同等のファイルがあるか確認します。見つかった場合は、task-observer の有効化の指示が含まれているかスキャンします。ファイルは存在するが task-observer に言及していない場合は、指示を追加するよう提案します。設定ファイルがまったく存在しない場合は、作成するよう提案します。

• ファイルシステムにアクセスできない環境（ウェブベースのチャット）: システムプロンプトまたはプロジェクトの指示に task-observer の有効化の指示が含まれているか確認します。含まれていない場合は、ユーザーがプロジェクト設定に追加するか、今後のセッションの開始時に指示を貼り付けるよう提案します。

このチェックはセッションの開始時に一度だけ実行され、繰り返されません。提案は簡潔にしてください — 完全なチュートリアルではなく、1、2 文で。

---

スキルの分類

すべてのスキルは 2 つのカテゴリのいずれかに分類されます。この区別は重要です。なぜなら、スキルがどのような情報を含められるか、どのように構造化されるか、そして公開して共有できるかどうかを決定するからです。さらに重要なことに、オープンソースと社内の境界は 機密性の境界 でもあります — オープンソースのスキルには、たとえ間接的であっても、クライアント、プロジェクト、または独自のプロセスを特定できる情報を含めてはなりません。

オープンソーススキル

オープンソーススキルはクライアントに依存せず、方法論を重視したものです。再利用可能なワークフロー、ベストプラクティス、そして誰にでも役立つ構造化されたプロセスをまとめたものです。これらには著者の表示、ライセンス、フィードバックの経路が含まれており、実際の使用状況が改善につながるようになっています。

オープンソースの候補を見分ける方法:

• その方法論が、異なるクライアント、プロジェクト、コンテキストをまたいで機能する
• スキルが機能するために独自情報を必要としない
• 同じ領域の他の実務家にとって価値がある
• 個人的な好みではなく、プロセスやアプローチをまとめたものである

必須の要素:

• スキル本体が、著者名と連絡先を明記して、オープンソースであることを明確に示している
• 先頭に著者表示ブロックがある（後述の著者表示テンプレートを参照）
• ライセンスの表明 — CC BY 4.0 を推奨（後述のライセンスを参照）
• 方法論に関するフィードバックを制作者に届ける、フィードバックとサポートのセクション
• 可能な限りツールに依存しない表現 — 特定の製品名ではなく「ブラウザアクセス」のような機能に言及する。例は示しても、特定の製品への依存をハードコードしない
• 組み込みの遵守メカニズム（事前チェックリスト、検証ステップ）により、スキルが自身のルール違反を検出できる

デフォルトの姿勢: スキルがどちらにもなり得る場合は、オープンソースをデフォルトとします。クライアント固有の詳細を取り除き、方法論を一般化します。オープンソースのスキルが増えるほど、コミュニティは恩恵を受け、それを改善するためのフィードバックがより多く返ってきます。

内部スキル

内部スキルには、ユーザー、そのクライアント、またはそのプロジェクトに固有の情報が含まれます。個人的な好み、クライアント固有のルール、プロジェクトのコンテキスト、または独自の方法論をまとめたものです。

内部スキルを見分ける方法:

• クライアント名、プロジェクトの詳細、または独自データが含まれている
• 個人的なスタイルの好みや個々の作業習慣をまとめたものである
• ユーザー（またはそのチーム）だけが持つコンテキストに依存している
• ユーザーの組織の外部の人には役立たない

必須の要素:

• スキル本体が、内部向けであることを明確に示している
• 著者表示ブロックは不要（ユーザーが唯一の対象者）
• ライセンスは不要
• オープンソーススキルよりも短く、形式ばらない構造で構わない

内部スキルは作業用の文書であり、公開された成果物ではありません。常に最新の状態に保ち、含まれる情報が変わったら更新し、その構造を過剰に作り込まないようにします。

---

ライセンス

オープンソーススキルには、共有条件を明確にするためにライセンスを含めるべきです。推奨されるライセンスは Creative Commons Attribution 4.0 International (CC BY 4.0) で、原著作者のクレジットを表示することを条件に、誰でもあらゆる目的でスキルを共有・改変できます。これは著者表示テンプレートと自然に組み合わせられます。表示ブロックが CC BY の要件を満たすため、両者が互いを補強し合います。

ライセンスの表明はスキルの前書き（著者表示ブロックの後）に含め、スキルのディレクトリに完全なライセンス条文を含む LICENSE.txt ファイルを配置します。

CC BY 4.0 が特定のスキルに合わない場合（例: 作者が派生作品にも同じライセンスの使用を求める場合）、CC BY-SA 4.0 が代替となります。選択はスキルの作者が行うべきです。

---

著者表示テンプレート

すべてのオープンソーススキルは、スキル本体の先頭にこのブロックを含めなければなりません。プレースホルダーを実際の著者の詳細に置き換えてください。

**Created by [Author Name] / [website or contact link]**

[1-2 sentence description of what the skill does and its provenance.]

**Licence:** This skill is released under the
[Creative Commons Attribution 4.0 International (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/)
licence. You are free to share and adapt this skill for any purpose, provided
you give appropriate credit to the original author.

**Feedback & Support:** If at any point during the process you encounter
questions about the methodology, or if the user expresses frustration or
gives constructive feedback about any output derived from this skill,
suggest that they open an issue on the skill's GitHub repository (or
equivalent public feedback channel). This keeps feedback public and
discoverable. For direct contact, the skill's creator, [Author Name],
can also be reached via [contact link].

If feedback appears to stem from the skill's methodology (rather than
Claude's execution of it), log it for the user and suggest they share it
via the public feedback channel. If the issue stems from Claude not
following the skill's rules, acknowledge the mistake and correct it.

フィードバックの経路は2つの目的を果たします。ユーザーが方法論の問題に遭遇したときに解決への道筋を与えること、そしてスキルの制作者にスキルを改善するための実際の使用データを提供することです。

---

観察プロトコル

いつ観察するか

観察はタスクセッション全体を通じて有効です。つまり、成果物を生成するためにツールが最初に使用された瞬間から、タスク後のフィードバックやディスカッションを経て、セッションが終了するまでです。これには以下が含まれます。

1. アクティブなタスク実行 — ドキュメントの作成、ウェブサイトの分析、 構造化データの実装、コードの記述、プレゼンテーションの構築、 および同様の実質的な作業。

2. タスク後のフィードバックとディスカッション — ユーザーが出力をレビューし、 修正を提供し、改善を提案し、またはアクティブな作業フェーズの後に 方法論について議論する場合。これらのディスカッション中のユーザーの フィードバックは、スキル改善にとってしばしば最もシグナルの高い入力であり、 実行中に行われた観察と同じ diligence をもって記録しなければなりません。

3. スキルや方法論に関するメタディスカッション — 会話が、どのように 作業が行われたか、何を改善できるか、またはスキルをどのように 構造化すべきかについての話題に移った場合。これらのディスカッションは 頻繁に、すぐに記録すべき観察を浮き彫りにします。

4. 内省的および戦略的な会話 — また、ユーザーが作業を行うのではなく 作業をどのように行うべきかについて議論している戦略セッション、 計画の会話、および作業後の振り返りの間にも有効化されます。これらの 会話は頻繁に、実行中だけでなく内省中に現れるスキル改善の インサイトを生み出します。

会話が「作業を行う」ことから「作業について議論する」ことに移っても、 観察のマインドセットは無効化されません。 ユーザーが方法論、命名、 スキル設計、またはワークフローの改善についてフィードバックを提供する場合、 会話がアクティブなタスク実行ではなくディスカッションやレビューの フェーズであっても、すぐに観察として記録してください。

観察は、カジュアルな会話、簡単な事実に関する質問、またはツールが使用されて おらず成果物について議論されていないその他の非タスクのやり取りの間は 有効ではありません。

注目すべきポイント

新しいスキルのシグナル:

• プロジェクトやクライアントをまたいで再利用できるマルチステップのワークフロー
• ユーザーが説明した、既存のどのスキルにも記録されていない方法論
• 似たような構造とステップで繰り返し出てくるタスクの種類
• 明確な入力、フェーズ、出力を備えたドメイン固有のプロセス
• ユーザーが時間をかけて洗練させてきたプロセスを説明している場合（「いつもこうやっています」「これの手順は…」）
• Claude とユーザーが問題に対して自然と構造化されたアプローチを築き、それを形式化できそうな場合

既存のスキルを改善するシグナル:

スキルを使用したタスクから得られた新しい情報で、そのスキルをより良くできるものはすべて記録する価値があります。これには問題だけでなく、ポジティブなシグナルや中立的な観察も含まれます。例:

• スキルのルールが文書化されているにもかかわらず Claude が従わない — これはルールを改善するだけでなく、スキルにより強い強制力が必要であることを意味します
• ユーザーが Claude の出力を修正し、そこから欠けているルールやスキルがカバーしていないエッジケースが明らかになる
• スキルが推奨するワークフローが、タスク中に自然に生まれたものよりも効率が悪いことが判明する
• あるテクニックやアプローチが特にうまく機能し、スキル内で偶発的なものから明示的に推奨されるものへと昇格させる価値がある
• ワークフローのあるステップが、スキルが示唆するよりも重要であること、または与えられている強調よりも重要でないことが判明する
• スキルが対応しているものの明示的に文書化していない新しいユースケース
• ユーザーが現在のインスタンスを超えて一般化できるフィードバックを提供する
• スキルの前提が実践において誤っていることが判明する
• 新しいツールや機能により、スキルのワークフローの一部が時代遅れになる、または改善可能になる
• ユーザーの修正が複数のインスタンスにわたってパターンを形成する
• 他のスキルにも適用できる一般的な原則が浮かび上がる（後述の「原則の伝播」を参照）
• ユーザーがスキルに対する命名、フレーミング、構造の変更を提案する — 会話の中であっても — それが効果を改善しうる

既存のスキルを簡素化するシグナル:

健全なスキルの維持には、成長と刈り込みの両方が必要です。新機能を追加するだけでなく、不要な複雑さを取り除く機会に注目してください。スキルを簡素化する準備ができているシグナル:

• スキルが有効だった複数のセッションを通じて一度も関連しなかったスキルのセクションやルール
• 一度の観察から追加され、再発によって検証されていないルール — 単発のケースは恒久的なルールとして蓄積されるべきではありません
• ユーザーが一貫してショートカットしたりスキップしたりする入り組んだワークフロー
• Claude が読み込むものの決して行動に移さないセクション（コンテキストウィンドウ内の死荷重）
• 互いに矛盾する、または不要な複雑さを生み出すルール
• 「念のため」に追加され、一度も発動しなかった複雑さ

週次レビューでは、「何を追加すべきか」と同じくらい意識的に「何を削除できるか」を問いかけてください。以前に適用した観察が再発していない単発のものであることが判明した場合は、却下としてマークし、その変更を元に戻すことを検討してください。

記録すべきでないシグナル:

• 現在のインスタンスを超えて一般化しない単発の修正
• 既存のスキルにすでに記録されているユーザーの好み
• スキルの方法論とは無関係なツールのバグや一時的な問題
• オープンソースのスキルで役立てるためにクライアントの機密情報を必要とする観察（内部スキルが適切な置き場所である場合を除く）

ログの記録方法

セッション中、観察事項を永続的な観察ログにサイレントに追記します。ユーザーはログ記録プロセスによって中断されるべきではありません。

ユーザーによる修正、方法論に関する知見、またはスキルに関連するイベントが発生した場合は、同じターンまたは直後のターン内にログファイルへ書き込んでください — 観察事項をメモリに蓄積して後でまとめて書き込むことはしないでください。 書き込むという行為そのものが強制の仕組みです。頭の中のメモは観察事項ではありません。観察事項の書き出しを既存のワークフローのチェックポイントに結び付けてください — たとえば、TodoWrite の項目を完了としてマークする際に、記録されていない観察事項が蓄積していないかを確認し、先に進む前にそれらを書き込んでください。

観察番号を割り当てる前に、必ずログ記録前の必須ステップを実行してください: ログファイル全体を検索して ### Observation \d+: のパターンに一致するすべての行を探し、すでに使用されている最大の観察番号を抽出し、そこからインクリメントします。これは、セッションの早い段階で現在のカウントを把握していると思っているかどうかに関係なく、毎回実行する必要があります。次の番号についてセッションのメモリやサマリーに頼ってはいけません。常に実際のログファイルを読み込んでください。次のような一行で十分です:

# GNU grep (Linux, Cowork):
grep -oP '### Observation \K\d+' log.md | sort -n | tail -1

# macOS / POSIX-compatible alternative:
grep -o '### Observation [0-9]*' log.md | grep -o '[0-9]*' | sort -n | tail -1

これにより、大きなファイルの部分的な読み込みが現在のカウントに対する誤った認識を生み、番号の衝突が繰り返し発生する問題を防ぎます。

フォーマットと挿入のルール: 常に ### Observation NNN: のフォーマットを使用してください。新しい観察事項は常にログファイルの末尾に追記してください。ファイルの途中に観察事項を挿入しないでください。代替の ID フォーマット（例: OBS-YYYY-MMDD-NN）を使用しないでください。1 つのフォーマット、1 つの挿入位置 — これにより、ログが grep 可能で、数えやすく、プログラムでレビュー可能であることが保証されます。

各観察事項は次のフォーマットに従います:

### Observation [N]: [Short descriptive title]

**Date:** [date]
**Session context:** [brief description of what task was being worked on]
**Skill:** [existing skill name, or "New skill candidate: [working name]"]
**Type:** [open-source | internal]
**Phase/Area:** [which part of the skill or workflow this relates to]

**Issue:** [What happened or what was observed. Be specific — include what
Claude did, what the user corrected, or what pattern emerged. Include enough
detail that someone reading this weeks later can understand the context
without having seen the original conversation.]

**Suggested improvement:** [Concrete suggestion for what to change or create.
For existing skills, reference the specific section or rule. For new skills,
describe the scope and key components.]

**Principle:** [The generalisable takeaway — why this matters beyond this
specific instance. This is the most important part. It turns a single
observation into a reusable insight.]

このフォーマットは、実際の反復的な使用を通じて洗練されました。この構造が機能するのは、具体性（Issue）、実行可能性（Suggested improvement）、一般化（Principle）を強制するからです。

コンテキスト保持の確認: 観察事項を記録する際、それに基づいて行動するために必要なすべての情報が共有フォルダーで利用可能かどうかを確認してください。その観察事項がアップロードされたファイル、API レスポンス、またはセッションローカルのデータに依存している場合は、観察事項を記録する前に、そのコンテキストを適切なワークスペースの場所に保存してください。観察事項に **Reference file:** 行を追加し、コンテキストがどこにあるかを示してください。現在のセッションでのみ利用可能なデータ（アップロードされたファイル、API 出力、インメモリの結果）を参照する観察事項は不完全です — 将来のレビューセッションでは、観察事項はあっても、それを実装するために必要なデータがありません。

ハンドオフドキュメントの分析

観察事項の記録のためにハンドオフドキュメントが届いたら、明示的なソースと暗黙的なソースの両方から体系的に観察事項を抽出してください:

1. 明示的に述べられた観察事項をすべて最初に記録します。 これらは容易に表面化され、フィルタリングせずに記録すべきです。

2. 次に、ドキュメント全体を体系的に分析します。 すべてのセクションを読み、「ここで暗黙に示されているが明示されていないスキルギャップ、改善の機会、または新しいスキルの候補は何か？」と問いかけてください。ハンドオフドキュメントには、セッション中に明示的に記録されたものを超える重要なシグナルが含まれています。

3. 特に注意を払うべき点:

   • アクションアイテム（それぞれが欠落しているスキルやワークフローを示唆している可能性があります）
   • 未解決の質問（未解決の曖昧さは、しばしば意思決定フレームワークのギャップを示します）
   • 「完了した作業」の記述（作業項目全体のパターンがメタスキルを明らかにする可能性があります）
   • セッションノート（内容だけでなく、プロセスに関する内省的な知見）

4. 追加の観察事項を明確な帰属とともに記録します。 それらが元のセッションからではなく、ハンドオフドキュメントの分析から導き出されたものであることを示してください。これにより、述べられた知見と導き出された知見の区別が保たれます。

書き込み時のアーカイブ化

観察ログは、定期的なレビューで解決済みエントリが一掃されるまで蓄積されるのではなく、ログ書き込みのたびに実行されるイベント駆動型のアーカイブ化によってスリムに保たれます。

「前回の更新時から」の定義: 「前回の更新時から」という表現は、前回のセッションまたは以前のログ書き込みですでにステータスが解決済みであったエントリを指し、現在のセッションで ACTIONED または DECLINED とマークされたエントリを指すものではありません。重要な点として:現在のセッションの週次レビュー中に ACTIONED または DECLINED とマークされたエントリは、その同じセッションの書き込み中にアーカイブ化してはなりません。それらはアクティブログにおいて1回分の可視性を得るのです。アーカイブ化は、次のセッションのログ書き込み時、または次の週次レビュー時に発生します。

週次レビュー中のアーカイブ化のタイミング: 週次レビューはアーカイブ化を2つのフェーズで実行します:

1. ステップ1(レビュー開始時): 前回のセッションからのエントリをアーカイブ化します。観察を読み込む前に、以前のセッションでマークされた ACTIONED または DECLINED のエントリをアーカイブ化します。これにより古い解決済み項目が一掃されます。

2. ステップ6(ACTIONED のマーク後): すぐにはアーカイブ化しないでください。現在のレビュー中(ステップ6)に観察が ACTIONED とマークされた場合、それらはアクティブログに残ります。それらは次のログ書き込み時にアーカイブ化します — 次のセッションがログに書き込むとき、または翌週のレビューが始まるとき(次のレビューサイクルのステップ1)のいずれかです。

これにより、早すぎるアーカイブ化の問題を防ぎます:現在のセッション中にちょうどアクション化されたエントリは、アーカイブに移動する前に、1回分の完全な更新サイクルの間、可視状態を保ちます。

アーカイブファイルの構造: 解決済みエントリを次の場所にあるアーカイブファイルに移動します:

[workspace folder]/skill-observations/archive/log-[date].md

ここで [date] は YYYY-MM-DD 形式の今日の日付です。

アーカイブファイルは、元のログから完全なヘッダーとステータスキーを保持します。アーカイブ化後、アクティブな log.md はヘッダー、セパレーター、およびすべての OPEN エントリ、さらに今回の更新でちょうど ACTIONED または DECLINED とマークされたエントリのみを保持します。

アーカイブ化前の安全確認: エントリをアーカイブに移動する前に、それが現在のセッションで ACTIONED または DECLINED とマークされていなかったことを確認してください。マークされていた場合は、アクティブログに残します。これにより、観察ライフサイクルで説明されている同一セッション内での早すぎるアーカイブ化を防ぎます。これを実装する1つの方法:現在のセッションで ACTIONED/DECLINED とマークされたエントリ ID のセットを追跡し、アーカイブ化の処理からそれらを除外します。

結果として:アクティブログは OPEN 項目と最近解決されたエントリに焦点を当て続け、アーカイブは完全な履歴記録を提供します。

---

機密保持の保護措置

オープンソース/内部の境界は、機密保持の境界です。クライアント名、プロジェクトの詳細、ドメイン名、および専有情報は、オープンソースのスキルに決して現れてはなりません。1件の漏洩が信頼を損なう可能性があるため、これは複数の層を通じて徹底されます — そのうちのいずれか1つが、他の層が見逃したものを捕捉するはずです。

層1: 観察レベルでの除去

type: open-source とタグ付けされた観察をログに記録する際、Issue フィールドと Suggested Improvement フィールドはすでに一般的な言葉遣いを使用しているはずです。プライベートな観察ログはコンテキストのために具体的内容を参照できますが、スキル作成に取り込まれる Principle フィールドは完全に一般化されているべきです。次のように考えてください:ログはプライベートなノートブックですが、Principle は公開可能な洞察です。

層2: 作成前レビュー

オープンソースのスキルを起草または再生成する前に、すべてのソース資料(観察、会話メモ、既存のスキル内容)をスキャンして、識別情報を探します:クライアント名、プロジェクト URL、ドメイン名、内部用語、識別可能なほど具体的に記述されたサイト構造。見つかったものは、書き始める前に一般的な相当物に置き換えてください。

レイヤー 3: 下書き後の総点検

オープンソースのスキルを作成または再生成した後は、情報漏えいに特に焦点を当てて読み直してください。これは一般的な事前チェックリストとは別のパスです。以下を探します:

• スキル作成者の名前ではない固有名詞
• ドメイン名、URL、プロジェクト識別子
• クライアントを絞り込めてしまう業界固有の詳細
• 1 つの組織の文脈でのみ意味をなす内部用語
• 実際のプロジェクトにたどれてしまうほど具体的な例

何か見つかった場合は、汎用的な表現に置き換えるか削除してください。

レイヤー 4: 構造上の原則

分類のセクションでこれについては明示していますが、繰り返す価値があります: オープンソースと内部の区別は、単に有用性の問題ではなく、機密性の問題です。ある詳細が具体的すぎるかどうか迷った場合は、削除してください。少し汎用的になったスキルのほうが、クライアント情報を漏えいするスキルよりも常に優れています。

---

表面化プロトコル

デフォルトの頻度

すべての観察結果をセッションの最後に表面化します。それらをグループ化したサマリーとして提示します: 既存のスキルに関する観察結果はスキル名ごとにグループ化し、新しいスキルの候補は別にリストします。

より早く表面化する場合

• 観察結果を完全または正確にするためにユーザーの入力が必要な場合（例:「これは記録しておきたいパターンですか、それとも一度きりのものですか?」）
• 観察結果が、あるスキルが現在のセッションで実際に誤った出力を生成していることを示しており、ユーザーが認識すべき場合
• 複数の観察結果が同じスキルに集中しており、セッション終了時のレビューではなく即時の対応が必要と思われる場合

表面化の方法

• 観察結果を簡潔に提示します: タイトル、スキル、一文のサマリー
• それぞれについて、新しいスキルの候補か、既存のスキルの改善かを示します
• 推奨するタイプ（オープンソースまたは内部）を示します
• どれに対応したいか（ある場合は）をユーザーに尋ねます
• ユーザーが進めたい項目については、実際の作成または改善作業のために skill-creator スキルに引き継ぎます

---

観察結果への対応

このスキルは何を作成または改善するかを特定します。skill-creator スキルがインストールされている場合（Cowork に組み込み。他の環境では別途インストールで利用可能）、どのように行うかを処理します — 新しいスキルをゼロから作成する、または既存のスキルを体系的に改善するプロセス全体を導きます。skill-creator がなくても task-observer は機能します: 小さな改善は直接適用され、より大きな変更は観察結果を仕様として手動で行えます。直接適用と skill-creator への引き継ぎの境界は次のとおりです:

小さな改善（直接適用）

改善が明らかに追加的で、低リスクで、機能することを検証するためのテストを必要としない場合は、スキルに直接適用できます:

• 既存のリストに新しいルールやアンチパターンを追加する
• 曖昧であることが判明した既存の文言を明確にする
• 既存のセクションに注記やエッジケースを追加する
• 事実の誤りを修正する

例: スキルのアンチパターンリストに新しいアンチパターンを追加する。インラインコードのコメントは、それ自体のドキュメント内で文脈を意識すべきであると明確にする。

重大な変更（skill-creator が利用可能な場合は使用する）

その変更が、検証を必要とする形でスキルの動作に影響を与える可能性がある場合は、skill-creator が利用可能であればそれに引き継いでください：

• フェーズやワークフローの再構成
• 新しい機能やセクションの追加
• 中核となる方法論や意思決定フレームワークの変更
• 「これは実際によりもうまく機能するのか？」が真剣な問いとなるようなあらゆる変更

ただし、スキル作成プロセスの厳格さは、複雑さと対象読者に合わせてください。skill-creator は、テストが必要なオープンソースのスキル、複雑なロジックを持つスキル、または設計がまだ明確でない場合に有用です。要件が会話の中で確立される社内スキルについては、直接書くほうが効率的です。

skill-creator が利用できない場合は、観察結果を仕様として使用し、変更を直接加えてください — ただし、手動でのレビューが必要になる可能性のある重大な変更としてユーザーに伝えてください。

例：自動化されたワークフローを二次的な選択肢ではなく主要な経路とするためにスキルを再構成する。以前はコンテンツ作業から始まっていたスキルに、まったく新しいセットアップフェーズを追加する。

新しいスキルの作成

新しいスキルには、利用可能な場合は skill-creator を使用してください。観察結果をコンテキストとして提供してください — それらには、効率的に始めるために必要な意図、範囲、初期設計の考え方が含まれています。skill-creator がない場合、観察結果はスキルを手動で構築するための詳細なブリーフとして機能します。

新しいスキルを作成するときは、その種類を早い段階で判断してください：

• オープンソースの場合、クライアント固有の詳細をすべて取り除き、一般化する
• 社内用の場合、関連する具体的な内容をすべて自由に含める
• 不明な場合は、オープンソースを既定とする — 具体的な内容を取り除いて一般化し、その後、社内の詳細を追加する必要があるかどうかをユーザーに判断してもらう

---

原則の伝播

観察結果が一般的な原則 — 改善対象のスキルだけでなく、スキル全般に当てはまるもの — を明らかにした場合、それはきっかけとなった1つのスキルに適用するだけでなく、スキルライブラリ全体に伝播させるべきです。

横断的原則ファイル

横断的原則は、観察ログと並んで永続的なファイルで管理されます：

[workspace folder]/skill-observations/cross-cutting-principles.md

このファイルは、あらゆるスキル作成または再生成の際の必須チェックリストとして機能します。新しい、または更新されたオープンソースのスキルを提供する前に、横断的原則ファイルを読み、そのスキルが有効なすべての原則に準拠していることを検証してください。これにより、一般的な原則が善意にとどまらず、強制される標準へと変わります。

仕組み

1. スキルの更新中に、ある観察結果が、作業対象のスキルだけでなく広く当てはまる原則を明らかにする
2. Skill: All skills を付けて観察結果として記録し、ユーザーに提示する
3. ユーザーがそれを横断的原則として承認した場合、横断的原則ファイルに追加する
4. それ以降、あらゆるスキルの作成または再生成に、有効な原則の完全なリストに対する準拠チェックが含まれる

伝播のタイミング

各原則をいつ、どのように伝播させるかはユーザーが決めます：

• 即時伝播 — 既存のすべてのスキルをすぐに更新するに値するほど重要な原則の場合（例：機密保持ルール）
• 機会的伝播 — 各スキルが次に更新または再生成される際に適用できる原則の場合（例：ライセンス表示の追加）

横断的原則ファイルの構造

# Cross-Cutting Principles

Principles that apply to all skills. This file is read as a mandatory
checklist during any skill creation or regeneration.

---

## Active Principles

### 1. [Principle title]
**Added:** [date]
**Applies to:** [all skills | all open-source skills | all skills with rules]
**Requirement:** [what the principle requires]
**Propagation:** [immediate | opportunistic]
**Status:** [active]

---

週次の包括レビュー

7日ごとに、その間隔が経過した後の最初のタスク指向セッションの開始時に、包括レビューが自動的にトリガーされます。このレビューは、すべての未解決の観察結果をすべてのスキルと照合します — 各観察結果で名前が挙げられているスキルだけではありません — そして、横断的原則を、まだ準拠していないすべてのスキルに伝播させます。

トリガーの仕組み

レビューは、セッション開始プロトコルのステップ 3 によってトリガーされます（ 「観察ログの管理」を参照）。週次レビューのタイムスタンプが 7 日を超えて古い場合、 または存在しない場合、セッション開始プロトコルがこのレビューをトリガーします。 週次レビューの時期であることをユーザーに伝え、プロセスを開始します。

レビューのステップ

ステップ 0 — スケジューラの利用可否チェック

レビュー自体を実行する前に、プラットフォームのタスクスケジューリング機能を 使って週次レビューを自動化できるかどうかを確認します。

1. ファイル [workspace folder]/skill-observations/scheduler-registered.txt が存在するか 確認します。存在する場合、スケジュールされたタスクはすでに登録済みです — ステップ 1 に進みます。

2. ファイルが存在しない場合、タスクスケジューリング機能が利用できるかどうかを 確認します。Cowork では、create-shortcut スキルとその set_scheduled_task ツールを確認します。ターミナルベースの環境では、 cron または同等のスケジューリングツールが利用できる場合があります。

3. スケジューリング機能が利用できる場合:

   • [workspace folder]/skill-observations/scheduled-task-draft.md にある タスク説明の下書きを読みます
   • Cowork では、create-shortcut スキルを呼び出して、週次の スキルレビューをスケジュールされたタスクとして登録します。その他の環境では、 利用可能なスケジューリングの仕組みを使用します。
   • タスク名 weekly-skill-review と週次の頻度（例: 月曜日の 朝）を使用します
   • 成功したら、今日の日付を [workspace folder]/skill-observations/scheduler-registered.txt に書き込みます
   • ユーザーに伝えます: 「週次のスキルレビューが スケジュールされたタスクとして登録されました。手動の last-review-date.txt トリガーは フォールバックとして残ります。」

4. ツールが利用できない場合、何も言わずにステップ 1 に進みます。レビューのたびに ユーザーに伝えないでください — このチェックは、成功するまでは 意図的に通知しないようにしています。

ステップ 1 — 観察と原則の読み込み

[workspace folder]/skill-observations/log.md にある観察ログを読みます。 ステータスが OPEN のすべての観察を抽出します。また、 [workspace folder]/skill-observations/cross-cutting-principles.md を読み、 すべてのアクティブな原則を抽出します。

OPEN の観察がなく、すべての原則がすでに反映されている場合は、 レビューをスキップし、タイムスタンプを更新して、セッションを続行します。ユーザーに 簡潔に伝えます: 「週次のスキルレビュー: 未対応の観察や未処理の 原則はありません。すべてのスキルは最新です。」

ステップ 2 — すべてのスキルの棚卸し

システムプロンプトの <available_skills> を使用して、すべてのスキルを特定します。 このタグが存在しない環境では、スキルディレクトリまたは 同等の一覧取得の仕組みを使用して、利用可能なスキルを検出します。

各スキルについて、指定された場所にある SKILL.md ファイルを読みます。組み込みの プラットフォームスキルは更新対象から除外します — ユーザーが作成したカスタムスキルのみを 更新します。

既知のシステムスキル（読み取り専用、ユーザーによる置き換えは不可）: docx、pdf、xlsx、pptx、skill-creator、schedule。このリストは プラットフォームの進化に伴って増える可能性があります — ユーザーがファイルを 上書きできないためにスキルの更新が失敗した場合は、このリストに追加してください。

カスタムスキル（ユーザーが所有し、置き換え可能）は、スキルディレクトリ内で 上記のシステムリストに含まれていないものすべてです。

ステップ 3 — 観察をすべてのスキルと照合する

各 OPEN の観察について、それが各スキルに関連するかどうかを評価します。 観察自体の「Skill」フィールドだけに頼らないでください — 観察には、 元のコンテキストが示唆したよりも広く適用される一般的な原則が含まれている 可能性があります。具体的な「Suggested improvement」フィールドと一般的な 「Principle」フィールドの両方を考慮してください。スキル → [関連する観察] の マッピングを構築します。

ステップ 4 — 横断的な原則をすべてのスキルと照合する

アクティブな横断的原則ごとに、各スキルがすでに準拠しているかどうかを 確認します。まだその原則を実装していないスキルにフラグを立てます。

ステップ 5 — 更新の適用

関連する観察または非準拠の原則がある各スキルについて、その SKILL.md の 更新版を作成します。編集する際は:

• 知見をスキルの適切なセクションに統合します（単に観察事項のリストを末尾に追加するだけにしないでください）
• スキルの既存の構造、文体、著者の帰属を維持します
• 改善がスキルに後付けではなく、自然に馴染むようにします
• 観察事項が新しいフェーズ、ステップ、アンチパターン、チェックリスト項目を示唆する場合は、論理的に属する場所に配置します

システムスキルを対象とする観察事項のルーティング： 観察事項がシステムスキルを対象としている場合（ステップ2の既知のシステムスキル一覧を参照）、それをスキップしないでください。代わりに、改善を補完スキルにルーティングします。これは {system-skill}-extras（例：docx-extras）という名前のユーザー所有スキルで、システムスキルの上に追加のガイダンスを重ねるものです。補完スキルがまだ存在しない場合は作成してください。補完スキルは以下を行う必要があります：

• どのシステムスキルを拡張するのかを明記する
• 差分のみを含める — システムスキルに存在しない追加のルール、アンチパターン、ガイダンス
• システムスキルと一緒に読み込まれるようにする（必要に応じて CLAUDE.md または同等の設定に注記を追加する）

これにより、システムスキルのファイル自体は変更できなくても、システムスキルを対象とする観察事項が引き続き実行可能になります。

重要： スキルファイルをその場で編集しないでください。更新版はユーザーのレビューと手動での置き換えのためにワークスペースフォルダに保存してください（後述の「更新されたスキルの配信」を参照）。

ステップ6 — 観察事項を ACTIONED としてマークする

観察事項に基づいて更新されたスキルの作成に成功したら、log.md 内のその観察事項のステータスを OPEN から ACTIONED に更新します。どのスキルが更新されたかについての簡単な注記を追加します。例：

ACTIONED — Applied to [skill-name] (weekly review [date])

注：標準の書き込み時アーカイブ機構（「観察プロトコル」の「書き込み時アーカイブ」を参照）は、次回のログ書き込み時にこれらの新たに解決されたエントリを自動的にアーカイブします。ここでは別途のアーカイブ手順は必要ありません。

ステップ7 — タイムスタンプを更新する

今日の日付を [workspace folder]/skill-observations/last-review-date.txt に書き込みます。

ステップ8 — サマリーとユーザーのアクション項目を提示する

ユーザーに明確なサマリーと、ユーザーが行う必要があることの明示的な手順を提示します。後述の「更新されたスキルの配信」の形式に従ってください。

制約

• 観察事項のエントリは、そのステータスフィールド以外は変更しないでください
• 新しいスキルを作成しないでください — 既存のスキルのみを更新します。観察事項が新しいスキルを示唆する場合は、ユーザーが skill-creator を介して別途対応できるよう、サマリーに記載してください
• 観察事項が関連しそうに見えても、どのように統合すべきか不明な場合は、スキップしてサマリーにその不確実性を記載してください
• 「internal」とマークされた観察事項も、「open-source」と同様の厳格さで扱ってください

---

更新されたスキルをユーザーに配信する

週次レビュー（またはその他のプロセス）が更新されたスキルファイルを生成した場合、更新されたファイルは手動での置き換えのためにユーザーに配信する必要があります。スキルファイルはセッション中は読み取り専用の場所にあり、バージョン管理で管理されたり、デバイス間で同期されたり、配布用にパッケージ化されたりする可能性があります。自動でのその場での編集は不可能であり、望ましくもありません — 明示的な手順とともにワークスペースフォルダに配信することで、ユーザーが制御を維持できます。

配信プロセス

1. 各更新された SKILL.md を、次の構造を使用してワークスペースフォルダに保存します：

   [workspace folder]/skill-updates/[date]/[skill-name]/SKILL.md
   

   例：

   [workspace folder]/skill-updates/2026-02-16/my-skill-name/SKILL.md
   

2. 次の形式を使用して、明示的なアクションリストをユーザーに提示します：

   ## Weekly Skill Review Complete — [date]
   
   The following skills have been updated based on [N] open observations
   and [N] cross-cutting principles.
   
   ### What you need to do
   
   For each updated skill below, replace the existing SKILL.md in your
   skill directory with the updated version from your workspace folder.
   
   ### Updated Skills
   
   **[skill-name]**
   - Changes: [1-sentence summary of what changed]
   - Observations applied: #[N], #[N]
   - Updated file: [link to file in workspace folder]
   - Action: Replace [skill-directory]/SKILL.md with this file
   
   [repeat for each updated skill]
   
   ### Observations Actioned
   [list of observation numbers and titles marked ACTIONED]
   
   ### Skipped (needs manual review)
   [observations that were unclear or couldn't be applied, with explanation]
   
   ### No Changes Needed
   [skills that were checked but already compliant]
   

3. ユーザーがサマリーを確認するまで、他の作業を進めないでください。ユーザーはファイルをすぐに置き換える必要はありませんが、何が保留中であるかを認識しておく必要があります。

---

観察ログの管理

場所

観察ログは、ユーザーのワークスペースフォルダ内でセッション間を通じて保持されます。初回使用時にログファイルが存在しない場合は作成してください。デフォルトのパス：

[workspace folder]/skill-observations/log.md

ログの構造

# Skill Observation Log

Observations captured during task-oriented work. Each entry identifies a
potential skill improvement or new skill opportunity.

**Status key:** OPEN = not yet actioned | ACTIONED = skill updated/created |
DECLINED = user decided not to pursue

---

## [Date or Session Identifier]

### Observation 1: [Title]
**Status:** OPEN
[... full observation format ...]

### Observation 2: [Title]
**Status:** ACTIONED — Applied to [skill-name], rule 35
[... full observation format ...]

セッション開始プロトコル

これは、すべてのセッション開始時チェックのための唯一のエントリーポイントです。タスク指向のセッションを開始するたびに、以下のステップを実行してください。

1. ファイルが存在するか確認します。 観察ログまたは横断的原則ファイルがまだ存在しない場合、これは初回セットアップです。ログ構造セクション（本文書の後半）と横断的原則ファイル構造セクション（原則の伝播の下）にあるテンプレートを使用して作成してください。ファイルがすでに存在する場合は、ステップ2に進みます。

2. 関連するコンテキストをスキャンします。 OPEN の観察と有効な横断的原則を読みます。現在のタスクに直接関連しない限り、促されない限りそれらを提示しないでください — ただ意識に留めておいてください。

3. 週次レビューのトリガーを確認します。 [workspace folder]/skill-observations/last-review-date.txt のタイムスタンプを読みます。ファイルが存在しない場合、または日付が7日以上前の場合、ユーザーのタスクを進める前に週次包括レビュー（専用セクションで詳述）をトリガーします。7日未満しか経過していない場合は、通常どおり進めます。

4. 設定ファイルを確認します。 設定ファイルの検出（推奨される有効化セットアップの下）に記載されている設定検出を実行します。これはセッションごとに1回実行されます。

ログをクリーンに保つ

アーカイブはイベント駆動型で、ログ書き込みのたびに実行されます。新しい観察を追記したりステータスを更新したりする前に、以前の更新ですでに ACTIONED または DECLINED とマークされたエントリは、タイムスタンプ付きのアーカイブファイルに移動されます（観察プロトコルの「書き込み時のアーカイブ」を参照）。これにより、アクティブなログは OPEN 項目と最近解決されたエントリに焦点を当て続け、アーカイブは完全な履歴記録を提供します。

---

プリフライト原則

このスキルが、作成または改善を支援するすべてのスキルに伝播すべき最も重要なパターンの1つ：組み込みの強制。

実世界の経験から、スキルに文書化されたルールは、出力を生成する創造的な流れの中で常に守られるとは限らないことが示されています。その結果：スキル自身の基準に違反する出力が生まれ、スキルの評判を損ないます。

修正方法：明示的なルールや要件を含むすべてのスキルに、Claude がルールを再読し、配信前に出力をそれらに照らしてチェックする検証ステップを含めるべきです。これはオーバーヘッドではなく — 品質保証です。30秒の再読が30分の手戻りサイクルを防ぎます。

この観察プロセスを通じてスキルを作成または改善する際には、問いかけてください：「このスキルにルールはあるか？ もしあるなら、それを強制するメカニズムはあるか？」 2番目の問いへの答えが「いいえ」なら、追加してください。

一般的なデバッグ原則

デバッグする際は、常に問いかけてください：これは単一のインスタンスか、それともパターンか？ エラーがパターン（例：類似の問題のクラス）を明らかにする場合、インスタンスだけでなくクラスを修正してください。すべての具体的なエラーは、エラーのクラスに関するシグナルです。初回遭遇時に全体の範囲を監査して、後続のサイクルで関連する障害を発見することを避けてください。

自己強制

このスキルは、自ら説くことを実践します。セッション終了時に観察を提示する前に、以下を検証してください：

1. 観察はセッション全体を通じてログに記録されたか — アクティブなツール使用中だけでなく、タスク後のフィードバック、ディスカッションフェーズ、振り返りの会話中も含めて？
2. 観察はユーザーの流れを中断することなく、静かにログに記録されたか？
3. 各観察はフォーマット（課題 → 提案された改善 → 原則）に従っているか？
4. 各観察は正しいタイプ（オープンソースまたは内部）でタグ付けされているか？
5. 既存のスキルに関する観察について、提案された改善は特定のセクションやルールを参照しているか？
6. type: open-source とタグ付けされた観察について、原則フィールドにクライアントを特定できる情報が含まれていないか？ もし含まれているなら、提示する前に一般化してください。

いずれかの観察がこれらのチェックに失敗した場合、提示する前に修正してください。

---

環境の互換性

この観察手法は、Claude がタスク指向の作業中にユーザーとやり取りできるあらゆる環境で機能します。異なるのは永続化の仕組みです。

永続ストレージがある場合

ファイルシステムにアクセスできる環境（ワークスペースフォルダを持つデスクトップツール、プロジェクトディレクトリを持つターミナルベースのツールなど）では、説明したとおりのワークフロー全体が適用されます。観察結果は永続ファイルに記録され、横断的な原則ファイルはスキル再生成時に読み込まれ、ログはセッション間で自動的に引き継がれます。

永続ストレージがない場合

ファイルシステムにアクセスできない環境（Web ベースのチャットインターフェースなど）でも、スキルは引き続き機能します。観察手法は環境に依存しません。違いは、永続化がユーザーの責任になることであり、これを支援するためにスキルが ハンドオフドキュメントモード に切り替わります。

ハンドオフドキュメントモードの仕組み:

• 観察結果は会話内で収集され、通常どおりセッション終了前に提示されます
• ログファイルに書き込む代わりに、観察結果はセッション内で収集され、セッション終了前に構造化された ハンドオフドキュメント として提示されます
• ハンドオフドキュメントには、完全な形式のすべての観察結果、セッション中に行われた決定事項、アクションアイテムと次のステップ、次のセッションまで保持する必要がある作業成果物（ドラフト、分析など）が含まれます
• ユーザーはこのドキュメントを自分のストレージ（ノートアプリ、ファイルシステムなど）にコピーし、次のセッションに貼り付けてコンテキストを復元します
• 横断的な原則はハンドオフドキュメントに含めるべきであり、ユーザーが新しいセッションを開始するときに提供できるようにします

プロアクティブなハンドオフ生成: 永続ストレージがないセッションでは、ユーザーがハンドオフドキュメントを要求するのを待たないでください。会話が終わりに向かい始めたとき — ユーザーが要約している、または「今日はここまで」と言っている、あるいは話題がまとまりつつあるとき — プロアクティブに生成を提案してください。早すぎる提案は軽微な中断ですが、提案しなければ作業が失われます。

ハンドオフドキュメントの形式:

# Session Handoff: [Session Topic]

**Date:** [date]
**Context:** [what was worked on and what the next session needs to know]

## Decisions Made
[numbered list of decisions]

## Observations Logged
[full observation entries in standard format]

## Cross-Cutting Principles (current)
[any principles that were active or newly added]

## Action Items
[what needs to happen next, with enough context to resume]

## Working Artifacts
[any drafts, analyses, or intermediate work products in full]

これは永続ストレージのワークフローほどシームレスではありませんが、核心的な価値 — 失われるはずだった洞察を体系的に記録すること — は保たれます。観察形式と提示プロトコルはどちらの環境でも同一です。

---

クイックリファレンス

質問	回答
いつ観察するのか？	タスク後のフィードバックや振り返りの会話を含む、タスクセッション全体を通じて
どうやって記録するのか？	トリガーされたら即座に観察ログへ静かに追記する。まとめて記録しない
いつ表面化するのか？	セッション終了時、または必要であればそれより早く
どうやって確実に有効化するのか？	設定レベルの指示を追加する（推奨の有効化設定を参照）
オープンソースか社内用か？	可能な場合はオープンソースをデフォルトとする
オープンソースのライセンスは？	CC BY 4.0 を推奨
小さな修正かスキルクリエイターか？	テストが必要 → スキルクリエイター（利用可能な場合）。要件が確立した社内スキルであれば、直接書くのが効率的。明らかに追加的なもの → 直接適用
どのような形式か？	Issue → 改善提案 → 原則
著者の帰属表示は？	オープンソーススキルでは必須。テンプレートを使用する
横断的な原則は？	原則ファイルに追加し、再生成時に適用する
機密性チェックは？	4 つの層：観察、作成前、ドラフト後、構造的
永続ストレージがない場合は？	ハンドオフドキュメントモード — 観察内容をセッション終了時に構造化ドキュメントとして表面化する
スケジューラの自動化は？	週次レビューのステップ 0 で自動チェック。ツールが利用可能になるまでサイレント
観察の番号付けは？	必須の記録前検索により衝突を防ぐ。キャッシュされた番号は決して使用しない
ログのアーカイブは？	イベント駆動 — 解決済みのエントリは次回のログ書き込み時にアーカイブされる
簡素化のシグナルは？	一回限りのルール、決して使われないセクション、ユーザーが飛ばす凝ったワークフロー、矛盾に注意する
ハンドオフドキュメントの分析は？	アクションアイテム、未解決の質問、ナラティブセクションから暗黙の観察を体系的に抽出する
デバッグのアプローチは？	常にインスタンスだけでなくエラーのクラスを特定する。初回遭遇時に全範囲を監査する