| name | preread |
| description | 技術文書(論文・技術ブログ・技術記事)の URL から、原典を読むかどうかを 決めるための自己完結 HTML 下読み教材を生成する。「下読みして」「教材にして」 「読むべきか判断したい」「読む価値あるか」と URL 付きで頼まれたとき、 または /preread で発火する。要約だけ・翻訳だけの依頼、URL のない質問、 文書内容への単発の質問には使わない。 |
| argument-hint | <技術文書の URL> |
| disable-model-invocation | true |
Preread — 原典を読むかどうかを決める下読み教材
技術文書 1 本から、Learn Your Way 型の自己完結 HTML 教材を 1 ファイル生成する。
教材の役割は習得ではなく選別 — 読者が 15 分で全体像を掴み、原典に時間を
投資するかを根拠を持って決められる状態にする。LLM が関与するのは生成時のみ。
生成後の教材はネットワークも鍵も不要で、判定も遷移もクライアント側で動く。
工程
1. 取得
- Web 記事:
defuddle parse <url> --md(defuddle スキル参照)
- arXiv: HTML 版(
https://arxiv.org/abs/<id> → HTML リンク)を優先、
なければ LaTeX ソース
- 図は画像として埋め込まない。教材側で再描画するか、原典の図番号を参照する
2. 文書タイプ判定
references/doc-types.md を読む。
実証論文 / 立場表明 / サーベイ / チュートリアル / ブログのどれかを判定する。
心像図の骨格、「事実と著者の見立て」の色分け要否がここで決まる。
3. 前提チェックと書き直し計画
読者プロファイルを次の優先順で解決する:
- 文脈に読者プロファイルがあればそれを使う(プロジェクトの
AGENTS.md がプロファイルのファイルを指している場合など)
- 無ければカレントディレクトリの
PROFILE.md を探す
- それも無ければ references/reader-profile.example.md
の見出しに沿って読者に 2〜3 問聞き取り、カレントディレクトリに
PROFILE.md を作成してから続行する。git リポジトリ内なら
「個人情報を含むならコミットに注意(必要なら .gitignore)」と一言添える
文書の鍵概念を列挙し、読者が持っていない前提を特定する。書き直しは
内容の範囲を維持したまま行う(Learn Your Way の制約 — 易しくしても
原文が主張していないことを足さない、主張の強度を変えない)。
4. 中身の生成
references/content-rules.md に従って生成する:
書き直した本文、章ごとの埋め込みクイズ、心像図、図の読み方ガイド、
「現実世界で回してみる」、用語集、結びの「原典へ進むか」判定ブロック。
5. テンプレートへの流し込み
assets/template.html の骨格に中身を埋める。
CSS・JS の汎用エンジンは変更しない。文書ごとに差し替えるのは本文マークアップと
JS 冒頭の「文書ごとに差し替えるデータ」(FIG_STEPS / MAP / WIRES)のみ。
テンプレートに無い見た目の要素がどうしても必要なときだけ
references/design-rules.md を読み、規約内で作る。
6. 自己検証
生成した HTML を以下のチェックリストで照合する:
7. 保存と報告
カレントディレクトリの preread/<slug>.html に保存する(<slug> は
文書の短い英語ケバブケース名)。版番号は付けない — 作り直しは上書き。
保存パスと、判定ブロックの結論(進む/止めるの分岐点)を 1 行で報告する。
運用ノート
- 生成後、読者が原典に進んだ結果「判断が覆った」場合はそのことを聞き取り、
何が下読みから抜けていたかを references の該当ファイルに追記する
(このスキル自体を検証中の PoC として扱う)
- 読者からプロファイルの変更依頼があったら(現場が変わった、前提の
見立てが違う、例が現場に合わない、など)、その場で工程 3 の解決順で
実際に使っているプロファイルの実体を編集して反映する
