DeliveryOS

Structured sprint execution, QA governance, and production release control — embedded in your GitHub or GitLab repos (same npm package).

Install (same CLI, two providers)

DeliveryOS ships as the deliveryos npm package. The default install adds GitHub Actions workflows and optional issue forms. For GitLab, pass --provider gitlab to install the CI bundle and .gitlab issue templates instead.

GitHub (default)

npx deliveryos install --with-templates .

GitLab

npx deliveryos install --provider gitlab --with-templates .

Add --with-labels to create labels via gh (GitHub) or glab (GitLab). Use --dry-run to preview. Full GitLab webhooks, tokens, and CI variables: docs/GITLAB.md on the repo.

Why this exists

Engineering teams often rely on informal coordination in Git hosts — manual approvals, inconsistent sprint tracking, reactive QA, and socially enforced releases. As teams scale, that creates:

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

DeliveryOS embeds structured intake, sprint orchestration, QA governance, and release gates directly into your repos — without replacing CI/CD or disrupting workflows.

What you get

Sprint child creation Create a sprint issue → each feature line becomes a child issue. Burn-down and auto-close at 100%.

Dual approval gates Production releases require both release approver and QA sign-off before deploy.

Auto-assign QA Issues with qa or qa-request labels get assigned to your QA team.

Telegram alerts Optional notifications for bugs, QA requests, sprints, and releases.

What gets installed

GitHub: the workflows below (Actions). GitLab: a root .gitlab-ci.yml bundle (Pages + releases baseline) plus markdown issue templates under .gitlab/issue_templates/ — not the same filenames, but the same governance ideas. Issue automation on GitLab uses webhooks to run the same CLI; see GITLAB.md.

Workflow	Purpose
sprint-child-creator	Creates child issues when a sprint (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

Quick start (after install)

GitHub

Create labels: Actions → DeliveryOS — Labels → Run workflow
Configure variables: Settings → Secrets and variables → Actions → Variables
RELEASE_APPROVER, QA_APPROVER, QA_ASSIGNEES
Optional: Add TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID for alerts

GitLab

Set the same variables in Settings → CI/CD → Variables (RELEASE_APPROVER, QA_APPROVER, etc.).
Create labels: install … --with-labels with glab authenticated, or run node dist/main.js labels-ensure in CI with GITLAB_TOKEN + project id — Required Labels.
Wire project webhooks (Issues, Comments, Merge requests) to a job that runs node …/dist/main.js issue-event / approval-event / notify with the payload — same CLI as GitHub; see examples/gitlab-ci.

Documentation

View on GitHub → Product & FAQ (PRFAQ) → GitLab setup (GITLAB.md) →