backlog-templates

Generates standardized ADO and GitHub work-item templates for planner backlog handoffs.

1.4k|284|Updated Nov 2, 2025
One-click install
npx skills add https://github.com/microsoft/hve-core --skill backlog-templates
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: backlog-templates
Source: https://github.com/microsoft/hve-core/tree/main/.github/skills/shared/backlog-templates
Command: npx skills add https://github.com/microsoft/hve-core --skill backlog-templates

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Teams running multiple planning agents (RAI, Security, SSSC, Accessibility, Privacy) need consistent work-item formats when handing off backlog items to Azure DevOps or GitHub, but each planner previously restated the same template skeletons, sanitization rules, and ID conventions.

Core Features & Use Cases

  • Dual-format templates: Provides HTML skeletons for ADO work items and YAML-plus-markdown skeletons for GitHub issues, with per-planner field blocks.
  • Content sanitization protocol: Applies five rules to strip internal paths, state JSON, and tracking references before work items reach external systems.
  • Autonomy-tier vocabulary: Defines the canonical manual/supervised/autonomous tiers and maps divergent per-planner vocabularies for cross-planner reporting.
  • Use Case: A security planner finishes a threat-modeling phase and emits sanitized GitHub issues using the shared template, disclaimer block, and WI-SEC- ID convention without duplicating format logic.

Quick Start

Ask the planner to generate the backlog handoff work items for ADO or GitHub using the shared backlog templates.

Frequently Asked Questions about backlog-templates

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate consistent work items for Azure DevOps and GitHub?

Use the shared template skeletons: an HTML body with a planner-specific field block for ADO, and a YAML metadata header plus markdown body for GitHub issues. Each planner substitutes its own domain fields into the common structure.

What is the work item ID naming convention for planner backlogs?

Work items use the format WI-{PREFIX}-{NNN}, where the prefix identifies the planner (WI-RAI, WI-SEC, WI-SSSC, WI-A11Y, WI-PRIV) and NNN is a zero-padded monotonic sequence scoped to the plan slug. GitHub temporary IDs are replaced with real issue numbers at creation.

How does content sanitization work before emitting work items?

Five rules run after rendering and before creation: replace .copilot-tracking/ paths, convert absolute paths to workspace-relative ones, remove state JSON references, preserve standards identifiers verbatim, and log a sanitization notice per artifact.

What autonomy tiers control backlog work item creation?

Three canonical tiers apply: manual (user creates items independently), supervised (default, user approves batches before MCP creation), and autonomous (direct creation after pre-approval). A fourth value, coached, emits no work items and is not a selectable tier.

Does this skill contain planner-specific content like severity mappings?

No. Domain-specific field content, severity-to-priority mappings, work-item hierarchy, and the accessibility disclaimer text stay in each planner's own instruction files. This skill only holds the shared skeletons, sanitization rules, and conventions.