polyphony-sdlc

Orchestrate Azure DevOps work item SDLC routing without hardcoded type names.

Updated Apr 29, 2026
One-click install
npx skills add https://github.com/PolyphonyRequiem/polyphony --skill polyphony-sdlc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: polyphony-sdlc
Source: https://github.com/PolyphonyRequiem/polyphony/tree/main/.github/skills/polyphony-sdlc
Command: npx skills add https://github.com/PolyphonyRequiem/polyphony --skill polyphony-sdlc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It solves the problem of brittle, type-specific workflow routing by providing a type-agnostic SDLC vocabulary and library of composable Conductor sub-workflows that can drive any Azure DevOps work item through plan, implement, PR, merge, and close-out.

Core Features & Use Cases

  • Type-agnostic lifecycle routing: Routes purely from derived per-requirement state and EdgeGraph readiness rather than hardcoded work item type names.
  • Recursive planning and parallel execution: Implements recursive planning across hierarchy levels and executes implementation in parallel through PG (processing group) batches.
  • Platform-aware PR lifecycle orchestration: Chooses GitHub vs ADO PR leg workflows using an explicit interface contract and runtime metadata (e.g., tracker=ado).

Use Case: You have a heterogeneous work item tree (Epics, Issues, Bugs, and custom process types) and need one canonical orchestration workflow that consistently drives each item through SDLC without rewriting Conductor YAML when the process template changes.

Quick Start

Run the canonical SDLC entry point with your root ADO work item id by invoking conductor run polyphony@polyphony --input root_id=<ID> --web.

Frequently Asked Questions about polyphony-sdlc

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

FAQPage Schema
How do I orchestrate Azure DevOps work item hierarchies through an end-to-end SDLC pipeline?

You orchestrate Azure DevOps work items through an SDLC pipeline by running a canonical Conductor workflow with a root work item ID. This drives recursive planning, parallel implementation processing groups, and platform-aware PR merge cycles end-to-end.

What is type-agnostic workflow routing for Azure DevOps work items?

Type-agnostic workflow routing is a mechanism that drives Azure DevOps work items through the SDLC based on derived per-requirement state and EdgeGraph readiness rather than hardcoded work item type names. This allows heterogeneous work item trees to be processed uniformly.

How do I handle recursive planning and parallel execution for Azure DevOps work item trees?

You handle recursive planning and parallel execution by using composable Conductor sub-workflows that fan out implementation tasks into processing group (PG) batches. This allows the SDLC orchestration to execute implementation steps in parallel across hierarchy levels.

Can I use Conductor workflows to manage both GitHub and ADO pull request lifecycles?

Yes, you can use Conductor workflows to manage both GitHub and ADO pull request lifecycles. The orchestration chooses the appropriate PR leg workflow using an explicit interface contract and runtime metadata, such as setting the tracker to ado for Azure DevOps.

Does SDLC orchestration work with heterogeneous Azure DevOps work item trees containing custom process types?

Yes, SDLC orchestration works with heterogeneous Azure DevOps work item trees containing Epics, Issues, Bugs, and custom process types. The type-agnostic vocabulary routes items purely from derived state, eliminating the need to rewrite Conductor YAML when process templates change.

Why do my Azure DevOps workflow routes break when I change custom process templates?

Azure DevOps workflow routes break because they are often hardcoded to specific work item type names. Using a type-agnostic SDLC vocabulary resolves this by routing based on derived per-requirement state and EdgeGraph readiness instead of relying on the process template type names.