GitHub Delivery Operating System

A GitHub-native Delivery Governance Framework for structured sprint execution, QA review, and collaborative production release control.

Why This Exists

Engineering teams often rely on informal coordination inside GitHub — manual approvals, inconsistent sprint tracking, reactive QA engagement, and socially enforced production releases.

As teams scale, this creates:

• Delivery ambiguity
• QA bottlenecks
• Unclear accountability
• Release risk
• Cross-team misalignment

The GitHub Delivery Operating System (Delivery OS) embeds structured intake, sprint orchestration, QA governance, and collaborative release gates directly into engineering repositories — without replacing CI/CD pipelines or disrupting developer workflows.

Installation

One command (recommended):

npx github-delivery-os install --with-templates .

From your repo root. Add --with-labels to create labels via gh CLI (requires gh auth). Use --dry-run to preview first.

Alternative — clone and run script:

git clone https://github.com/Phaneroo/github-delivery-operating-system
cd github-delivery-operating-system

# New install or repo with existing workflows — adds only missing files (safe)
./scripts/install.sh --with-templates /path/to/your-repo

# Also create labels via gh CLI (requires gh auth)
./scripts/install.sh --with-templates --with-labels /path/to/your-repo

# Update Delivery OS (replace existing) — use --dry-run first to preview
./scripts/install.sh --with-templates --overwrite /path/to/your-repo

Note: By default, existing files are never overwritten. Use --overwrite only when updating Delivery OS. See Consumer Setup for the full command guide.

Other commands:

npx github-delivery-os status .                    # Show what's installed
npx github-delivery-os uninstall .                 # Remove workflows
npx github-delivery-os uninstall --with-templates .  # Remove workflows + templates
npx github-delivery-os uninstall --dry-run .      # Preview (no changes)

What gets installed:

| Workflow | Purpose | |----------|---------| | sprint-child-creator | Creates child issues when a sprint (title SPRINT -) is opened | | auto-close-sprint | Burn-down, sprint health, auto-close at 100% | | notify-release-approver | Pings approver when production release issue opens | | authorize-deployment | Dual approval (release approver + QA) | | auto-assign-qa | Assigns QA team to qa / qa-request issues | | telegram-issues | Telegram alerts for bugs, QA, sprints, releases | | setup-labels | One-time workflow to create required labels |

Workflows and templates are copied directly into your repo. No workflow_call or external references.

Quick Start (After Install)

1. Create labels: Actions → Setup Labels → Run workflow
2. Configure variables: Settings → Secrets and variables → Actions → Variables
   • RELEASE_APPROVER — GitHub username
   • QA_APPROVER — GitHub username
   • QA_ASSIGNEES — Comma-separated usernames (e.g. user1,user2)
3. Optional: Add TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID for alerts

Sprint Child Creation

When you open an issue using the Sprint Planning template with a title like SPRINT - Sprint 12:

1. Each line under "Sprint Features (One Per Line)" becomes a child issue
2. Child issues link back with Parent Sprint: #N
3. Closing child issues updates burn-down; sprint auto-closes at 100%

Required: Install with --with-templates so the sprint form is available.

Documentation

| Document | Description | |----------|-------------| | Landing page & quick start | Overview, one-command install, features | | Consumer Setup | Installation, configuration, variables, labels, Telegram, uninstall | | How To | Create sprints, request releases, approve, report bugs, QA requests | | Architecture | Workflows, templates, data flow | | Governance | Lifecycle, approval gates, automation rules |

License

MIT License. See LICENSE for details.