polyphony-branch-model

Standardize Git branch topology and promotion gates for polyphony SDLC runs.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Polyphony SDLC runs require a consistent, deterministic Git branch topology so planning, merge-group promotion, PR ordering, and evidence capture can be enforced without brittle, type-specific logic.

Core Features & Use Cases

  • Defines the canonical branch tree for a run, including feature/, plan/, mg/ (top and nested), impl/, and evidence/ branch naming and placement.
  • Specifies promotion and merge-chain rules (head/base relationships, mandatory merge commits at key layers, and driver-enforced gates based on requirement state).
  • Guarantees stable merge-group identity via planner-declared MG ids and immutable topology inputs recorded in a run manifest (.polyphony/run.yaml).
  • Handles renegotiation and concurrency safely through parent-plan generations, stale PR blocking with auditable rebase or human gates, and ancestor restack protections.
  • Manages cross-sibling code dependencies by applying policy-driven remedies like promote-and-rebase and recording rebase events to prevent silent topology drift.

Quick Start

Use the polyphony-branch-model skill when authoring or reviewing branch-creation logic for a polyphony SDLC run to ensure your branch names, merge gates, and PR topology follow the Rev 4 rules.

Frequently Asked Questions about polyphony-branch-model

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

FAQPage Schema
How do I standardize Git branch naming conventions for CI/CD workflow orchestration?

Standardize Git branch naming by enforcing deterministic topology rules for feature, plan, merge-group, and evidence branches. This ensures workflow orchestration and pull request routing can be automated without brittle, type-specific logic.

What is merge-group promotion and how does it manage pull request ordering?

Merge-group promotion is a gated process that standardizes PR lifecycle ordering using stable MG identity grammar and driver-enforced merge policies. It mandates specific head/base relationships and merge commits to safely advance code through topology layers.

How do you handle concurrent pull requests and renegotiation safely in a Git workflow?

Handle concurrent pull requests safely using parent-plan generations to block stale PRs and enforce auditable rebases. Ancestor restack protections and recorded rebase events prevent silent topology drift during concurrent renegotiation.

How do I resolve cross-sibling code dependencies during branch topology promotion?

Resolve cross-sibling code dependencies by applying policy-driven remedies like promote-and-rebase. These dependency fixes are recorded in a run manifest to ensure branch topology remains stable and auditable across sibling merges.

What is a topology hash and when do I need it for branch lifecycle management?

A topology hash is an immutable input recorded in a run manifest that guarantees stable merge-group identity. You need it when authoring workflow YAML to derive deterministic routing decisions across feature planning and evidence capture.

Can I use deterministic branch naming rules without a run manifest file?

Deterministic branch naming requires a run manifest to record immutable topology inputs and planner-declared MG ids. Without this manifest, workflow orchestration cannot reliably enforce merge gates or prevent silent topology drift across branch generations.