1仕組みと動作原理

テンプレート自体には実行可能コードが含まれていません：loader は src/lib/templates/skills/<id>/SKILL.md から frontmatter と本文を読み込み、本文（body）を example の内容とともに LoadedSkill として返します。

next/src/lib/templates/loader.ts

const raw = safeRead(path.join(dir, "SKILL.md"));

ここで行われていること：SKILL.md が動作の唯一のソースです——frontmatter はセレクター描画用（zh_name/emoji/aspect_hint/tags/example_* など）、本文全体がプロンプトとして機能します。loader は意味検証を行わず、テンプレートの記述をそのまま渡します。

配信前にホストがプロンプトを規定通りに組み立てます：テンプレート本文は SHARED_DESIGN_DIRECTIVES と【入力フォーマット】/【ユーザーコンテンツ】の間に挟まれます。

next/src/lib/templates/shared.ts

Wrap a per-template instruction body with the shared design directives and

ここで行われていること：テンプレートは「この成果物がどのような外観であるか」（レイアウト/リズム/コンポーネント）のみを定義し、共通指示がテンプレート横断のハード制約（単一ファイル HTML、ファイル操作ツールの禁止、Tailwind および Google Fonts の CDN 経由、コンテンツの真実性、CJK スペース規則）を担います。

共通指示はハード制約をエージェントへの明示的な禁止事項として規定し、コンテンツ駆動による数量決定を強制します（テンプレート内の数値は最小限の参考値にすぎません）。

next/src/lib/templates/shared.ts

**禁止使用 Write / Edit / MultiEdit / Bash / Create / 任何文件系统工具**。

同一ファイル内には次の規則もあります：出力される slide / frame / card / section の数量は、【ユーザーコンテンツ】の実際の長さと情報構造によって完全に決定されます。これにより、コンテンツが長くなってもテンプレートが破綻しない理由が説明されます：各コンテンツブロックにつき最低1つのカード/セクションが割り当てられ、テンプレートはレイアウトプールのみを提供します。

実際に実行を行うのはユーザーのローカル環境にインストールされログイン済みのコーディングエージェント CLI です：ホストが子プロセスを spawn し、プロンプトを渡し、HTML を stdout からストリーミング取得します。

next/src/lib/agents/invoke.ts

import { spawn, type ChildProcessWithoutNullStreams } from "node:child_process";

ここで行われていること：テンプレート skill はプロンプトを提供するのみで、実行能力（コード生成やツール実行を含む）はホスト CLI の既存権限に依存します。skill ディレクトリ自体にはスクリプトのエントリポイントが存在しないため、判定はディレクトリ内のアセットのみを対象とします（ホストの動作は評価対象外）。

/api/convert はテンプレートの実行パスです：skill.body とユーザーコンテンツをプロンプトとして組み立て、invokeAgent に引き渡します。

next/src/app/api/convert/route.ts

prompt = assemblePrompt({ body: skill.body, content, format });

編集モードでは別途 buildEditPrompt が呼び出されます（差分を最小限に抑えた編集、ファイルツールの禁止、完全な HTML の直接ストリーミング出力を要求）。そのため本種別のテンプレートの成果物は安定した構成を保ちます：単一ファイル HTML、インライン CSS/SVG、外部参照はフォントと一部テンプレートが明示的に要求するチャートライブラリのみに限定されます。

テンプレートの核心は9つの固定構造です：Header、Executive takeaway、Positioning map から 30/90/180日間の Recommended moves に至るまで、セクションの欠落は不合格とみなされます。