content-template-gateway

コンテンツテンプレートゲートウェイ

概要

content-template-gateway は、このプロジェクトでエージェントが作成するあらゆる構造化コンテンツの標準的な入口です。出力先を問いません。ユーザーまたはエージェントが、以下のいずれかの対象に配置するコンテンツを作成しようとする場合は、必ず最初にこのスキルを呼び出します。

• コンテンツタイプ（テンプレート選択の基準）：RFC、ADR、事後分析、運用手順書、仕様書、計画書、PRD、概要資料、ロードマップ、README、チュートリアル、リリースノート、振り返り、状況報告、議事録、履歴書、カバーレター、ブログ記事、GitHub の PR の説明／issue の本文／PR または issue のコメント、Jira または Linear のチケット、複数段落のコミットメッセージ、Slack またはメールでのお知らせ、その他、構造化されたテンプレートに沿う形式。
• 出力先（コンテンツタイプとは独立しており、同じコンテンツタイプをいずれにも配置できます）：ローカルの Markdown ファイル、GitHub（gh ... 経由の PR／issue／コメント本文）、Jira／Linear（API またはウェブ）、Confluence、Notion、Google Drive、Slack、メール、または将来登場する、エージェントが作成した構造化文章を受け付けるあらゆるシステム。テンプレートの選択はコンテンツタイプに基づき、出力先は Phase C の指示に含まれる付随的なメタデータです。

このスキルは、(a) 調査を通じてユーザー／エージェントの意図からコンテンツタイプとバリアントを特定し、(b) docs/templates/<content-type>/<variant>/ に既存のテンプレートがあるか確認し、(c) テンプレートが存在する場合は、明確な拒否指示によってテンプレートの使用を徹底し、(d) テンプレートがない場合は、調査に基づくワークフローを通じて新たなテンプレートを作成し、(e) ユーザーから依頼された場合は、当てはまらないコンテンツの配置方法について助言します。

このスキルは単独で動作します。調査機能を備えたスキルがインストールされている場合はそちらを優先しますが、どの環境でも動作するよう、内蔵の WebSearch と WebFetch に切り替えることもできます。

起動するタイミング

• ユーザーが、どの出力先であっても、構造化コンテンツの作成を依頼した場合。 主な起動条件です。
• エージェントが、どの出力先であっても、構造化コンテンツを作成しようとしている場合。 ユーザーがテンプレートを明示的に要求していない場合でも、エージェントであるあなたが以下のいずれかを実行しようとしているなら、まずこのスキルを起動します。これはユーザーが起動する場合と同様に必須です。例（これらに限定されません）：
  • temp-spec-*.md、temp-plan-*.md、docs/<type>/<name>.md、サブディレクトリ用の README など、新しい文書形式のファイルや、構造化テンプレートに沿う成果物を作成する。
  • 重要な内容を含む本文を指定して、gh pr create、gh issue create、gh pr comment、gh issue comment を実行する。
  • Jira／Linear のチケットを作成する、またはその説明文を作成する。
  • 複数段落の git commit 本文を作成する。
  • 長文の Slack／メールメッセージを投稿する、または Confluence／Notion ページを公開する。
• ユーザーが既存のテンプレートの再作成を依頼した場合（モード force-regenerate）。
• ユーザーが既存のコンテンツタイプに新しいバリアントを追加するよう依頼した場合（モード force-new-variant）。
• ユーザーが「advise: 自分のコンテンツが当てはまりません」と伝えた場合。Phase E を起動します。
• ユーザーがスキルを明示的に起動した場合（例：/content-template-gateway）。

起動しない場合：

• ユーザーがプロジェクト構成のひな形作成（例：「Python の uv ワークスペースを作成して」）を希望している場合。別のスキルを使用します。
• ユーザーが既存のテンプレートを別の言語または形式に翻訳したい場合。対象外です。
• ユーザーがテンプレートに実際の内容を記入したい場合（テンプレートを具体化する場合）。それは利用する側のエージェントの役割です。このスキルが返すのはテンプレートと指示のみです。
• ユーザーがすでに作成されたコンテンツの誤字、書式、明瞭さを修正している場合。このスキルの対象は新しいコンテンツの作成であり、既存コンテンツの編集ではありません。
• ユーザーが「テンプレートは不要です。簡単なメモで」と明示した場合。（この場合は例外となり、ブロックはされませんが、スキルは自動的に起動しません。）
• 1 行だけの内容や、簡単な内容（1 行のコミットメッセージ、1 行の Slack 返信、短いコードコメント）。このスキルの対象は、複数のセクションから成る構造化コンテンツです。

ワークフロー

フェーズ A — 特定

入力：

• ユーザー／エージェントの自由記述による意図（例：「API を再起動するためのランブックを書きたい」、または「認証リファクタリングのために gh pr create を実行しようとしています」）。
• 出力先のヒント（ファイルパス、gh pr、gh issue、jira、linear、slack、commit-msg、confluence など）。意図の表現や、これから実行するツール呼び出しから推測します。不明な場合は確認します。
• 任意の明示的なモードのヒント（デフォルトは use-or-create、force-regenerate、force-new-variant）。
• 任意の明示的なコンテンツタイプおよび／またはバリアントの上書き指定。

アクションの順序：

1. 意図からモードを検出します。 ユーザーの表現に基づいてモードを設定します。
   • 次の表現があれば force-regenerate を指定します：「X を再生成する」「X テンプレートを再生成する」「X を更新する」「X テンプレートを更新する」「X をやり直す」。
   • 次の表現があれば force-new-variant を指定します：「新しいバリアントを追加する」「X という名前のバリアントを作成する」「Y の新しいバリアントとして X を作成する」。
   • それ以外の場合は、デフォルトの use-or-create を指定します。
2. コンテンツタイプとバリアントを調査します。 次の調査手順を使用します。有効な場合は deep-research スキル（199-biotechnologies/claude-deep-research-skill — 信頼性評価と引用追跡を伴う複数ソース調査）を優先します。そうでない場合は、他の調査機能を備えたスキルを使用します。いずれも使えない場合は、組み込みの WebSearch と WebFetch を使用します。（実際の調査方法については ## Research methodology を参照してください。）
3. 曖昧さに対処します。 調査の結果、候補となるコンテンツタイプが 2～3 個ある場合は、それぞれを 1 行で説明し、ユーザーに選択してもらいます。
4. スラッグのルールを適用し、正規の <content-type> および <variant> スラッグを生成します（小文字とハイフンを使用し、バリアントからコンテンツタイプの語を削除し、30 文字で切り捨て、予約済みのバリアントスラッグ README／template／research／.*／_* を使用しない）。
5. スラッグを確認します。 次のように表示します：「docs/templates/<content-type>/<variant>/ を確認します。確認するか、名前を変更してください。」

失敗時の処理： 調査後もフェーズ A で特定できない場合は、詳細情報を求めます。最大 2 回まで確認します。その後、force-new-variant モードのヒントを付けて中止します。

フェーズ B への出力： content-type スラッグ、variant スラッグ、mode、destination。

フェーズ B — 確認

フェーズ A からの入力： content-type、variant、mode、destination。

アクションの順序：

1. docs/templates/<content-type>/<variant>/ を次のように分類します。

   • 完全 — template.md と research.md の両方が存在します。
   • 欠落 — フォルダーが存在しません。
   • 不完全な残存フォルダー — フォルダーは存在しますが、template.md、research.md、または forge: フロントマターが欠落しています。

2. モードと状態に応じて分岐します。

   モード	状態	次の処理
   use-or-create	完全	→ フェーズ C
   use-or-create	欠落	→ フェーズ D、次に C
   use-or-create	不完全	→ 不完全フォルダーのサブメニュー（下記を参照）、次に再分類
   force-regenerate	完全または不完全	→ フェーズ D（上書き）、次に C
   force-regenerate	欠落	→ フェーズ D、次に C
   force-new-variant	完全	→ スラッグの衝突。別のスラッグを尋ね、B に戻る
   force-new-variant	欠落	→ フェーズ D、次に C
   force-new-variant	不完全	→ まず不完全フォルダーのサブメニューを表示し、次に再分類

不完全フォルダーのサブメニュー（上の表から参照）：

検出した不完全なバリアントフォルダーごとに、ユーザーに確認します。

不完全なバリアントフォルダーが見つかりました：<content-type>/<slug>（欠落：template.md および／または research.md および／または forge: フロントマター）。 どのようにしますか？

1. 再生成する（このスラッグでフェーズ D を再実行）
2. 削除する
3. そのままにする（スキップ。次回の実行時に再度表示）

選択を適用した後、フォルダーを再分類し、分岐表に従って続行します。

フェーズ C または D への出力： 検証済みの content-type、variant、destination、および should_forge フラグ。

フェーズ C — 適用

入力： 検証済みの content-type、variant、destination。テンプレートファイルは docs/templates/<content-type>/<variant>/ に存在します。

アクションの順序：

1. template.md と research.md を読み込みます。

2. 返却するペイロードを組み立てます。

   ═══════════════════════════════════════════════════════════════
     TEMPLATE DIRECTIVE — MUST FOLLOW
   ═══════════════════════════════════════════════════════════════
   
   You are about to author content of type: <content-type>
   Variant: <variant>
   Destination: <destination>          (file path, gh pr, jira, slack, ...)
   Template source: docs/templates/<content-type>/<variant>/template.md
   
   RULES:
     1. You MUST follow the template structure below — section headings,
        order, and required fields are not negotiable.
     2. You MAY add placeholder text or fill in sections, but you MUST
        NOT remove or rename sections.
     3. If your content does not fit any section in the template, STOP
        and invoke content-template-gateway with intent "advise: I have
        content that doesn't fit" — do NOT improvise sections.
     4. You MUST author the content INTO the template before performing
        any destination-side action (writing the file, calling
        `gh pr create`, posting the ticket, sending the message, etc.).
        Do NOT call the destination first and patch later.
     5. If you proceed without this template, you are violating
        the project's "templates first" norm.
   
   ═══════════════════════════════════════════════════════════════
     TEMPLATE CONTENT — copy and fill in below
   ═══════════════════════════════════════════════════════════════
   
   <full template.md content>
   
   ═══════════════════════════════════════════════════════════════
     RESEARCH NOTES — for your reference (not required reading)
   ═══════════════════════════════════════════════════════════════
   
   <research.md content>
   

3. 組み立てたペイロードを呼び出し元に返します。

ユーザーへの確認はありません。出力の組み立てのみを行います。

Phase D — 作成（サブ手順）

呼び出し元： Phase B（不足または孤立解決済み）、またはモードが force-regenerate / force-new-variant の場合に直接呼び出されます。

アクションの流れ：

1. フォールバックチェーンを使って、コンテンツタイプの初期調査を行います。（方法については ## Research methodology を参照してください。）

2. バリアントを提案します。 モードが force-regenerate または force-new-variant の場合、この手順は完全に省略します。バリアント名はすでに Phase A の出力で指定されているためです。それ以外（モード = use-or-create）の場合は、1 行の説明と自動導出されたスラッグを付けた候補を 2～4 件提示します。ユーザーは候補一覧を承認するか、編集するか、新たな調査を依頼します。

3. バリアントごとに詳細調査を行います。バリアントのより限定された範囲に合わせて、フォールバックチェーンを再実行します。（## Research methodology を参照してください。）失敗した場合は、1 回再試行してからサブメニュー（再試行 / スキップ / キャンセル）を表示します。

4. 成果物を（次の順序で）出力します。

   1. 各バリアントについて、template.md、続いて research.md を docs/templates/<content-type>/<variant>/ に書き込みます。どちらにも forge: のフロントマター（status: unreviewed、forged: <YYYY-MM-DD>、reviewed: null）を含めます。
   2. すべてのバリアントを書き込んだ後、バリアントのインデックスとして docs/templates/<content-type>/README.md を更新します。
   3. スキップされたバリアントはフォルダーを作成せず、README.md にも含めません。

5. 次の形式で、Forge の終了時の概要を呼び出し元に出力します。

   Forge complete for `<content-type>`.
   
   Emitted:
     • <variant-1>  (docs/templates/<content-type>/<variant-1>/)
     • <variant-2>  (docs/templates/<content-type>/<variant-2>/)
   
   Skipped (research failed):
     • <variant-3> — retry by re-invoking with mode `force-new-variant`
   

   すべてのバリアントの作成に成功した場合、「Skipped」ブロック全体を省略します。

Phase C への出力： 呼び出し元が指定したテンプレートの content-type と variant。

Phase E — アドバイス（サブ手順）

呼び出し元： 意図が「advise:」パターンに一致する場合の Phase A。

入力： 現在適用されているテンプレートの content-type と variant、およびテンプレートに合わないユーザーのコンテンツ。

アクションの流れ：

1. 現在の template.md と research.md を読み込みます。
2. フォールバックチェーンを使って配置を調査します。このコンテンツタイプでは、この種のコンテンツは通常どのように配置されますか？（## Research methodology を参照してください。）
3. 判断して分岐します。
   • 既存のバリアントに収まる場合 → 配置の推奨を返します（段落 N → ## SectionName）。
   • 収まらない場合 → 不足しているセクションを含む新しいバリアントを提案します。ユーザーに、はい（新しいバリアントのために Phase D を呼び出す）／いいえ（既存のバリアントへの最善の配置案を返す）／調整（提案の何を変更するかユーザーが説明。最大 2 回の調整を行い、その後、最善の案を採用するか、配置の推奨にフォールバックして中止）を尋ねます。

出力： 配置の推奨（プレーンテキスト）または新しいテンプレートと指示（Phase D → Phase C 経由）。

Research methodology

すべての調査呼び出し（Phase A、Phase D のステップ 1 と 3、Phase E）は、この方法に従います。

調査呼び出しごとの目標

• Phase A — 特定。 「これはどのコンテンツタイプか？どのようなバリアントがあるか？ユーザーの意図に最も合うバリアントはどれか？」
• Phase D のステップ 1 — 初期調査。 「このコンテンツタイプの一般的な概要は？代表的な例は？」
• Phase D のステップ 3 — バリアントごとの詳細調査。 「この特定のバリアントには、慣例的にどのようなセクションや構成があるか？」
• Phase E — 配置。 「このテンプレートの文脈では、このコンテンツは慣例的にどこに配置されるか？それとも、新しいバリアントが必要か？」

情報源の品質レベル（上位を優先）

1. 公式／標準的な参照資料 — 原典となる仕様（例：ADR に関する Michael Nygard の記事）、公式ドキュメント、言語／フレームワークのリファレンスドキュメント、掲載先プラットフォームのドキュメント（GitHub の PR テンプレートのガイダンス、Atlassian の Jira チケットガイドなど）。
2. 相互に裏付け合う複数のエンジニアリングブログ — Google SRE Book、Atlassian Handbook、GitLab のドキュメント、有名企業のエンジニアリングブログなど、確立された情報源。
3. 信頼できる単一の情報源 — 使用可能ですが、research.md で単一情報源として明記します。
4. 避けるべき情報源 — 裏付けのない Stack Overflow の個別回答、AI 生成コンテンツを量産するサイト、出典が不明な個人のチュートリアル。

クエリパターン（広く → 狭く）

1. 広く：「what is a <content-type>」— 大まかな構成を確認します。
2. 構造：「<content-type> template / sections / structure」
3. バリエーション：「<content-type> variants / types」
4. 例：「<content-type> example」— 提案したセクションが実例にも含まれているか確認します。

セクションを「標準」と判断する前に必要な最小限の情報源

• 2つ以上の独立した情報源にそのセクションが含まれている場合に限り、そのバリエーションの標準として扱います。
• 情報源が1つのみ → テンプレートには含めますが、research.md でそのセクションに「単一情報源。依拠する前に確認すること」と注記します。
• 情報源に矛盾がある場合 → research.md に両方の解釈を示し、ユーザーの想定する文脈に基づいて選ぶか、ユーザーに確認します。

出力前の検証項目

• 提案する template.md 内のすべてのセクションが、そのバリエーションの実例に少なくとも2つ登場していること。
• バリエーションが実質的に異なること — 提案する2つのバリエーションでセクションの重複が90％以上ある場合、実質的に異なるバリエーションとはいえません（統合するか、名前を変更します）。
• セクション名に一般的な用語を使っていること（新しい名称を作らない）。

停止条件

• 2～3つの情報源が構造に合意している → 十分です。
• 新しいクエリで、すでに確認済みの内容が返される → 停止します。
• トークン数または時間の上限に達した → 可能な範囲で最善を尽くし、research.md にその旨を記録して終了します。

ルール

必須ルール（決して違反しないこと）：

• ハード拒否指示を含まないテンプレートは決して返しません。
• Phase D の実行中、または force-regenerate / force-new-variant モード以外では、既存のテンプレートファイルを上書きしません。
• スキル依存関係を宣言しません。このスキルは自己完結しており、リサーチのフォールバック順序は実行時の優先設定です。
• 例示を除き、SKILL.md の本文でトリガーコマンドを列挙しません。「When to activate」のリストは例示であり、網羅的なものではありません。エージェントは、基盤となる原則（あらゆる出力先向けに、エージェントが作成する構造化コンテンツ）を、新しいツール／API／システムにも適用します。

優先設定（ユーザーの選択により変更可能）：

• 利用可能な場合は、deep-research スキル（199-biotechnologies/claude-deep-research-skill）を優先します（フォールバック順序）。
• Phase D では、失敗時に中止するより、失敗した項目をスキップすることを優先します。
• 確認なしですぐにキャンセルすることを優先します。

出力

スキルは次のいずれかを返します。

1. Phase C ペイロード — 指示、テンプレート、リサーチを組み立てたもの。ASCII文字数制限内で返します。use-or-create / force-regenerate / force-new-variant / Phase-E-new-variant の各パスが成功した場合に返されます。
2. Phase E の配置に関する推奨事項 — セクションと対応先を示すプレーンテキスト。Phase E のリサーチで、既存のバリエーション内にコンテンツが収まると判断された場合に返されます。
3. 中止シグナル — 中止理由を示すプレーンテキスト。ユーザーがキャンセルした場合、または Phase A で2回のコンテキスト収集を終えた場合に返されます。

ディスク上の副作用：

• Phase D は docs/templates/<content-type>/ の下に template.md、research.md、README.md を書き込みます。
• それ以外のフェーズはディスクに書き込みません。
• このスキルは外部の出力先（docs/templates/ 外のファイル、GitHub、Jira、Slack など）には書き込みません。呼び出し元が Phase C ペイロードを受け取った後、出力先側の操作を実行します。

段階的な情報開示

スキル本文は完全に自己完結しています。

今後、次の項目が追加される場合があります。

• references/forge-research-prompts.md — 一般的なコンテンツタイプ向けの既成リサーチプロンプト。
• assets/directive-template.txt — ASCII文字数制限内の指示テンプレート。
• scripts/check-orphans.sh — Phase B の孤立項目分類用ヘルパー。

関連項目

• 関連スキル（content-template-gateway からは呼び出されませんが、隣接するスキル）：deep-research、writing-skills、brainstorming、external-content-sanitizer。

本文の上限

• description は1,024文字以下（agentskills.io の上限）
• 本文は約500行／5,000トークン以下 — Claude は毎回のターンで本文をコンテキストに保持します
• 上限は30,000文字（エージェントとして再レンダリングする場合の Copilot カスタムエージェントの上限）