delegate-htmldoc
Skill3 starsChanged 5 months agoMITView on GitHub
token cost の削減とデザインの一貫性確保を目標として、固定デザインテンプレートに沿った 自己完結型 HTML ドキュメントの生成を安価な subagent に委譲するスキル。 調査結果・レポート・issue まとめ・技術資料・議事録などを「HTML で」「ドキュメントにして」 「レポート化して」といった形で文書化する要求に使う。 同梱テンプレートの CSS と component 語彙に content を流し込むため、実行ごとのデザイン揺れがない。 対象は静的文書のみ。ダッシュボードなどインタラクティブ・JS を要する成果物、 デザインの新規設計、Web アプリの UI 実装には使わない(delegate-implement を使う)。 htmldoc の作業を委譲する場合は、この skill を使う。generic な subagent で代替しない。
In this repository9 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- delegate-choreSkill
- delegate-exploreSkill
- delegate-imagegenSkill
- delegate-implementSkill
- delegate-proseSkill
- delegate-reviewSkill
- delegate-x-researchSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 59
run は内部で prepare → dispatch → read-response を順に実行し、stdout は成功・失敗とも単一 JSON(exit_code / status / content / content_truncated / response_file …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
delegate-htmldoc
固定テンプレートに沿った HTML ドキュメント生成を委譲する。task_type=htmldoc、既定モデル haiku(テンプレート固定の流し込み作業のため判断比重が低い)。実行系分岐(Codex / Devin / Cursor / Claude / OpenCode)は dispatch.sh が行う。opencode/<provider>/<model> を使う場合は opencode CLI(ログイン済み)が必要。
スクリプトパス
- Claude Code:
skill_dir=.claude/skills/delegate-htmldoc - Codex:
skill_dir=.agents/skills/delegate-htmldoc
以降のコマンド例は Claude Code の .claude/skills/delegate-htmldoc を使う。Codex で使う場合は、同じ相対構造の .agents/skills/delegate-htmldoc に読み替える。
モデル価格参照
コスト分析・単価比較が必要な場合のみ、<skill_dir>/model-token-prices.json を読む。このデータは参照用であり、delegate の起動可否判定には使わない。
テンプレートと component 語彙
デザインは skill 同梱の固定資産で担保する。worker に CSS やレイアウトを生成させない。
<skill_dir>/references/template.html: 完成した CSS と全 component の使用例を含むテンプレート<skill_dir>/references/styleguide.md: component 語彙と執筆ルール
request の Context には両ファイルのパスを必ず記載し、worker にテンプレートをコピーして content だけを流し込ませる。main がテンプレート本文を読み込んで request に貼ることはしない(パス参照で足りる)。
図・画像素材
素材は親側で用意し、request にパスで渡す。worker に素材を生成・加工・取得させない。
- チャート・図解が必要なら、先に dataviz-svg(SVG 生成)や delegate-imagegen(ラスタ画像生成)で素材を作り、そのファイルパスを Context に列挙する
- SVG は worker がファイル内容を figure component へインライン埋め込みする(単一ファイル性を保つ)
- ラスタ画像は worker が出力 HTML と同じディレクトリ配下(例:
assets/)へコピーし、相対パスで参照する。この場合の成果物は「出力ディレクトリ一式」になる
委譲する前に(コストゲート)
htmldoc は文書本文の生成(出力 token)が嵩むほど効果が出る。まとまった分量の調査結果・レポート・複数セクションの資料は委譲する。一方、main が既に全 content を持っていて数行の HTML 断片を書けば済む場合や、既存 HTML の 1 箇所修正は main が直接処理する。
適性ゲート: 受けるのはテンプレートの component 語彙で表現できる静的文書だけ。ダッシュボードやインタラクティブな画面(フィルタ・タブ・動的更新・チャートライブラリ等の JS 前提)、レイアウト・デザインの新規設計が本体の成果物は、分量にかかわらず対象外として delegate-implement へ委譲する。
実行フロー(one-shot)
- リクエスト作成: Objective / Scope / Context / Acceptance criteria / Verification / Constraints の Markdown を stdin で渡す。request は terse に書く: 文書化する source(ファイル・issue・調査結果)はパスや URL で参照させ、本文を貼らない。Context に
references/template.htmlとreferences/styleguide.mdのパス、および使用する図・画像素材のパスを記載する。Constraints に出力ファイルパスを明記する(ユーザー指定がなければdelegate-htmldoc-output/配下)。- ユーザーが会話でモデルや effort を指定した場合は、run 呼び出しにインライン env を前置する(例:
DELEGATE_HTMLDOC_MODEL=gpt-5.5@high bash .../run.sh ...)。exit 6 の場合は、許容値列挙を含む stderr の 1 行をそのままユーザーへの説明に使う。
- ユーザーが会話でモデルや effort を指定した場合は、run 呼び出しにインライン env を前置する(例:
- 実行:
out="$(printf '%s' "$req_md" | bash .claude/skills/delegate-htmldoc/scripts/run.sh htmldoc DELEGATE_HTMLDOC_MODEL haiku "$PARENT_TASK_TYPE_CHAIN" "$REQUESTER_SESSION_ID")"(top-level 起動なら$PARENT_TASK_TYPE_CHAINは空でよい)。- run は内部で prepare → dispatch → read-response を順に実行し、stdout は成功・失敗とも単一 JSON(
exit_code/status/content/content_truncated/response_file/observe_file/run_dir)を返す。 - selector 省略時の既定は
auto。第 6 位置引数は read-response の selector であり、prepare.sh の第 6 位置引数 session_mode とは意味が異なる。 - exit code は内部スクリプトを透過する。exit 3=前提不足 / exit 4=委譲サイクルなら中止する。
run.shは dispatch 前にobserve_file: <path>を stderr へ先出しする。run.shが Bash timeout で background へ退避しただけの場合は再実行しない(再実行は worker の二重起動になり、implement / chore では同一 worktree の同時書き換えになる)。復旧はbash .claude/skills/delegate-htmldoc/scripts/read-json.sh .state.phase "$observe_file"を見て分岐する。ended/stalled/interruptedなら終端なので、いずれでもbash .claude/skills/delegate-htmldoc/scripts/read-json.sh .run.response_file "$observe_file"で応答パスを取得してbash .claude/skills/delegate-htmldoc/scripts/read-response.shで読む(stalledでは failed response が書かれる。interruptedは dispatcher が終端を書けずに落ちた run を wrapper が代わりに記録したもので、.state.response_presentがtrueなら完走した response がある)。runningの間は.heartbeat.tsが進んでいれば待つ。runningのまま.heartbeat.tsがDELEGATE_OBSERVE_HEARTBEAT_INTERVAL(既定 10 秒)を大きく超えて進まない場合は dispatcher が終端を書けずに落ちている。wrapper も同時に落ちていれば phase は終端へ遷移しないので、待っても応答は来ない。新しい run を出す前に順に確認する。(1)read-json.sh .run.response_file "$observe_file"を読む。dispatcher だけが死んだ場合、wrapper が完全な response を書き終えていることがある。(2) response がChild CLI failed or did not write a response.の stub なら、read-json.sh .run.run_dir "$observe_file"の<run_dir>/worker-stdout.captureに子 CLI の生 stream が残っている。wrapper が finalize まで到達していれば observe の.streams.stdout.contentにもDELEGATE_OBSERVE_STREAM_MAX_BYTES(既定 65536 バイト)まで入る。構造化された response ではないが、長い run では再実行より安く回収できる。(3)read-json.sh .heartbeat.child_pid "$observe_file"の pid の生存を確認する。wrapper は dispatcher と別プロセスなので孤児化して動き続けることがあり、生きている間に implement / chore で新しい run を出すと同一 worktree の二重書き換えになる。確認後に新しい run を出す。background 退避した出力ファイルは stdout と stderr が合流するが、read-json.shは既知の harness 行(空行 /observe_file:行 /[exited with ...]行)に囲まれた JSON object を切り出して読める。- 非対話モードの親(
claude -p等)では run を必ずフォアグラウンドで実行し、委譲所要時間より長い Bash timeout(Claude Code ならBASH_DEFAULT_TIMEOUT_MS/BASH_MAX_TIMEOUT_MSまたは Bash tool の timeout 引数)を設定する。
- run は内部で prepare → dispatch → read-response を順に実行し、stdout は成功・失敗とも単一 JSON(
- レスポンス消費と検証:
status="$(printf '%s' "$out" | bash .claude/skills/delegate-htmldoc/scripts/read-json.sh .status)"/content="$(printf '%s' "$out" | bash .claude/skills/delegate-htmldoc/scripts/read-json.sh .content)"を読む。content_truncatedがtrueならresponse_file="$(printf '%s' "$out" | bash .claude/skills/delegate-htmldoc/scripts/read-json.sh .response_file)"を取り出し、bash .claude/skills/delegate-htmldoc/scripts/read-response.sh "$response_file" <N>で必要 section だけ段階読みする。読了後、worker の本文を 要約し直さない(echo しない)。statusがfailedなら Error section をユーザーへ伝える。completedでも Summary 先頭に警告行があればその旨を伝える(警告は response 本体に載るので selector に関わらず Summary とともに返る)。Changed filesのパスが存在することをtest -fで確認し、生成 HTML 全文は main の context に読み込まない。 - Artifact 共有の確認: main(Skill 実行者)が Claude で Artifact tool が利用可能な場合のみ、生成したドキュメントを artifact にもアップロードするかを AskUserQuestion で確認し、同じ質問でセクションのパーマリンク(見出し横の # でその位置への URL をコピー)を付けるかも確認する。希望された場合のみ、アップロードに必要な範囲で生成 HTML を読み込んでアップロードする。パーマリンクも希望された場合は、(a)
bash .claude/skills/delegate-htmldoc/scripts/htmldoc-permalink.sh <html>で注入し、(b) Artifact tool で publish して URL を得て、(c)bash .claude/skills/delegate-htmldoc/scripts/htmldoc-permalink.sh <html> <url>で URL を埋め込み、(d) 同じ file_path で再 publish する。htmldoc-permalink は再実行しても注入物を入れ直すだけで重複しない。注入物は worker 生成物ではなく JS 禁止規則と Verification の唯一の例外であり、worker には JS を書かせない。相対参照のラスタ画像を同梱する成果物は単体アップロードで画像が欠落するため、その旨を伝えて提案しない。Artifact が利用できない実行系(Codex / Devin / Cursor 等)ではこの手順を行わない。
高度なフロー(個別スクリプト)
dispatch 中の observe 監視、background 実行など、途中で親の判断を挟むフローでは従来の個別スクリプトを使う。
- 準備(集約): 前提チェック→モデル解決→チェーン確認→リクエスト生成を
prepare.sh1 本に畳む。Objective / Scope / Context / Acceptance criteria / Verification / Constraints の Markdown を stdin で渡す。request は terse に書く: 文書化する source(ファイル・issue・調査結果)はパスや URL で参照させ、本文を貼らない。Context にreferences/template.htmlとreferences/styleguide.mdのパス、および使用する図・画像素材のパスを記載する。Constraints に出力ファイルパスを明記する(ユーザー指定がなければdelegate-htmldoc-output/配下)。exit 3=前提不足 / exit 4=委譲サイクルなら中止。- ユーザーが会話でモデルや effort を指定した場合は、prepare 呼び出しにインライン env を前置する(例:
DELEGATE_HTMLDOC_MODEL=gpt-5.5@high bash .../prepare.sh ...)。prepare が exit 6 の場合は、許容値列挙を含む stderr の 1 行をそのままユーザーへの説明に使う。 out="$(printf '%s' "$req_md" | bash .claude/skills/delegate-htmldoc/scripts/prepare.sh htmldoc DELEGATE_HTMLDOC_MODEL haiku "$PARENT_TASK_TYPE_CHAIN" "$REQUESTER_SESSION_ID")"(top-level 起動なら$PARENT_TASK_TYPE_CHAINは空でよい)model="$(printf '%s' "$out" | bash .claude/skills/delegate-htmldoc/scripts/read-json.sh .model)"/request_file="$(printf '%s' "$out" | bash .claude/skills/delegate-htmldoc/scripts/read-json.sh .request_file)"/response_file="$(printf '%s' "$out" | bash .claude/skills/delegate-htmldoc/scripts/read-json.sh .response_file)"/run_dir="$(printf '%s' "$out" | bash .claude/skills/delegate-htmldoc/scripts/read-json.sh .run_dir)"/observe_file="$(printf '%s' "$out" | bash .claude/skills/delegate-htmldoc/scripts/read-json.sh .observe_file)"
- ユーザーが会話でモデルや effort を指定した場合は、prepare 呼び出しにインライン env を前置する(例:
- 実行:
bash .claude/skills/delegate-htmldoc/scripts/dispatch.sh "$model" htmldoc "$request_file" "$response_file" "$run_dir" "$observe_file"。モデル名プレフィックスによる実行系分岐(Codex / Devin / Cursor / Claude / OpenCode)は dispatch.sh が行う。stdout は response_file のパスのみ。非対話モードの親(claude -p等)では dispatch を必ずフォアグラウンドで実行し、委譲所要時間より長い Bash timeout(Claude Code ならBASH_DEFAULT_TIMEOUT_MS/BASH_MAX_TIMEOUT_MSまたは Bash tool の timeout 引数)を設定する。実行中の通常監視はobserve_fileからstate.phase/state.started_at/heartbeat.ts/heartbeat.stdout_bytes/heartbeat.stderr_bytes/heartbeat.last_stream_change_atだけを read-json.sh で読む。state.phaseはprepared | running | superseded | stalled | interrupted | ended。prepared/supersededは dispatch されなかった observe(state.started_at == null、usageは未設定で read-json.sh では null 相当)なので、usage を集計する場合は分母から除外する。 - レスポンス読み取り:
bash .claude/skills/delegate-htmldoc/scripts/read-response.sh "$response_file" auto。autoは response が小さい(既定 10KB 未満)なら status と全 section を 1 回で丸読みし、大きい場合は status + index + Summary section を返すので、必要 section だけ... "$response_file" <N>で追加取得する。読了後、worker の本文を 要約し直さない(echo しない)。statusがfailedなら Error section をユーザーへ伝える。completedでも Summary 先頭に警告行があればその旨を伝える(警告は response 本体に載るので selector に関わらず Summary とともに返る)。main のユーザー向け応答は Summary を指す 1 行に留める(main の出力=課金トークンを増やさないため。spec.md §6)。 - 検証:
Changed filesのパスが存在することをtest -fで確認する。生成 HTML 全文は main の context に読み込まない。 - Artifact 共有の確認: main(Skill 実行者)が Claude で Artifact tool が利用可能な場合のみ、生成したドキュメントを artifact にもアップロードするかを AskUserQuestion で確認し、同じ質問でセクションのパーマリンク(見出し横の # でその位置への URL をコピー)を付けるかも確認する。希望された場合のみ、アップロードに必要な範囲で生成 HTML を読み込んでアップロードする(このときだけ手順 4 の「全文を読み込まない」の例外とする)。パーマリンクも希望された場合は、(a)
bash .claude/skills/delegate-htmldoc/scripts/htmldoc-permalink.sh <html>で注入し、(b) Artifact tool で publish して URL を得て、(c)bash .claude/skills/delegate-htmldoc/scripts/htmldoc-permalink.sh <html> <url>で URL を埋め込み、(d) 同じ file_path で再 publish する。htmldoc-permalink は再実行しても注入物を入れ直すだけで重複しない。注入物は worker 生成物ではなく JS 禁止規則と Verification の唯一の例外であり、worker には JS を書かせない。対象はインライン SVG までで完結した単一 HTML のみとする。相対参照のラスタ画像を同梱する成果物(出力ディレクトリ一式)は単体アップロードで画像が欠落するため、その旨を伝えて提案しない。Artifact が利用できない実行系(Codex / Devin / Cursor 等)ではこの手順を行わない。
待ち時間の隠蔽(対話親向け)
対話親では体感待ち時間を隠蔽できる。経路は起動スクリプトで異なる。dispatch.sh 経由は prepare.sh で response_file を事前取得済みなので、dispatch.sh を background で実行し、observe_file の state.phase / heartbeat を確認して ended / stalled / interrupted になった後に read-response.sh する。run.sh 経由は response_file を事前に取得できないので、run.sh を background で実行した場合は read-json.sh .run.response_file "$observe_file" で応答パスを取るか、合流した出力 JSON をそのまま read-json.sh で読む。総所要時間(wall time)は変わらない体感改善であり、非対話モードの親では従来どおりフォアグラウンド実行必須。
Worker report
report の見出しは共有 wrapper が固定する標準構成(Summary / Changed files / Commands / Verification / Findings / Blockers / Error)に従う。htmldoc では各見出しを次のように使う。
Summary: 生成したドキュメントの短い説明Changed files: 作成した HTML ファイルのパスVerification: テンプレート CSS を変更していないこと、外部 URL 依存が無いこと(インライン SVG と同梱アセットの相対参照は可)、JavaScript を含まないこと(script 要素・イベントハンドラ属性・javascript:URL が無いこと)、目次 section が hero 直後にあり経緯・改訂履歴が末尾の history section に隔離されていることの確認Findings: 使用した component(hero / toc / section / table / conclusion / tasks / history 等)と文書構成、source の特記事項Blockers: source 不足・内容の矛盾・テンプレートで表現できない要求
制約
- 書き込みは指定された出力ディレクトリ配下(出力 HTML と素材コピー)と response の生成のみ。それ以外のリポジトリファイル編集・push はしない
- 図・画像は request で渡された素材のみ使用する。worker は素材を生成・加工・取得しない
- テンプレートの CSS・component 構造を変更しない。content の流し込みだけを行う(デザイン揺れを排除するため)
- 目次(toc)を hero 直後に、経緯記録(history)を footer 直前に必ず置く。時系列ログ・改訂履歴など経緯は history にのみ記載し、他 section は常に最新の仕様・事実だけを記載する
- JavaScript(script 要素・イベントハンドラ属性・
javascript:URL)を含めない。テンプレートで表現できない要求は作らずに Blockers で報告させる - 単発生成の種別のため session reuse(resumable / follow-up)は使わない。修正が必要なら新しい delegate run として出し直す
- task_type_chain 内種別への再委譲はしない(別種別 delegate は可)
- main は worker 出力を echo / 再要約しない。ユーザー向けは生成ファイルパスと Summary を指す 1 行に留める(出力=課金トークンを増やさないため。spec.md §6)
- OpenCode: cwd 外への出力は保証されない(direct な edit / write と明示パスの読み取りは拒否され、bash のリダイレクトは通る)。出力先を cwd 外に指定すると成功は保証されない。request が
DELEGATE_REQUEST_INLINE_MAXを超えると child 起動前に fail-closed する - OpenCode の read-only 抑止は管理者設定のない環境を前提とする(管理者設定は注入した permission を override し得る)
- この種別は常に
--pureで起動し、OpenCode の project plugin を読み込まない(plugin は任意コード実行で prompt 制約を迂回し得るため)。DELEGATE_OPENCODE_PUREが1/true/yesなら implement / chore を含む全 task type へ広げる。DELEGATE_OPENCODE_MCP_SOURCE(claude/cursor/codex)で MCP 入力元を明示し、未指定なら注入しない
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

