構造化レポート
1つの自己完結型HTMLファイル（ネットワーク不要）で、忙しい読者が以下のことを行えます:
- 作業全体をタスクマップとして表示し、各タスク内で何が待機しているかを確認
- 任意のタスク（およびその内部の段階）を開き、どのように実行され、なぜ各主張が信頼されるのかを監査
- その場でエージェントの質問に回答し、どのプロンプトが何を生み出したかを確認
構造 vs コンテンツ
- 構造 はテンプレート（
assets/template.html）に属します: レイアウト、セクション名（Problem, Task, Context, Conclusions, Assumptions, Result, Not checked, Workflow, Needs approval, Your actions）、その順序、ステータス、すべてのアイコンとUIラベル。固定され、常に英語です。アイコンは構造のみを示し、コンテンツの内容については示しません。 - コンテンツ はあなたのものです: ユーザーの言語で記述されたJSON。
scripts/build.pyがそれを検証し、テンプレートのプレースホルダーを埋めます。あなたはHTMLを書いたり、セクションを発明したりすることはありません。
ワークフロー
- 素材の収集: メッセージ、ツールの結果、ファイル、コマンド、リンク、テスト、測定結果、決定事項。実際に起こったことだけを報告します。
- タスクへの分割（1〜12個）: 1タスク = 1つの目標とその成果。それらを
linksで接続します:depends、blocks、related。 - 各タスクの記入: 以下のルールと
references/schema.mdに従います。 - JSONの作成: デフォルトではワーキングディレクトリに
reports/<YYYY-MM-DD>-<slug>.jsonを作成します。 - ビルド:
python3 <skill>/scripts/build.py <file>.json→<file>.html。すべてのerror:を修正します。すべてのwarning:を読み、それが真実でない限り修正します。 - ローカルで開く（
open/xdg-open/start）してパスを伝えます。絶対にアップロードしないでください。 - チャット内: 2〜4行 — 主要な結果と、読者を待っているもの。
リビングレポート: セッションを追跡し、回答を取り込む
ユーザーがセッション中にレポートを最新に保つこと（または追跡/リビングレポートを要求した場合）を望むときは、一度だけセッションをバインドします:
python3 <skill>/scripts/track.py start reports/<file>.json # <file>.journal.json を作成
以降、UserPromptSubmit フック（一度インストール: track.py install-hook、これによりStopフックも追加されます）は、すべてのユーザープロンプトをジャーナルに記録し、プロンプト番号を通知します。作業を変更する各プロンプトの後、JSONを更新して再ビルドしてください — build.py はすべてのブロック（各ノード×セクション）をフィンガープリントし、新しいブロックまたは変更されたブロックに現在のプロンプト番号をスタンプします。スタンプを自分で書くことは決してしないでください。レポートにはプロンプトラックが表示され、プロンプトを選択すると、そこで現れた（緑）または変更された（青）ものがハイライトされます。
読者への質問。 決定事項は approvals に配置します。各項目は options（排他的（デフォルト、1つの回答）または "multi": true（該当するものすべて））を持つ質問で、recommend（マルチの場合はリスト）、why、due を指定します。常に「あなた自身の回答」が追加オプションとして存在します。オプションがない質問は自由文で回答されます。レポートでは、Needs approval セクションの未解決質問がシリーズとして表示され、一度に1つの質問が提示されます: 排他的オプションを選択すると回答して次に進み、マルチチョイスまたは独自の回答は「次へ」で確定され、シリーズはすべての回答のレビューで終了し、「回答を送信」でそれらがあなたに送信されます — これ以外の送信方法はなく、actions（読者が取る手順）には入力はありません。回答はローカルの回答サービス（127.0.0.1:47319、ビルドによって起動・更新される）に送信され、プレーンファイルとして開かれた場合でも、ジャーナルに次のプロンプトとして保存されます。レポートに未解決の質問がある間は、バックグラウンドコマンドとしてウェイターを実行し続けます:
python3 <skill>/scripts/track.py wait reports/<file>.json
読者が送信すると、wait が回答を出力して終了します — その出力があなたに返ってきます: それをユーザーのプロンプトとまったく同じように扱い、続行します。質問が残っている場合は再度 wait を開始します。ウェイターが実行されていない場合、Stopフックはキューに入った回答をあなたのターンが終わる前に引き渡し、UserPromptSubmitフックはそれらをユーザーの次のメッセージに添付します — 回答が失われることはありません。回答済みの質問は、次のビルド後に回答済みとして表示されます。--static は回答チャネルなしでレポートをビルドします（このマシンの外部で共有するため）: 質問は読み取り専用で表示され、入力はありません。
入力欄の下のリンク。 scripts/statusline.py は、セッションのレポートのステータス行を1行出力します — HTMLをブラウザで開くクリック可能なリンクとしてのタイトルと、まだ待機中の質問の数。ステータス行として使用するか、その出力を既存のステータス行に追加します。レポートがないセッションでは何も出力しません。
レポートのすべてのブロックには Markdownとしてコピー ボタンがあります（レポート全体、タスクカード、レポート、セクション、単一アイテム、ステップ、プロンプト） — 読者が他の場所に貼り付けたいときにそのボタンを指し示します。
レポートを信頼できるものにするルール
各事柄について どのように知ったか を分離し、決して混同しないでください。
- context — 実際に参照したソース:
id（C1…）、短いtitle、実際のurl、および取った正確な事実を含むnote。URLをでっち上げないでください。リポジトリ/Web URLを優先:file://リンクは読者のマシンでは開きません（ビルドが警告します。ローカルファイルが存在しない場合はエラーになります）。 - inferences — 結論。それぞれに
basis（コンテキストID）とconfidenceを含みます。basisがない → それは仮定です。 - assumptions — 確認せずに真としたもの:
why（理由）、verify（検証方法）、risk（誤っていた場合のリスク）。 - unchecked — 確認しなかったことや行わなかったこと、およびその
why（理由）。読者は他の何よりもこれを重視します。率直に述べてください。完了したタスクにuncheckedがないと警告が出ます（[]は「すべて確認済み」を意味します — 本当にそうである場合のみ）。 - result — 現在存在するもの。型付けされたアイテムとして記述します。すべての
verifiedアイテムにはhow: それを証明するコマンド、テスト、またはリンクが必要です — ビルドはこれがないと失敗します。 - stages — 実際に行った手順。レベルあたり2〜8個。ステージはタスクと同じ種類のノードです:
id+title必須、任意のタスクフィールドが許可され、自身のstages+flowを任意の深さで持てます。カード上ではdetail（行ったこと）、outcome（結果）、status、when、usesを表示します。ステージをクリックすると同じ構造でレポートが開くため、実際の作業だったステージには実際のコンテンツを入れてください。行き止まりもステージです（failed/skipped）。 - next steps are planned stages — まだ行うべきことはすべて
status: "planned"のステージであり、detail（行うこと）とwhen（条件または時期: "after your approval"、"Monday"）を含みます。計画済みまたは進行中のステージがない未完了のタスクは警告を受けます。 - approvals — 読者だけが下せる決定: 質問、
why（なぜ読者の決定なのか）、options（排他的、またはmulti: true）、あなたのrecommend（オプションの1つ。マルチの場合はリスト）、due。1つのノード内の関連する複数の質問はシリーズになります — 読者が回答すべき順序に並べてください。すでに行ったことに対して承認を求めてはいけません。 - actions — 読者だけが実行できること。正確な
commandと、関連する場合はdueを含めます。 - secrets — レポートは転送される可能性があります。キー、トークン、秘密鍵、JWT、パスワードの代入、URL内の認証情報のように見えるものがあるとビルドが失敗します（gitleaksがインストールされていればそれも使用します）。コンテンツから削除してください。決して手動で「マスク」しないでください。ログに記録されたプロンプト内の機密情報は自動的にマスクされます。
散文ではなく構造を書く
すべてのテキストフィールドは構造をレンダリングするため、構造を与えてください:
- item→ 箇条書き。1. item→ 番号付きリスト（実際のシーケンスのみ）。2つ以上のKey: value行 → 整列テーブル。文字列のJSON配列 → 箇条書き。**太字**で、行ごとに読者が見逃してはならない1〜2項目を強調。==テキスト==でハイライト。`コード`で識別子、パス、コマンドを示す。- 段落は2文以下。小見出しや導入行は不要。
フィールドガイダンス: brief — マップカード用の1〜3行の Key: value。problem — キー/値の事実。goal — 完了状態を説明する箇条書き。result.summary — キー/値または箇条書き。
言語
コンテンツはユーザーの言語で、meta.lang をその言語コードに設定します。構造ラベルは英語のままです。
ファイル
assets/template.html— 構造: プレースホルダー、スタイル、アイコン、レイアウト、ナビゲーション、検索、プロンプトラック、回答機能のためのスクリプトを含むマークアップ。scripts/build.py— コンテンツの検証（上記のチェック、機密情報）、ジャーナルへのスタンプ、テンプレートのレンダリング。--checkは検証のみ。--templateは別のテンプレートを使用。scripts/track.py—start、wait、hook、stop-hook、daemon、status、install-hook（docstringを参照）。scripts/statusline.py— Claude Codeのステータス行用のレポートリンク。references/schema.md— すべてのフィールドの定義。examples/— 英語とロシア語の例。ロシア語の例には5プロンプトのジャーナルが含まれています。