backlog-templates

バックログテンプレート

バックログの引き継ぎを出力するすべてのプランナーで使用する、ADO と GitHub の作業項目テンプレート生成、コンテンツのサニタイズ、自律性ティアの語彙、免責事項ブロックの配置、作業項目 ID の規則に関する共通リファレンスです。

概要

Phase 最終のバックログ作業項目を出力するプランナーには、共通の 2 種類の形式のテンプレート骨格、共通のコンテンツサニタイズルール、および作業項目 ID の割り当て位置に関する共通規則が必要です。このスキルでは、それらの共通要素を一元化し、各プランナーの指示ファイルが内容を重複して記述することなく、1 つの情報源を参照できるようにします。

呼び出し元：

• RAI Planner（rai-planner スキルの references/backlog-handoff.md）
• Security Planner（Security Planner エージェント。セキュリティ固有の引き継ぎの詳細は、security-planning スキルの references/backlog-formats.md）
• SSSC Planner（SSSC Planner エージェント。sssc-planner.instructions.md に準拠）
• Accessibility Planner（accessibility/accessibility スキルの references/phases/backlog-handoff.md）
• Privacy Planner（Privacy Planner エージェント。privacy-identity.instructions.md に準拠）

プランナーごとに定める内容（このスキルには含まれません）：

• ドメイン固有の HTML および Markdown の本文コンテンツ（NIST の特性、STRIDE カテゴリー、WCAG 基準、Scorecard チェック）。
• 重大度から優先度へのマッピング表、および重大度からティアへのマッピング表。入力語彙はプランナーごとに異なります。
• 作業項目の階層マッピング（Epic / Feature / Story / Task / Bug）。
• アクセシビリティの免責事項テキスト（L7 の免責事項レバーによって accessibility-identity.instructions.md に固定されています）。

ADO 作業項目テンプレート

ADO の説明フィールドでは HTML を使用し、プランナー固有のフィールドブロックと、原文どおりの免責事項の引用ブロックを埋め込みます。プランナー ID のプレフィックスとプランナーごとのフィールドセットを指定して、この骨格をパラメーター化してください。

骨格：

<div>
  <h3>{Domain} Control: {control_name}</h3>
  
  <h4>Implementation</h4>
  <p>{implementation_details}</p>
  <h4>Acceptance Criteria</h4>
  <ul>
    <li>{criterion_1}</li>
    <li>{criterion_2}</li>
  </ul>
  <blockquote>
  <p><strong>Note</strong> — The author created this content with assistance from AI. All outputs should be reviewed and validated by a qualified {role} reviewer before use.</p>
  <ul><li><input type="checkbox" disabled /> Reviewed and validated by a qualified {role} reviewer</li></ul>
  </blockquote>
</div>

記入例（Security Planner）：

<div>
  <h3>Security Control: {mitigation_name}</h3>
  <p><strong>Threat:</strong> {threat_id} - {threat_description}</p>
  <p><strong>Bucket:</strong> {bucket_name}</p>
  <p><strong>Standards:</strong> {owasp_ref}, {nist_ref}</p>
  <h4>Implementation</h4>
  <p>{implementation_details}</p>
  <h4>Acceptance Criteria</h4>
  <ul>
    <li>{criterion_1}</li>
    <li>{criterion_2}</li>
  </ul>
</div>

各プランナーは、それぞれのフィールドブロックに置き換えます（RAI では NIST の特性 + 脅威 + 制御対象、Accessibility ではフレームワーク + 基準 + 対象 + ペルソナ + エビデンス + トレードオフ、SSSC ではサプライチェーン制御 + Scorecard チェック + 導入タイプ、Privacy ではデータカテゴリー + 処理目的 + DPIA 参照 + 法的根拠 + リスクティア）。

プランナー固有の ADO 説明フィールドブロック（`` スロットに代入するキー）：

• RAI — characteristic、subcategory、principle、maturity_level、tradeoff_ref（該当する場合）。
• Security — threat_id、stride_category、bucket、risk_level。
• SSSC — Scorecard Check、Risk Level、Effort、Adoption Type、Prerequisite、Adoption Steps、Source References（Workflow、Script、Documentation）。
• Accessibility — framework、criterion、surface、wcag_level、severity、category、risk_tier、tradeoff_ref（該当する場合）。severity が critical または major の場合は、支援技術による検証の注記を追加します。
• Privacy — data_category、processing_purpose、dpia_ref、lawful_basis、risk_tier。

GitHub Issue テンプレート

GitHub Issue では、YAML メタデータヘッダーに続けて Markdown 本文を記述します。{{<PREFIX>-TEMP-N}} 形式の一時 ID は、Issue の作成時に実際の Issue 番号に置き換えられます。

標準 YAML メタデータヘッダー：

---
id: "{{<PREFIX>-TEMP-N}}"
planner: {rai|security|sssc|accessibility|privacy}
priority: {Critical|High|Medium|Low}
standards: ["{standard_id_1}", "{standard_id_2}"]
evidence_refs: ["{evidence_id_1}"]
cross_planner_refs: ["{wi_id_1}"]
---

プランナー固有の追加フィールド（置き換えるのではなく、同じ YAML ブロックに追加します）：

• RAI — characteristic、subcategory、principle、maturity_level、tradeoff_ref、horizon、standards。
• Security — threat_id、stride_category、risk_level、bucket、standards。
• SSSC — scorecard_check、risk_level、adoption_type、effort、standards。
• Accessibility — framework、criterion、surface、wcag_level、severity、category、risk_tier、tradeoff_ref、standards。
• Privacy — data_category、processing_purpose、dpia_ref、lawful_basis、risk_tier、standards。

Markdown 本文の骨格：

## {Domain} Control: {control_name}

{planner_specific_summary_lines}

### Implementation

{implementation_details}

### Acceptance Criteria

* [ ] {criterion_1}
* [ ] {criterion_2}

形式間の整合性を保つため、ADO テンプレートの免責事項の引用ブロックを Markdown 本文の末尾で原文どおりに再利用します。

プラットフォームごとのフィールドマッピング

ADO

Field	Purpose	Required	Per-planner override
タイトル	括弧付きタグの接頭辞＋簡潔な説明	はい	タイトルの接頭辞は異なります（[Security]、[RAI]、[A11Y][{framework}]）。
説明	ADO テンプレートのひな形に沿った HTML 本文	はい	フィールドブロックの内容は異なります。
受け入れ条件	検証可能なチェック項目	はい	アクセシビリティでは、必要に応じて支援技術による検証を追加します。
タグ	ドメインタグ＋該当するプロパティタグ	はい	タグの語彙は異なります（CIA トライアド、RAI 原則、WCAG レベルなど）。
優先度	リスクまたは重大度から決定	はい	プランナーごとのマッピング表。
イテレーション	ユーザーが指定するイテレーションパス	任意	空の場合はバックログリファインメントが既定値になります。
AreaPath	ユーザーが指定するプロジェクト領域	はい	すべてのプランナーで ADO に出力するために必須です。
親	エピックまたは機能の親参照	任意	シードがプランナー固有の階層に対応する場合に設定します。

GitHub

Field	Purpose	Required	Per-planner override
タイトル	括弧付きタグの接頭辞＋簡潔な説明	はい	タイトルの接頭辞は異なります（ADO のタイトル規約に準拠）。
本文	GitHub テンプレートに沿った Markdown 本文	はい	YAML ヘッダーへの追加内容と本文の要約行は異なります。
ラベル	小文字のドメインラベル＋プロパティラベル	はい	ラベルの語彙は異なります。コロンが許可されない場合は prefix: 形式を削除します。
マイルストーン	計画マイルストーンがある場合はそれを指定	任意	各プランナーはドメインのマイルストーンを指定できます。ない場合は未設定のままにします。
担当者	担当者の役割に関する提案	任意	既定値は TBD — assign during backlog refinement. です。

コンテンツのサニタイズプロトコル

ADO または GitHub に出力する前に、各作業項目に次の 5 つのルールを適用します。サニタイズはレンダリング後、MCP を介した作成前に実行されます。

1. .copilot-tracking/ の出現箇所をすべて、{domain} plan artifacts のような説明的な表現に置き換えます（例：security plan artifacts、accessibility plan artifacts）。
2. 絶対ファイルシステムパスをワークスペース相対参照に置き換えます。
3. 埋め込みの状態 JSON または状態 JSON ファイルへのポインターを削除します。状態内の標準規格への参照は、抽出後も保持します。
4. 標準規格の識別子はそのまま保持します — OWASP A{NN}、NIST AI RMF サブカテゴリ ID、CIS コントロール番号、WCAG 達成基準 ID（1.1.1、1.3.5）、Scorecard チェック名、SLSA レベル文字列、Section 508 章 ID、EN 301 549 条項番号。
5. サニタイズされた成果物ごとに state.noticeLog エントリを追加します。noticeType: "sanitization"、source: "<planner-handoff-instruction-path>"、成果物のパス、および適用されたサニタイズルールを含めます。

.copilot-tracking/<planner-domain>/{slug}/debug/ に保持されるデバッグモードの出力には、完全なパスが含まれ、外部向けの作業項目に渡されることはありません。

自律性レベルの列挙

3 つのレベルによって、レンダリングされた作業項目を対象のバックログシステムに登録する方法を制御します。標準の語彙は manual ／ supervised ／ autonomous です。4 つ目の値 coached は、作業項目をまったく出力しない機能を示します。

• manual — プランナーは .copilot-tracking/ の下にバックログ引き継ぎファイルを出力します。ユーザーは各作業項目を対象システムに個別に作成します。MCP ツールの呼び出しはありません。
• supervised — プランナーは .copilot-tracking/ にレンダリング済みの作業項目の下書きを作成し、5～10 項目ごとにユーザーに提示してレビューを依頼します。ユーザーの承認後にのみ、MCP 作成ツールを呼び出します。これがデフォルトのレベルです。
• autonomous — ユーザーが実行を事前承認した後、プランナーはサニタイズ済みのバッチに対して MCP 作成ツールを直接呼び出します。すべての項目を 1 回の操作で作成します。
• coached — この機能は、バックログの作業項目ではなく、会話と独自の出力を生成します。何もレンダリングせず、作成ツールを呼び出さず、バックログシステムにも到達しないため、どのレベルも適用されません。バックログプランナーがこの値を選択することはなく、プランナーの状態スキーマでも受け付けられません。これは、コーチング形式の機能が、この語彙の中で文書化されていない状態ではなく、名前を持てるようにするために存在します。コーチング機能は、独自の状態に自律性フィールドを記録しません。

異なる語彙を使用するプランナー間の対応関係です。各プランナーは、独自の語彙を使用して、選択した値をセッション状態の userPreferences.autonomyTier に保存します。この表は、プランナー間の同等性を示す唯一の信頼できる情報源です。

標準（このスキル）	アクセシビリティ（シードスキーマ）	セキュリティ	RAI	SSSC	プライバシー
autonomous	autonomous	Full	Full	Full	Full
supervised（デフォルト）	supervised	Partial	Partial	Partial（デフォルト）	Partial（デフォルト）
manual	manual	Manual	Manual	Guided	Manual
coached	該当なし	該当なし	該当なし	該当なし	該当なし

注記：

• アクセシビリティの語彙はすでに標準の名称と一致しています。シードスキーマの autonomyTier フィールドが、保存される形式です。
• SSSC では、最も自律性の低いレベルのラベルとして Guided を使用します。対応関係の参照とレポートでは、プランナー間で Guided と Manual を同等として扱ってください。
• coached はレベルではなく、プランナーに対応する値もありません。選択できず、いずれのプランナー状態スキーマにも保存されず、重大度からレベルへの振り分けも行いません。プランナーがこの値に遭遇した場合は、範囲外として扱ってください。
• 重大度からレベルへのマッピング（どの重大度がどのレベルに振り分けられるか）は、各プランナーの引き継ぎ指示ファイルに記載されています。

免責事項ブロックの配置規約

バックログの引き継ぎ成果物（引き継ぎサマリー、ADO 出力ファイル、GitHub 出力ファイル）には、ファイルの末尾に免責事項ブロックをそのまま出力します。このブロックは、プランナーによる出力が AI の支援を受けて作成されたものであり、実行前に適格な人間によるレビューが必要であることを示す正式な根拠です。

免責事項テキストの情報源の区分：

• RAI、Security、SSSC — 対応するプランナーセクションの、自動適用された disclaimer-language.instructions.md から免責事項テキストを読み取ります。
• Privacy — Privacy Planning セクションの、自動適用された disclaimer-language.instructions.md から免責事項テキストを読み取ります。
• Accessibility — Disclaimer Handling 見出しの下にある、自動適用された accessibility-identity.instructions.md から免責事項テキストを読み取ります。L7 の免責事項レバーにより、アクセシビリティに関する免責事項はこのファイルに固定されています。disclaimer-language.instructions.md に移動しないでください。

配置ルール：

• 出力する各成果物の末尾にブロックを出力します。先頭には出力しません。
• セッション中に初めて出力した時点の ISO 8601 タイムスタンプを state.disclaimerShownAt に設定します。
• 出力するたびに、noticeType: "handoff-disclaimer"、source: "<authoritative-instruction-path>"、および成果物のパスを含むエントリを state.noticeLog に追加します。
• ADO 出力では、説明フィールド内の作業項目ごとの HTML ブロック引用は、独立したレビュー手段であり、ファイルレベルの免責事項ブロックの代わりにはなりません。

このスキルでは、免責事項テキスト自体を意図的に再掲しません。正規のテキストが更新された際にスキルを編集せずとも変更が反映されるよう、出力時に上記の正式な情報源から読み取ってください。

作業項目 ID の命名規約

作業項目の形式は WI-{PREFIX}-{NNN} です。プレフィックスは作成元のプランナーを示し、{NNN} はプランのスラッグごとにゼロ埋めされた単調増加の連番です。

プランナー	ADO プレフィックス	GitHub 一時 ID
RAI	WI-RAI-	{{RAI-TEMP-N}}
Security	WI-SEC-	{{SEC-TEMP-N}}
SSSC	WI-SSSC-	{{SSSC-TEMP-N}}
Accessibility	WI-A11Y-	{{A11Y-TEMP-N}}
Privacy	WI-PRIV-	{{PRIV-TEMP-N}}

ルール：

• プレフィックスを個別にすることで、複数のプランナーが同じプロジェクトのバックログを作成した場合に ID が重複するのを防ぎます。
• 連番はプランのスラッグごとに単調増加させます。プランやセッションをまたいで識別子を再利用しないでください。
• GitHub の一時 ID は、作成時に実際の Issue 番号に置き換えます。追跡可能性を保つため、一時 ID は state.noticeLog に残してください。
• プランナーをまたぐ参照では、対象プランナーの完全な ID の前に関係の種類を付けます。Accessibility-Ref: WI-A11Y-{NNN}、Security-Ref: WI-SEC-{NNN}、RAI-Ref: WI-RAI-{NNN}、SSSC-Ref: WI-SSSC-{NNN}、Privacy-Ref: WI-PRIV-{NNN} の形式を使用します。

内部参照 ID（脅威用の T-{BUCKET}-{NNN}、エビデンス用の EV-A11Y-{NNN}、シード用の SEED-A11Y-{NNN}、トレードオフ用の TO-A11Y-{NNN}）は、それぞれのプランナーの範囲内で管理され、このスキルの対象外です。