リサーチログ は何をしますか？
研究をエンジニアが後日語るように文書化します。つまり、測定の物語、そこから再実装できるほど正確な仕様、数値付きの検証記録、そしてまだわかっていないことを正直にリストアップしたものです — 1つの自己完結型HTMLファイル（CSSと画像が埋め込まれ、外部アセットはありません）として提供します。
中核となる約束：すべての主張は測定に裏付けられているか、未検証とマークされているか、未解決としてリストアップされています。 ガイドとなる一文（必要な場合）：成果物を読めば誰が何を書いたかはわかるが、実際の意味を知っているのは本物のシステムだけだ。
ワークフロー
1. 最初に証拠を棚卸しする
会話、リポジトリ、ログ、およびユーザーから、何かを書き始める前に以下を収集します：
- 時系列：日付、試したこと、失敗したこと、驚いたこと
- 正確な数値とその取得方法を含むすべての測定値
- 検証実行：何を何と比較したか、誤差の数値
- 作業を再現するために必要なツール、ファイルパス、コマンド
- 未解決の質問と純粋な仮説
測定値、日付、数値を創作しないでください。 数値が不足している場合は、質問するか、OPENとマークしてください。データを捏造した書き起こしは、書き起こしがないよりも悪いです — 記録のギャップは記録の一部です。
2. 規約を学ぶ
書き始める前に references/style-guide.md を読んでください — スタイルは細部に宿ります（主張を証明するキャプション、失敗を物語に残すこと、数値は正確に、マーケティングは一切なし）。コンテンツモジュールを書く準備ができたら references/content-format.md を読んでください。
3. 骨格を選ぶ
6つの中核セクションを番号順に、この順序で配置します。理由を明示した場合のみ一つを省略できます。「実際のものを作る」という経緯がある場合は、仕様とツールの間にケーススタディセクションを挿入します。
| # | セクション | 必須内容 |
|---|---|---|
| 1 | ストーリー | 日単位のタイムライン；すべてのステップは測定に基づく；行き止まりや驚きも含める |
| 2 | 方法 | 認識論に関する一文 + テーブル：テスト成果物 → 質問 → 回答 |
| 3+ | 仕様 | バイト/プロトコル/フォーマットテーブル（確信度タグ付き、再実装可能な精度）；数式はコードブロックとして |
| −2 | ツールとハウツー | そのままコピーして動作する実際のコマンドとパス |
| −1 | 検証記録 | 定量的な誤差を含むすべての測定実行 + 最終結論のコールアウト |
| −0 | 未解決の質問 | 正直な未知事項、それぞれOPENまたはHYPとタグ付け |
4. 書いてビルドする
コンテンツを DOC を定義するPythonモジュールとして書き（フォーマットは references/content-format.md に従う）、プロジェクト内に保存してドキュメントを再生成できるようにします。その後：
python3 <skill-dir>/scripts/build_doc.py content.py out.html
出力を開き、ユーザーに提示する前にレンダリングを確認します。
5. 自己監査
- すべての事実の主張にはタグが付いているか、検証記録に記載されている
- ストーリーには少なくとも1つの驚き、失敗、または訂正が含まれている — もし作業にそれらがなかった場合は、ドラマを作り出す代わりにそのまま率直に述べる
- 数値は正確で単位が付いている（「速い」ではなく0.445秒、「多い」ではなく64,779ピクセル）
- すべての図のキャプションは、画像が示していることではなく、証明していることを述べている
- ハウツーコマンドは実際に実行されたか、未テストであることが明確にラベル付けされている
- 未解決の質問が存在する（必ず存在する）
- 最終結論は、誰かが記憶から繰り返せる一文である
タグについて
4つの確信度タグ。対象となる主張の末尾にインラインで配置します：
- HW（緑）— 実際のテスト対象システムで測定されたもの。非デバイス作業でも適用：ライブ実行、ベンチ上、本番環境で測定されたもの。
- FILE（青）— 調査したすべての成果物（ファイル、キャプチャ、ログ）で真であるもの。
- HYP（紫）— すべての証拠と一致するが、未検証のもの。
- OPEN（灰）— 不明；どちらの方向の証拠もないもの。
事実にはタグが付きます。解説には付きません。ドメインにこれらのより適切な名前がある場合は、ドキュメントの先頭で一度名前を変更し、一貫して使用してください — ただし、この4段階の分割は正確に維持してください。
文体
同僚のエンジニアとして、一人称複数形、マーケティングは一切なし。数値は正確で単位付き。文は短く。ユーモアは控えめでまれ。失敗と訂正は脚注ではなくストーリーに含める。同僚は役割でクレジットする（「ある同僚が2つのPNGシーケンスを提供した…」）。
起源
TriCaster DVEリサーチログ（waldobjekt.org, 2026年11月1～3日、Claudeで作成）から抽出 — 元のドキュメントには独自の build_doc.py が付属しています。このスキルはそのセットアップを一般化したものです。