reading-notes

読書ノート

提供されたリソースを、役立つ復習ノートと具体的な宿題リストにまとめます。

判断ツリー

ユーザーが提供したものは何ですか？

• 生のメモ、貼り付けられた箇条書き、またはリアルタイムのメモの記録 テキストを資料として扱います。ユーザーの大まかな構成を保ち、明らかなグループ分けを整え、メモが完全であるかのように装うことなく宿題を抽出します。

• ローカルのドキュメント、PDF、スライドデッキ、スプレッドシート、画像、音声ファイル、または動画ファイル references/intake.md を読み、利用可能なテキストと視覚・音声情報を抽出してから、デフォルトのワークフローに進みます。

• ウェブページ、記事、RFC、issue、プルリクエスト、または公開 URL references/intake.md を読みます。要約する前に、タイトル、URL、表示されている場合は日付、アクセス上の制約を記録します。

• YouTube またはその他の動画 URL references/intake.md を読みます。まず文字起こしまたは字幕を優先し、次に表示されているメタデータを補足します。文字起こしを利用できない場合はその旨を伝え、根拠のある内容をまとめた後でのみ、文字起こしの提供を依頼します。

• ユーザーが「宿題」「調べること」「次に何をすべきか」「これを ToDo にまとめて」と依頼している references/synthesis.md を読み、アクションリストを明確にします。

• ユーザーがノートの保存、エクスポート、共有、または変換を依頼している references/output-formats.md を読みます。まずノートを作成し、ユーザーが形式を指定していない場合は、どの形式で保存するか尋ねます。

クイックリファレンス

必要なこと	実行すること
ソースをすばやく分類する	python3 scripts/probe_reading_notes.py --source "<resource-or-notes>"
ドキュメント、動画、ウェブページ、スクリーンショットから内容を抽出する	references/intake.md を読む
雑然とした資料をトピック、アイデア、ToDo、調査の手がかりにまとめる	references/synthesis.md を読む
一貫した Markdown 構成を使う	templates/reading-notes.md をコピーする
Markdown、DOCX、PDF、またはその他の形式で保存する	references/output-formats.md を読む
よくある要約の失敗を避ける	references/gotchas.md を読む
スキルパッケージを検証する	スキルディレクトリで python3 scripts/validate.py . を実行する
パッケージ化とヘルパーのテストを実行する	スキルディレクトリで python3 scripts/test_skill.py . を実行する

デフォルトのワークフロー

1. リソースの種類とアクセス方法を特定します。リソースがない場合は、メモ、リンク、ファイル、文字起こし、またはスクリーンショットの提供を依頼します。
2. ソースのメタデータを記録します。タイトル、分かる場合は著者・発言者、イベント・文脈、URL・パス、日付、アクセス上の制約を含めます。
3. 情報の損失が最も少ない方法で内容を抽出します。長いリソースは、セクション、タイムスタンプ、見出し、スライド、またはトピックごとに分割します。
4. 最終ノートを書く前にトピックマップを作成します。断片が現れた順ではなく、主題ごとにまとめます。
5. 興味深いアイデアを拾い出します。意外な主張、有用な手法、トレードオフ、未解決の議論、参考資料、名前の挙がったツール、再確認する価値のある概念などです。
6. 価値のあるフォローアップを、具体的な動詞を使った宿題の ToDo に変換します。読む、検証する、比較する、試作する、質問する、インストールする、ベンチマークする、書く、作成する、決定する、などです。
7. 事実、推論、疑問を分けます。不確かな項目は、断定的な表現に整えるのではなく、不確かであることを示します。
8. ユーザーが別の形式を指定していない限り、ノートは Markdown で返します。
9. Markdown、DOCX、PDF、タスクリスト形式など、実用的な選択肢を挙げて、ノートを保存またはエクスポートするか最後に尋ねます。

出力仕様

デフォルトでは次の形式を使います。空のセクションは省略しますが、ユーザーが宿題を求めている場合は、ToDo と調査のセクションを残します。

# <Resource or Session Title>

## Snapshot
- Context:
- Source:
- Confidence:

## Topics
- <topic>: <one-line explanation>

## Interesting Ideas
- <idea>: why it matters or why it is worth revisiting

## Homework / Todos
- [ ] <verb-first action>

## Further Research
- <term, tool, paper, RFC, person, library, or question to look up>

## Open Questions
- <uncertainty, missing source, or question to ask later>

品質基準

• 箇条書きは、重要な情報に絞ります。元のソース全体を圧縮した文字起こしのように書き直さないでください。
• ユーザーが後からすべてを読み直さなくても着手できるよう、ToDo を具体的なアクションにします。
• 名前の挙がった参考資料、コマンド、URL、ライブラリ、製品、人名、RFC を保持します。
• ソースに部分的にしかアクセスできない場合は、何を利用でき、何が欠けていたかを明確に述べます。
• 可能な場合は、URL、ページ番号、タイムスタンプ、見出し、スライド番号、ファイルパスなどの引用やソースの参照箇所を使います。

読み方ガイド

状況	読むファイル
リソースにアクセスする、または正規化する必要がある	references/intake.md
トピック、アイデア、調査の手がかり、ToDo に該当するものを判断する必要がある	references/synthesis.md
メモを保存またはエクスポートする必要がある	references/output-formats.md
ソースが雑然としている、一部しかない、長い、視覚的な内容を含む、または文字起こしのみである	references/gotchas.md
再利用可能な出力のひな型が必要である	templates/reading-notes.md

注意点

1. 文字起こしだけでは、トーク全体を網羅できません。デモ、スライド、図、コード、聴衆からの質問に重要な背景情報が含まれている場合があります。
2. 雑然としたライブメモは証拠であり、完全なソースではありません。不確かな点は明示したままにしてください。
3. 「ClickHouseを調べる」のような曖昧なToDoは不十分です。「ClickHouseのMergeTreeにおけるプライマリーキーの設計を、Nightwatchの一般的なダッシュボードクエリと比較する」のように具体化してください。
4. 興味深いとは、単に言及されたという意味ではありません。意外性がある、有用である、議論を呼ぶ、再利用可能である、または後のアクションにつながる項目を取り上げてください。
5. ユーザーの主な依頼がファイルの作成でない限り、メモを作成する前にエクスポート形式について尋ねないでください。

検証メモ

ヘルパースクリプトは決定論的で、ソースの説明を分類するだけです。コンテンツの取得や要約は行いません。コマンドの構文は --help で、パッケージの動作は scripts/test_skill.py で確認してください。