backlog-templates

작성자: microsoft

RAI, Security, SSSC, Accessibility 및 Privacy 플래너 간 ADO 및 GitHub 백로그 핸드오프를 위한 공유 작업 항목 템플릿 및 규칙

npx skills add https://github.com/microsoft/hve-core --skill backlog-templates

Backlog Templates

Shared reference for ADO and GitHub work-item template generation, content sanitization, autonomy-tier vocabulary, disclaimer-block placement, and work-item ID conventions used by every planner that emits a backlog handoff.

Overview

Planners that emit Phase-final backlog work items all need the same dual-format template skeletons, the same content sanitization rules, and the same convention for where to assign work-item IDs. This skill consolidates those shared pieces so each planner instruction file can reference one source instead of restating them.

Callers:

  • RAI Planner (rai-planner skill references/backlog-handoff.md)
  • Security Planner (Security Planner agent; security-specific handoff details in the security-planning skill's references/backlog-formats.md)
  • SSSC Planner (SSSC Planner agent, governed by sssc-planner.instructions.md)
  • Accessibility Planner (accessibility/accessibility skill references/phases/backlog-handoff.md)
  • Privacy Planner (Privacy Planner agent, governed by privacy-identity.instructions.md)

What stays per-planner (NOT in this skill):

  • Domain-specific HTML and markdown body content (NIST characteristic vs. STRIDE category vs. WCAG criterion vs. Scorecard check).
  • Severity-to-priority and severity-to-tier mapping tables — different input vocabularies per planner.
  • Work-item hierarchy mapping (Epic / Feature / Story / Task / Bug).
  • The accessibility disclaimer text (pinned to accessibility-identity.instructions.md by the L7 disclaimer lever).

ADO Work Item Template

ADO description fields use HTML and embed a planner-specific field block plus a verbatim disclaimer blockquote. Parameterize the skeleton with the planner ID prefix and per-planner field set.

Skeleton:

<div>
  <h3>{Domain} Control: {control_name}</h3>
  <!-- planner-specific field block goes here -->
  <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>

Worked example (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>

Each planner substitutes its own field block (NIST characteristic + threat + control surface for RAI; framework + criterion + surface + personas + evidence + tradeoff for Accessibility; supply-chain control + Scorecard check + adoption type for SSSC; data category + processing purpose + DPIA reference + lawful basis + risk tier for Privacy).

Planner-specific ADO description field block (the keys substituted into the <!-- planner-specific field block goes here --> slot):

  • RAI — characteristic, subcategory, principle, maturity_level, tradeoff_ref (when applicable).
  • 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 (when applicable). Add an assistive-technology validation note when severity is critical or major.
  • Privacy — data_category, processing_purpose, dpia_ref, lawful_basis, risk_tier.

GitHub Issue Template

GitHub issues use a YAML metadata header followed by a markdown body. Temporary IDs of the form {{<PREFIX>-TEMP-N}} are replaced with real issue numbers on creation.

Canonical YAML metadata header:

---
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}"]
---

Planner-specific augmentation fields (added to the same YAML block, not replacing it):

  • 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 body skeleton:

## {Domain} Control: {control_name}

{planner_specific_summary_lines}

### Implementation

{implementation_details}

### Acceptance Criteria

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

The disclaimer blockquote from the ADO template is reused verbatim at the end of the markdown body for parity across formats.

Per-Platform Field Mappings

ADO

FieldPurposeRequiredPer-planner override
TitleBracket-tag prefix + concise descriptionYesTitle prefix differs ([Security], [RAI], [A11Y][{framework}]).
DescriptionHTML body per the ADO template skeletonYesField block contents differ.
AcceptanceCriteriaVerifiable checksYesAccessibility adds assistive-technology validation when required.
TagsDomain tags + applicable property tagsYesTag vocabulary differs (CIA triad, RAI principles, WCAG level, etc.).
PriorityDerived from risk or severityYesMapping table per planner.
IterationIteration path supplied by userOptionalEmpty defaults to backlog refinement.
AreaPathProject area supplied by userYesRequired for ADO emission across all planners.
ParentEpic or Feature parent referenceOptionalSet when seed maps into the planner-specific hierarchy.

GitHub

FieldPurposeRequiredPer-planner override
titleBracket-tag prefix + concise descriptionYesTitle prefix differs (matches ADO Title convention).
bodyMarkdown body per the GitHub templateYesYAML header augmentation and body summary lines differ.
labelsLowercased domain + property labelsYesLabel vocabulary differs; strip prefix: form when colons are disallowed.
milestonePlanning milestone if one existsOptionalEach planner may target a domain milestone; otherwise leave unset.
assigneesOwner role suggestionOptionalDefault to TBD — assign during backlog refinement.

Content Sanitization Protocol

Apply these five rules to every work item before emission to ADO or GitHub. Sanitization runs after rendering and before MCP-driven creation.

  1. Replace any occurrence of .copilot-tracking/ with a descriptive phrase such as {domain} plan artifacts (for example, security plan artifacts, accessibility plan artifacts).
  2. Replace absolute file system paths with workspace-relative references.
  3. Remove embedded state JSON or pointers to state JSON files; standards references inside state remain after extraction.
  4. Preserve standards identifiers verbatim — OWASP A{NN}, NIST AI RMF subcategory IDs, CIS control numbers, WCAG criterion IDs (1.1.1, 1.3.5), Scorecard check names, SLSA level strings, Section 508 chapter IDs, EN 301 549 clause numbers.
  5. Append a state.noticeLog entry per sanitized artifact with noticeType: "sanitization", source: "<planner-handoff-instruction-path>", the artifact path, and the sanitization rules that fired.

Debug-mode output retained under .copilot-tracking/<planner-domain>/{slug}/debug/ keeps full paths and never reaches external-facing work items.

Autonomy-Tier Enumeration

Three tiers control how rendered work items reach the target backlog system. The canonical vocabulary is manual / supervised / autonomous. A fourth value, coached, names a capability that emits no work items at all.

  • manual — The planner emits a backlog handoff file under .copilot-tracking/. The user creates each work item in the target system independently. No MCP tool invocations.
  • supervised — The planner drafts rendered work items in .copilot-tracking/, presents each batch of 5 to 10 items for user review, and only invokes MCP creation tools on user approval. This is the default tier.
  • autonomous — The planner invokes MCP creation tools directly on the sanitized batch after the user pre-approves the run. All items are created in a single operation.
  • coached — The capability produces a conversation and its own output rather than backlog work items. It renders nothing, invokes no creation tool, and reaches no backlog system, so no tier applies to it. No backlog planner selects this value and no planner state schema accepts it; it exists so a coaching-shaped capability has a name in this vocabulary instead of an undocumented absence. Coaching capabilities record no autonomy field in their own state.

Cross-reference mapping for planners that use divergent vocabularies. Each planner persists the selected value in its session state under userPreferences.autonomyTier using its own vocabulary; this table is the single source of truth for cross-planner equivalence.

Canonical (this skill)Accessibility (seed schema)SecurityRAISSSCPrivacy
autonomousautonomousFullFullFullFull
supervised (default)supervisedPartialPartialPartial (default)Partial (default)
manualmanualManualManualGuidedManual
coachednot applicablenot applicablenot applicablenot applicablenot applicable

Notes:

  • Accessibility's vocabulary already matches the canonical names; the seed schema autonomyTier field is the persisted form.
  • SSSC uses Guided as the lowest-autonomy tier label. Treat Guided and Manual as equivalent across planners for cross-reference and reporting.
  • coached is not a tier and has no planner equivalent. It is not selectable, not persisted in any planner state schema, and carries no severity-to-tier routing. A planner that encounters it should treat it as out of range.
  • Severity-to-tier mapping (which severity routes to which tier) stays in each planner's handoff instruction file.

Disclaimer-Block Placement Convention

Every backlog handoff artifact (handoff summary, ADO output file, GitHub output file) emits a disclaimer block verbatim at the end of the file. The block is the source of authority that the planner emission was AI-assisted and requires qualified human review before execution.

Source-of-truth split for the disclaimer text:

  • RAI, Security, SSSC — Read the disclaimer text from the automatically applied disclaimer-language.instructions.md under the corresponding planner section.
  • Privacy — Read the disclaimer text from the automatically applied disclaimer-language.instructions.md under the Privacy Planning section.
  • Accessibility — Read the disclaimer text from the automatically applied accessibility-identity.instructions.md under the Disclaimer Handling heading. The L7 disclaimer lever pins the accessibility disclaimer to that file. Do not move it to disclaimer-language.instructions.md.

Placement rules:

  • Emit the block at the end of every emitted artifact, not at the start.
  • Set state.disclaimerShownAt to the ISO 8601 timestamp at first emission within a session.
  • Append a state.noticeLog entry per emission with noticeType: "handoff-disclaimer", source: "<authoritative-instruction-path>", and the artifact path.
  • For ADO emission, the per-work-item HTML blockquote inside the description field is a separate review affordance and does not replace the file-level disclaimer block.

This skill intentionally does not reproduce the disclaimer text. Read it from the authoritative source above at emission time so updates to the canonical text propagate without skill edits.

Work Item ID Naming Convention

Work items use the format WI-{PREFIX}-{NNN} where the prefix identifies the originating planner and {NNN} is a zero-padded monotonic sequence scoped to the plan slug.

PlannerADO prefixGitHub temp ID
RAIWI-RAI-{{RAI-TEMP-N}}
SecurityWI-SEC-{{SEC-TEMP-N}}
SSSCWI-SSSC-{{SSSC-TEMP-N}}
AccessibilityWI-A11Y-{{A11Y-TEMP-N}}
PrivacyWI-PRIV-{{PRIV-TEMP-N}}

Rules:

  • Distinct prefixes prevent ID collision when multiple planners produce a backlog against the same project.
  • Sequence is monotonic per plan slug. Do not reuse identifiers across plans or sessions.
  • GitHub temporary IDs are replaced with real issue numbers at creation time; preserve the temporary ID in state.noticeLog for traceability.
  • Cross-planner references use the target planner's full ID, prefixed with the relationship type: 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}.

Internal reference IDs (T-{BUCKET}-{NNN} for threats, EV-A11Y-{NNN} for evidence, SEED-A11Y-{NNN} for seeds, TO-A11Y-{NNN} for tradeoffs) remain scoped to their owning planner and are out of scope for this skill.

microsoft의 다른 스킬

oss-growth
microsoft
OSS 성장 해커 페르소나
agent-framework-azure-ai-py
microsoft
Microsoft Agent Framework Python SDK(agent-framework-azure-ai)를 사용하여 Azure AI Foundry 에이전트를 구축합니다. AzureAIAgentsProvider로 지속적 에이전트를 만들 때, 호스팅 도구(코드 인터프리터, 파일 검색, 웹 검색)를 사용할 때, MCP 서버를 통합할 때, 대화 스레드를 관리할 때, 또는 스트리밍 응답을 구현할 때 사용합니다. 함수 도구, 구조화된 출력, 다중 도구 에이전트를 다룹니다.
development
airunway-aks-setup
microsoft
AKS에서 AI Runway 설정 — 빈 클러스터에서 실행 중인 모델까지. 클러스터 검증, 컨트롤러 설치, GPU 평가, 공급자 설정, 첫 배포를 다룹니다. 시기: "AI Runway 설정", "AKS 클러스터 온보딩", "AI Runway 설치", "airunway 설정", "AKS에 모델 배포", "AKS에서 GPU 추론", "AKS에서 KAITO 설정", "AKS에서 LLM 실행", "AKS에서 vLLM", "AKS에서 모델 서빙 설정", "AI Runway 컨트롤러".
devops
appinsights-instrumentation
microsoft
Azure Application Insights로 웹앱을 계측하기 위한 지침입니다. 원격 분석 패턴, SDK 설정, 구성 참조를 제공합니다. WHEN: 앱 계측 방법, App Insights SDK, 원격 분석 패턴, App Insights란 무엇인가, Application Insights 지침, 계측 예시, APM 모범 사례.
devops
applicationinsights-web-ts
microsoft
브라우저/웹 앱을 Application Insights JavaScript SDK(@microsoft/applicationinsights-web)로 계측합니다. Real User Monitoring(RUM) — 페이지 뷰, 클릭, AJAX/fetch 종속성, 예외, 사용자 지정 이벤트, 백엔드 OpenTelemetry 트레이스와 상관관계가 있는 브라우저 측 GenAI 에이전트 트레이스에 사용합니다. SDK Loader Script 및 npm 설정, 프레임워크 확장(React, React Native, Angular), Click Analytics, 텔레메트리 이니셜라이저, 브라우저에서 생성된 에이전트/도구/모델 스팬에 대한 OTel GenAI 의미론적 규칙을 다룹니다.
devops
azure-ai-anomalydetector-java
microsoft
Azure AI Anomaly Detector SDK for Java로 이상 탐지 애플리케이션을 구축하세요. 단변량/다변량 이상 탐지, 시계열 분석 또는 AI 기반 모니터링을 구현할 때 사용하세요.
development
azure-ai-language-conversations-py
microsoft
azure-ai-language-conversations Python SDK를 사용하여 대화형 언어 이해(CLU)를 구현합니다. ConversationAnalysisClient로 대화 의도와 엔터티를 분석하거나, NLP 기능을 구축하거나, 애플리케이션에 언어 이해를 통합할 때 사용합니다.
development
azure-ai-ml-py
microsoft
Azure Machine Learning SDK v2 for Python. ML 작업 영역, 작업, 모델, 데이터 세트, 컴퓨팅 및 파이프라인에 사용합니다. 트리거: "azure-ai-ml", "MLClient", "workspace", "model registry", "training jobs", "datasets".
development