ConardLi/garden-skills

Beautiful Article

背景原則

AI が生成するコンテンツが複雑になればなるほど、その出力メディアは重要になります。HTML の価値は、情報密度、視覚的な明瞭さ、共有のしやすさ、そしてインタラクティブ能力を同時に向上させる点にあります。テーブル、SVG、CSS、コードスニペット、調整可能なコントロール、コピー＆エクスポートボタンなどを活用することで、読者は単に「読み終える」だけでなく、比較、位置確認、調整、再確認、そして使い続けることができるようになります。Beautiful Article の目的は、退屈で直線的で消化しにくいテキスト素材を、視覚体験が美しく、読むリズムがはっきりしていて、レビューや共有も簡単な単一ファイルのウェブ記事に変換することです。

境界（最初にこのスキルに入るべきか判断する）

• 最終的な成果物は 単一の HTML 記事であり、ウェブアプリケーションではありません。
• 記事には Raw 自由層（任意の HTML / CSS / JS / React：インタラクション、レイアウト・タイポグラフィ、アニメーション、小さなツール、オンデマンドの SVG / canvas 図解）を含めることができますが、読む、説明する、論証する、リズムを整える、または美的であることに役立つ必要があります。
• 生成しないもの：管理画面、フォーム、ドラッグ＆ドロップワークベンチ、完全なダッシュボード、プロトタイプ、汎用ウェブアプリ。
• 情報密度はユーザーが確認します。デフォルトで 100% の情報を保持し、長文形式のウェブ記事を生成します。

ユーザーがアプリケーションではなく記事を求めている場合は、立ち止まって明確にし、このスキルに入らないでください。

---

ワークフロー概要

Phase 0  Intake            スキルに入るべきかの判断 + 初期的な記事タイプ
   ▼
Phase 1  Source → Markdown URL/PDF/DOCX/MD/テキスト → source.md + extraction-notes.md
         └ メインAgentがインラインで5項目のチェックリストを自己チェック（複雑/低信頼ソースの場合のみ SubAgent にアップグレード）
   ▼
Phase 2  Editorial Planning 1つの plan.md を作成（Brief / Outline / Theme / Assets の4セクション）
         └ メインAgentがインラインで自己チェック（SubAgentなし、レビューファイルなし）
   ▼
Phase 3  Plan Checkpoint   ★Checkpoint 1 は必須停止。5項目を1つずつ確認：記事タイプ（デフォルト情報保持率込み）/ テーマ / レイアウト幅 / 画像モード / 表紙
   ▼
Phase 4  First Spread      最初の画面 + 最初のセクション + 代表的なビジュアルブロック（ここでスキャフォールドを作成）
         └ First Spread Reviewer SubAgent（review/first-spread-review.md を作成）
         └ ★Checkpoint 2 は必須停止。2項目を1つずつ確認：承認結論 / 開発モード A/B
   ▼
Phase 5  Full Article Build 完全なウェブ記事を生成（デフォルトは単一Agent、超長文の場合はセクションごとに分離可能）
         └ Section Reviewer SubAgent（メッセージで pass/fail を返す。レビューファイルは作成しない）
   ▼
Phase 6  Final Review      編集 / ビジュアル / 技術 の3視点で最終レビュー（review/final-review.md を作成）
   ▼
Phase 7  Repair            最小単位での修正。修正があった場合のみ repair-log.md を作成
   ▼
Phase 8  Delivery          ★Checkpoint 3 は必須停止。納品可否を1項目ずつ確認 → article.html と短い編集注釈を納品

ワークスペース構造（スキャフォールド作成時。これらのファイルはスキルの長期記憶であり、チャットのコンテキストだけに頼って決定を記憶しないこと）：

<workspace>/
  source/   original.*  source.md  source.<lang>.md(翻訳が必要な場合)  extraction-notes.md
  plan/     plan.md                                    # 単一の計画ファイル：Brief / Outline / Theme / Assets の4セクション
  article/  Cover.tsx(デフォルト)  Article.tsx  sections/  raw-blocks/  assets/  article.html(成果物)
  review/   first-spread-review.md  final-review.md   # これら2つのみが通常の成果物
            source-review.md(複雑なソースのみ)  repair-log.md(修正があった場合のみ)
  index.html  package.json  vite.config.ts  tsconfig*.json   (ビルドツール)

---

厳格な品質チェックプロトコル（スキル全体で一貫）

品質チェック方法はノードによって異なります。すべての品質チェックに SubAgent を起動するわけでも、すべての品質チェックでファイルを書くわけでもありません。 誤った SubAgent の起動やファイルの作成はパフォーマンス上の主要な問題となるため、以下の表に従って厳格に実行してください。

ノード	品質チェック方法	成果物	理由
Phase 1 Source（デフォルト）	メインAgentがインラインで5項目のチェックリストを実行	ファイルなし	メインAgentは source.md を通読するから
Phase 1 Source（複雑/低信頼ソースのみ）	Source Reviewer SubAgent（original.* とのdiffを確認）	review/source-review.md	静かな消失はdiffでしか発見できないから
Phase 2 Plan / Checkpoint 1 の前	メインAgentがインラインで自己チェック（SubAgentの起動禁止）	ファイルなし	planはテキストによる意思決定であり200～400行。コンテキストはホットで、SubAgentのコールドスタートはむしろ遅いから
Phase 4 First Spread / Checkpoint 2 の前	First Spread Reviewer SubAgent	review/first-spread-review.md	最初の画面で方向性を決めるため、もう一つの独立した視点があるとより安定するから
Phase 5 各セクション	Section Reviewer SubAgent	メッセージで pass/fail と修正点を返す（ファイルは作成しない）	記事によっては5～15セクションになることもあり、N個のレビューファイルは誰も読まないから
Phase 6 最終レビュー / Checkpoint 3 の前	Editorial + Visual + Technical Reviewer SubAgent	review/final-review.md	納品物の一部として、記録に残す価値があるから

鉄則：

1. Plan Checkpoint（Phase 2 → Checkpoint 1）では、品質チェックのために SubAgent を起動することを固く禁じます。メインAgentは plan.md を書き終えた後、その場で5項目のチェックリスト（references/review-checklist.md のPlan自己チェックセクション参照）に照らして確認し、結論に従って plan/plan.md を修正します。review ファイルは一切作成せず、その後 Checkpoint 1 に進みます。
2. First Spread / Final では SubAgent を使用する必要があります（これらのノードでは SubAgent の価値がオーバーヘッドを上回ります）。SubAgent 環境が検出できない場合のみ、メインAgentが代行し、ファイルの先頭に「SubAgent環境なし、メインAgentが代行」と明記します。
3. Section Reviewer は SubAgent を使用しますが、戻り値はメッセージ（pass / fail + 修正点）です。fail 項目はメインAgentが受け取ったら直接修正し、SubAgent に review/section-NN-review.md ファイルを作成させないでください。
4. どの品質チェックの結論を受け取った場合でも、まず fail 項目に従って成果物を修正し終えてから、「完了 + 自己チェック結論 + 修正内容」を報告してください。未修正のまま生の結論を報告することは違反です。
5. 意思決定収集の鉄則・ユーザーに代わって静かに選択することを禁止：各Checkpoint（1 / 2 / 3）では、ユーザーの確認が必要なすべての意思決定項目を必ず独立してリストアップし、ユーザーの応答を待つ必要があります。Agentは推奨することはできます（「理由は…なのでXを推奨します」）、しかし「すでにXに決めてありますので、違う場合は言ってください」と言ってはいけません——これは選択の機会を奪うことになります。
   • 優先：環境に AskQuestion ツールがある場合、各決定項目を独立した質問として（1回の呼び出しで複数の質問を渡せます）、ユーザーが選択カードで1つずつ確認できるようにします。
   • それ以外の場合：立ち止まり、メッセージですべての質問を番号付きでリストアップし（各質問は段落を分け、推奨項目+理由+選択肢を明確に書き）、「あなたの回答を1つずつ待ってから続けます」と明確に伝え、後続の作業を一切進めないでください。
   • 絶対にしてはいけないこと：複数の決定を「私の推奨をすべて受け入れますか？/すべてOKですか？」という yes/no 質問にまとめること。また、「推奨の一文」の後にデフォルトで次のステップに進むこと。

各ノードのチェックリストとSubAgentプロンプトテンプレートは references/review-checklist.md にあります。

---

各フェーズのファイル読み取りガイド（段階的に読み込むこと。一度に全部読まないこと）

フェーズ	必読	必要に応じて参照
Phase 0 Intake	references/harness.md	——
Phase 1 Source→MD	references/source-to-markdown.md	scripts/source-to-markdown-markitdown.py · scripts/source-to-markdown.py
Phase 2 Planning	references/article-types.md · references/information-density.md · references/plan-template.md · references/theme-selection.md · references/layout.md · references/asset-policy.md · references/cover.md（表紙の構図アイデア）	references/article-types/<type>.md · theme-profiles/*.md
Phase 4 First Spread / Phase 5 Build（各セクションの前に毎回確認）	references/section-build.md · references/component-policy.md · references/raw-policy.md · 選択されたテーマ theme-profiles/<id>.md · 表紙：references/cover.md	references/scaffold.md（プロジェクト作成時に一度）· references/html-output.md
Phase 6/7 Review & Repair	references/review-checklist.md · references/repair-policy.md	——
Phase 8 Delivery	references/html-output.md	references/pdf-output.md（ユーザーがPDF出力を選択した場合のみ）

長いセッションではエージェントが原則を忘れがちです —— Phase 5 では N 個のセクションを繰り返し実装します。各セクションの作業を開始する前に component-policy.md + raw-policy.md + 現在のテーマ theme-profiles/<id>.md を再度確認してください。

---

Phase 0 —— Intake

このスキルに入るべきか判断し、初期的な記事タイプと出力モード（デフォルトは単一HTML）を特定します。

ユーザーが渡したもの	行うべきこと
1つ以上の素材（URL/PDF/DOCX/MD/テキスト/スクリーンショット）	Phase 1 へ
「Xについての記事を作って」と言うだけで素材がない	逆質問：まず素材またはアウトラインを求める。スキルはユーザーに代わって内容を空想しない
明らかにアプリケーション / ツール / ダッシュボードを求めている	立ち止まって明確にし、このスキルに入らない

ターゲット言語の取得：開始時にユーザーの最終記事に使用する言語を記録します（例：ユーザーが「日本語で / 英語版にして」などと述べた場合）。

• ユーザーが言語を指定した場合 → plan/plan.md のBriefセクションの「ターゲット言語」に記録します。ソース資料の言語と異なる場合、Phase 1 でまず自然な翻訳版のソース文を生成し、以降は翻訳版に基づいて作成します（Phase 1 参照）。
• ユーザーが指定しなかった場合 → デフォルトで最終記事の言語はソース資料の言語に従います。翻訳は行いません。

自己チェック：ユーザーが求めているのは記事かウェブアプリケーションか？完全な情報が必要か？最初に追加の素材を求めるべきか？ ユーザーは最終的な言語を指定したか？ソース言語と一致しているか？

---

Phase 1 —— Source → Markdown

任意の入力を source/source.md に統一し、不確かな点は source/extraction-notes.md に書き込みます。 ルールと各種入力の処理については references/source-to-markdown.md を参照してください。MarkItDown メインパスまたは軽量フォールバックスクリプトを使用して PDF/DOCX/HTML の抽出を行うことができます。

書き込み後、メインAgentがインラインで自己チェック（references/source-to-markdown.md の5項目のチェックリスト）を行い、結論に従って修正してから Phase 2 に進みます。extraction-notes.md が低信頼/複雑なソースとマークしている場合のみ、独立した Source Reviewer SubAgent にアップグレードし、original.* と比較した diff 形式のチェックを行います（review/source-review.md を作成）。

言語処理（抽出の直後に行う）：source.md の言語を判断します。

• ユーザーがターゲット言語を指定していない、または指定されたターゲット言語がソースと一致する場合 → 翻訳は行いません。以降は source.md に基づいて作成し、最終記事の言語 = ソース言語とします。
• ユーザーがターゲット言語を指定しており、それがソースと一致しない場合 → まず自然な翻訳版 source/source.<lang>.md（例：source.zh.md / source.en.md）を生成し、以降の Phase 2+ の事実上のベースとします。原文 source.md は参照用として保持します。翻訳要件：ターゲット言語として自然で、翻訳調がないこと（ターゲット言語の表現習慣に従って文を再構成し、逐語訳せず、不自然な外国語の語順/受動態の連続/異国の句読点を残さないこと）。用語/数字/コード/数式/引用は正確に保持し、構造と情報保持率は変更しません。翻訳に関する説明は extraction-notes.md に書き込みます。

---

Phase 2 —— Editorial Planning

編集計画を立案します。直接 HTML を書きません。plan/plan.md を1つだけ作成します（4セクション：Brief / Outline / Theme / Assets）。テンプレートは references/plan-template.md にあります。

• Brief：対象読者 / 記事タイプ / 情報保持率 / 必須保持項目 / 削減可能項目 / トーン / 主要な主張 / 読了目標 / ターゲット言語 / レイアウト幅 / TOC / 画像戦略。
• Outline：Hero / Lead / Summary / Section リスト / 各セクションで保持する情報 / 各セクションに Raw·Table·CodeBlock·Formula·Image が必要か / 結論の付け方。
• Theme：選択したテーマ + 理由 + 競合の説明（references/theme-selection.md 参照）。
• Assets：画像戦略と画像ごとの計画（references/asset-policy.md 参照。none モードの場合はこのセクションは一文で十分）。

記事タイプのルーティングは references/article-types.md、情報密度とコンポーネント比率は references/information-density.md を参照してください。

自己チェック方法・強い制約：plan/plan.md を書き終えた後、メインAgentがインラインで5項目のPlan自己チェックリスト（references/review-checklist.md のPlan自己チェックセクション参照）に照らして確認し、結論に従って plan/plan.md を修正し、直接 Checkpoint 1 に入ります。SubAgent の起動、review/plan-review.md の作成は禁止です。

---

Phase 3 —— Plan Checkpoint（★ハードノード · Checkpoint 1、必ず停止すること）

鉄則：ユーザーに代わって静かに選択することを禁止。各決定項目は独立してリストアップし、独立してユーザーの応答を待つこと。

推奨することはできます（「理由は…なのでXを推奨します」）が、「すでにXに決めてあります。違う場合は教えてください」と言ってはいけません——後者はデフォルト値をこっそりと通し、選択の機会を奪うことになります。

収集方法（環境に応じて2択）：

• 優先 AskQuestion ツール：各項目を独立した質問として渡します（1回の呼び出しで複数の質問を渡せます）。ユーザーは選択カードで1つずつ確認できます。
• AskQuestion ツールがない場合：立ち止まり、メッセージですべての質問を番号付きでリストアップし + 各質問は段落を分け + 推奨項目 + 理由 + 選択肢を明確に書き、「あなたの回答を1つずつ待ってから続けます」と明確に伝え、後続の作業を一切進めないでください。

どちらの方法でも：各独立した決定は1つの独立した質問に対応します。「すべてOKですか？」という yes/no にまとめないでください。

必ず独立して確認する5項目（欠かせないもの）：

#	決定項目	選択肢（意味ラベル · デフォルト情報保持率を含む）	備考
1	記事タイプ（情報保持率を内包）	完全な長文 / アーカイブ longform · ~100% ／ 研究レポート / 正式な分析 full-report · ~80% ／ チュートリアル / 入門ガイド tutorial · ~90% ／ 概念 / システム解説 explainer · ~80% ／ 対話 / インタビュー / ポッドキャスト dialogue · ~80% ／ PR / 提案 / インシデントレビュー review · ~70% ／ 意見 / 評論 / ナラティブ essay · ~70% ／ インタラクティブラーニング / 概念を遊んで理解する interactive-explainer · ~25% 原文引用 + 75% AI 再構成 ／ 意思決定サマリー / 忙しい人向け briefing · ~50% ／ ビジュアル主体 / 拡散・展示用 visual-essay · ~40%	AI が1つを推奨し、理由を一文添える。比率はすでにタイプの選択肢に組み込まれているため、別途項目にしない（そうしないと longform + 20% のような疑似組み合わせが発生する）。ユーザーが標準から逸脱したい場合は、自由テキストで一言カバーする（「longform で60%にしたい」）。以下の「標準から逸脱する方法」を参照
2	テーマ	tufte / press / その他登録済みテーマ（theme-profiles/index.json を読む）	AI が1つを推奨し、理由を一文添える
3	レイアウト幅	narrow / regular / wide / full	AI が1つを推奨。デフォルトは regular
4	画像モード（必須選択 · 「デフォルトでOK」は不可）	none / user-assets / placeholders / ai-generated	ひとことで「外部 Image を使用するかどうかのみ決定。Raw は影響を受けない」と説明
5	表紙（3:4 の書籍カバー風タイトル画像、TOC + 本文の上に配置）	オン（デフォルト） / オフ	AI は「オン」を推奨し、構図のアイデアを一文添える（どのメインビジュアル + どの表紙テンプレート A/B/C/D/E を選ぶか）。briefing / dialogue の場合は「オフ」を推奨してもよい。詳細は references/cover.md を参照

TOC はデフォルトでオン：オン/オフのスイッチが1つだけで、ほぼすべての記事でオンにすべきなので、Plan Checkpoint の冒頭の説明で「デフォルトでTOCはオンです。オフにしたい場合は教えてください」と一言添えるだけでよく、独立した質問にする必要はありません。

すでにデフォルト値であり、個別に質問する必要がない事項（それでも冒頭の説明で「変更したい場合は教えてください」と明示し、ユーザーに撤回の機会を与える必要があります。完全に隠してはいけません）：

• 最終記事の言語：ソース言語に従う（ユーザーがすでに前文で指定している、または翻訳が完了している場合を除く）。
• 編集による削減、再構成、トーンの書き換えを許可するか：デフォルトで許可（上記の情報保持率に従って実行）。
• 最初の見開きのサンプルを先に見るか：デフォルトで先に作成する（これがPhase 4）。
• TOC：デフォルトでオン。

テーマについてユーザーが「あなたに任せる」と言った場合 → あなたが推奨する最初のものを採用します。それでも選択肢の中では、それを他の候補と並べて表示し、「デフォルト · AI推奨」とマークし、撤回の余地を残します。テーマの質問を飛ばしてはいけません。

情報保持率の「標準」から逸脱する方法：各記事タイプには推奨保持率が組み込まれています（上の表を参照）。ほとんどの場合、標準で問題ありません。ユーザーが微調整したい場合（例：「longform だけど60%だけにして」→ 深く編集された長文）、ユーザーに冒頭の説明の後の自由テキストで「<タイプ> + <X%>にしたい」と一言書いてもらいます。AI はその上書きを受け取ったら、plan/plan.md のBriefセクションに「タイプ / 標準保持率 / ユーザーによる上書き X%」を同時に記録し、ユーザーにこれが「非標準の組み合わせ」であることを警告します。このような組み合わせでは、メインAgentが各セクションを作成する際に、テキスト/ビジュアルの比率を手動で調整する必要があります。

Plan Checkpoint 冒頭メッセージテンプレート（決定を収集する前に、まず短い説明を送信します）：

plan/plan.md を作成しました（自己チェック済み）。以下の5項目について、1つずつ確認させてください：記事タイプ / テーマ / レイアウト幅 / 画像モード / 表紙。

私の推奨は以下の通りです（選択はしません）：
- タイプ：<X>（デフォルト情報保持率 <Y%>。理由：…）
- テーマ：<theme>（理由：…）
- レイアウト幅：<width>（理由：…）
- 画像モード：<戦略>（理由：…）
- 表紙：オン / オフ（理由：…。オンの場合、構図アイデア：…）

デフォルトで進むが、変更可能なもの：言語はソースに従う。編集による削減・再構成を許可。TOCはオン。次に最初の見開きサンプルを作成します。
情報保持率をタイプの標準から逸脱させたい場合は、以下の回答と一緒に具体的なパーセンテージを直接お知らせください（例：「longform だけど60%だけ」）。

以下、項目ごとに確認をお願いします。

上の説明を送信した後、すぐに AskQuestion で5つの質問を送信するか（またはツールがない環境では5つの質問を番号付きでリストアップし、応答を待ちます）。5項目すべての回答が揃って初めて Phase 4 に進むことができます。ユーザーが自由テキストで「非標準の保持率」を指定した場合、まず AI がそれを plan/plan.md に記録したことを確認してから Phase 4 に進んでください。

---

Phase 4 —— First Spread（記事版「第一章承認」）

まず「表紙（オンの場合）+ 最初の画面 + 最初のセクション + 代表的なビジュアルブロック」を作成します。スキャフォールドはここでワークスペースを作成します：

# デフォルトで表紙オン
bash <path-to-beautiful-article>/scripts/scaffold.sh ./my-article --theme=<id>
# Checkpoint 1 でユーザーが「表紙・オフ」を選んだ場合
bash <path-to-beautiful-article>/scripts/scaffold.sh ./my-article --theme=<id> --no-cover
bash <path-to-beautiful-article>/scripts/scaffold.sh --list-themes

これにより、Vite + React + TS のワークスペース（npm から最新の reacticle リリース版をインストール）+ source/ plan/ review/ 記憶ディレクトリ + アセンブラ article/Article.tsx + サンプルセクションコンポーネント（+ デフォルトの article/Cover.tsx、--no-cover の場合を除く）が作成されます。詳細は references/scaffold.md を参照してください。

最初の画面（Hero / Lead）はアセンブラ article/Article.tsx に記述します。最初のセクションは独立したコンポーネントファイル article/sections/01-*.tsx として記述する必要があります（これは以降の並列処理のコードアンカーとなります。references/section-build.md 参照）。表紙（オンの場合）は article/Cover.tsx 内の <CoverPlaceholder /> を、テーマと記事の主題に合わせてカスタマイズした図版構成に置き換えます。外殻（3:4コンテナ + 印刷改ページ）は変更しないでください。表紙デザインガイドは references/cover.md を参照してください。npm run dev でプレビューします。これにより、タイトルの雰囲気 / フォントサイズ / コンテンツ密度 / Rawスタイル / 画像配置方法 / テーマの適合性が決まります。

最初のセクションが完了したら、厳格な品質チェックプロトコルに従って First Spread Reviewer SubAgent を作成し、review/first-spread-review.md を書き（表紙の5項目自己チェックを含む。 references/cover.md 参照）、修正してから Checkpoint 2 に進みます。

---

Checkpoint 2 · First Spread（★ハードノード、必ず停止すること）

ユーザーに最初の画面 + 最初のセクションを承認してもらい、その後の開発モードを選択してもらいます。Checkpoint 1 の意思決定収集の鉄則がここでも適用されます：2項目は独立して確認し、まとめてはいけません。優先的に AskQuestion を使用し、ツールがない場合は番号付きでリストアップし、応答を待ちます。

まず短いメッセージを送信します：

最初の画面 + 最初のセクションが完了しました。npm run dev で localhost でプレビューできます。
品質チェックの結論は review/first-spread-review.md にあります（fail項目に従って修正済み。修正内容を列挙）。
以下の2項目について、独立して確認をお願いします：1) 承認結論 2) その後の開発モード。

その後、AskQuestion で2つの独立した質問を送信するか（または番号付きで2つの質問をリストアップし、応答を待ちます）：

1. 承認結論 —— 選択肢：承認・完全生成へ進む / 部分的修正・修正箇所を別途指示します / テーマまたはレイアウトが不適切・Checkpoint 1 に戻る。
2. その後の開発モード —— 選択肢：A・単一Agent順次（デフォルト・最も安定・スタイルが最も統一される） / B・複数Agent並列（最速・スタイルにわずかな差異が出る可能性あり）。

これら2つを「承認 + A、OKですか？」のようにまとめてはいけません —— ユーザーが「承認だけどBを使いたい」場合やその逆の場合があります。両方の質問の回答が揃ってから Phase 5 に進みます。

---

Phase 5 —— Full Article Build

Checkpoint 2 で選択された開発モードに従って、完全な記事を生成します。詳細は references/section-build.md + references/component-policy.md + references/raw-policy.md を参照してください。

鉄則・各セクションは独立したコンポーネントファイル（article/sections/NN-*.tsx）でなければなりません。複数のセクションを1つのコンポーネントに直接記述することは固く禁じます。article/Article.tsx は単なる アセンブラであり、各セクションをインポートして並べ替える役割を持ち、メインAgentが所有します。大規模なRawブロックも同様に article/raw-blocks/NN-*.tsx に分離します。ファイルレベルの分離は、マルチAgent並列処理の前提条件です。

開発モード（Checkpoint 2 で選択）：

• A・単一Agent順次（デフォルト）：メインAgentが各 sections/NN-*.tsx を順番に記述します。最も安定し、スタイルが最も統一されます。
• B・複数Agent並列：サブAgentが各1つの sections/NN-*.tsx ファイルを所有して並列開発します。メインAgentはマージと安定性に責任を持ちます —— Article.tsx のインポートと順序を維持し、npm run typecheck / build を実行し、テーマとスタイルの一貫性を確保し、競合を解決します。サブAgentのプロンプトテンプレートは references/section-build.md にあります。

その他の原則：本文が主体です。すべてのRawブロックは --ra-* テーマトークンを使用し、野生のスタイルは禁止です。100%の情報保持は長文構造を基本とし、Raw/画像で拡張します。情報密度が低い場合はビジュアルブロックの比率を高めることができますが、それでも記事の形態である必要があります。

各セクションが完了したら、必ず厳格な品質チェックプロトコルに従って Section Reviewer SubAgent を実行します：アウトラインのタスクを完了しているか / 情報保持率を遵守しているか / 前後のセクションと接続しているか / 過度にコンポーネント化されていないか / 十分な本文があるか / Rawと画像に明確な目的があるか / このセクションの番号が自己無撞着か。

SubAgent はメッセージで pass/fail + 修正点を返します（pass の場合は一行「OK」。fail の場合は修正点をリストアップします）。review/section-NN-review.md ファイルは作成しないでください。メインAgentは fail 項目を受け取ったら、対応するセクションファイルを直接修正し、その後このセクションの完了を報告します。

---

Phase 6 —— Final Review（3視点最終レビュー）

読者 / テーマ / 技術の3つの視点から検収し、review/final-review.md + 修正リストを作成します。 完全なハードチェックリストは references/review-checklist.md にあります。3名のReviewer（Teamsがない場合は少なくとも1名の独立したSubAgent）を推奨します：

1. Editorial Reviewer：記事としての質、情報の取捨選択、構造。
2. Visual Reviewer：テーマ、Raw、画像、モバイル対応。
3. Technical Reviewer：ビルド、コンソール、コード/数式、アクセシビリティ。

核心的なレッドライン：それがまだ1つの記事であること（アプリケーションではない）・情報保持率が計画に沿っていること・必須保持情報が欠落していないこと・テーマの雰囲気が統一されていること・Rawに野生のスタイルがないこと・明らかなAI臭がないこと・デスクトップ+モバイルで読めること・HTMLがビルドでき、開けて、共有できること。

---

Phase 7 —— Repair（最小単位の修正）

最小単位で修正します。ルールは references/repair-policy.md を参照してください。禁止：1か所指摘しただけで記事全体を書き直すこと / 修正のために確認済みの記事構造を変更すること / 情報を圧縮するためにユーザーが指定した必須保持内容を削除すること。修正があった場合のみ review/repair-log.md を作成します（修正なし / 一発合格の場合は作成しません）。

---

Checkpoint 3 · Final（★納品確認）

最終レビューと修正が完了したら、立ち止まってユーザーに納品可否を独立して確認させてください（「HTMLをエクスポートします。問題なければこのままで」とスキップしてはいけません）。優先的に AskQuestion を使用し、ツールがない場合はメッセージで質問を番号付きでリストアップし、応答を待ちます。

• 納品可否 —— 選択肢：承認・HTMLを出力して納品 / 承認・HTMLとPDFを同時に出力 / まだ部分的に修正が必要・修正箇所を具体的に指示します / 一旦停止・もう一度確認したい。

決定項目はこれ1つだけですが、それでも積極的に立ち止まって質問し、静かにデフォルトのHTML出力に進んではいけません。

---

Phase 8 —— Delivery

ビルドして納品します（コマンドは references/html-output.md を参照）：

• article/article.html（自己完結型単一ページ、CSS + JS インライン、オフラインでも開ける）—— 主要納品物。
• オプション article/article.pdf：Checkpoint 3 でユーザーが「承認・HTMLとPDFを同時に出力」を選択した場合のみ生成します。コマンド：

  bash <path-to-beautiful-article>/scripts/html-to-pdf.sh
  

  スクリプトはシステムを検出します

…

[truncated for translation]