GitHub Delivery OS

Paste this into your agent. It asks a few questions, recommends lite or full, shows a preview and installs after you say yes.

On Claude Code you can also add a permanent setup assistant that works in any repo: npx github-delivery-os setup-skill

        
You:    I want Telegram alerts for this repo.

Agent: A dry run of `add telegram` shows it
        would add one workflow:
        .github/workflows/telegram-issues.yml.
        Nothing else changes.

        After it's added you create two repo
        secrets yourself (Settings → Secrets and
        variables → Actions):
          TELEGRAM_BOT_TOKEN  from @BotFather
          TELEGRAM_CHAT_ID    where alerts go

        Shall I run `add telegram .` for real?

You:    Yes, add it.

Agent: Added. `list` shows the telegram pack as
        installed. Two things for you: add the
        two secrets, and commit and push the new
        workflow, since it only runs once it's
        on the default branch.

You:    Now I also want QA sign-off before
        releases.

Agent: A dry run of `add qa` shows what comes
        in: QA assignment, the rolling QA issue,
        QA approval, the QA Request form, and
        QA-aware release workflows that replace
        lite's. What changes for you: a release
        then needs the QA approver's approval as
        well as yours. You'd set QA_APPROVER and
        QA_ASSIGNEES. Who should they be? I
        won't set them unless you tell me to,
        because they name a real person.

          You:    Create a sprint called Sprint 14 for the checkout revamp, running
        Oct 1 to Oct 14, with features: guest checkout, saved cards,
        order confirmation email.

Agent: Checked acme/storefront: Delivery OS is installed and the sprint
        and planning labels exist. I'm about to create:

          Title:    SPRINT - Sprint 14
          Labels:   sprint, planning
          Goal:     Checkout revamp
          Dates:    2026-10-01 to 2026-10-14
          Features: guest checkout
                    saved cards
                    order confirmation email

        Create it?

You:    yes

Agent: Created acme/storefront#57. sprint-child-creator has opened
        #58 guest checkout, #59 saved cards and #60 order confirmation
        email. Closing each one moves the sprint's burn-down.

You:    Approve release #61

Agent: You're logged in as jkaweesi22, which matches RELEASE_APPROVER.
        Posting "approved" on #61. authorize-deployment will mark it
        ready to deploy.

Illustrative walkthrough against acme/storefront, a repo with Delivery OS installed (same example repo as the full walkthrough below).

Filing the bug:

1. In your agent, inside (or pointed at, via --repo) the target repo, describe the bug in plain language:
   "File a bug on acme/storefront — the order request form submits with an empty phone number, severity high. Steps: fill in the form, leave phone blank, submit. Expected: should block submission. Actual: submits anyway, so there's no way to contact the customer. Tested on Chrome, desktop, production."
2. The agent pre-flights the repo — confirms Delivery OS is installed and the bug/qa labels exist.
3. The agent shows the exact issue it's about to create before doing anything: Title [BUG] Order request form submits with empty phone number; Labels bug, qa; body fields (Platform, Severity: High, Build/Version, Steps to Reproduce, Expected/Actual Result, Test Environment) filled in from what you said.
4. Confirm ("yes") when asked to create it.
5. The agent runs gh issue create and reports back the issue — e.g. acme/storefront#42. Nothing else happens automatically; bug reports don't trigger a workflow, they're just labeled and tracked.

Filing the follow-up task:

1. Ask the agent to turn the bug into tracked work, referencing the bug's issue number:
   "Create a task to add phone number validation to the order form, owner @alex, priority P1, status Backlog, acceptance: form blocks submission until a valid phone number is entered. Link it to #42."
2. The agent shows the constructed issue: Title TASK - Add phone number validation to order form; Labels task; body: Task Summary, Description (references #42), Owner → @alex, Priority → P1 - High, Status → Backlog, Acceptance Criteria, Artifacts/Links → Related bug: #42.
3. Confirm ("yes") to create it.
4. The agent runs gh issue create. Same as the bug — no workflow trigger, just labeled and tracked, now linked back to the bug it addresses.

A realistic session, run from inside the repo. RELEASE_APPROVER, QA_APPROVER, and QA_ASSIGNEES are already configured.

You: Create a sprint called "Sprint 14 - Checkout Revamp", running 2026-09-16 to
     2026-09-30, goal is shipping the new checkout flow, features:
     - Redesign cart summary
     - Add saved payment methods
     - Fix tax rounding bug

Agent: This will create an issue in acme/storefront:

          Title:  SPRINT - Sprint 14 - Checkout Revamp
          Labels: sprint, planning
          Body:
            ### Sprint Name
            Sprint 14 - Checkout Revamp
            ### Sprint Start
            2026-09-16
            ### Sprint End
            2026-09-30
            ### Sprint Goal
            Ship the new checkout flow
            ### Sprint Features (One Per Line)
            Redesign cart summary
            Add saved payment methods
            Fix tax rounding bug
            ### Sprint Approved
            Pending

        Create this issue?

You: yes

Agent: Created #52. sprint-child-creator will fire on open and create one child
        issue per feature — #53 "Redesign cart summary", #54 "Add saved payment
        methods", #55 "Fix tax rounding bug" — each labeled sprint-active and
        linked back with "Parent Sprint: #52".

  [ ... engineers do the work, close #53 and #54 as they land ... ]

You: How's Sprint 14 doing?

Agent: Reading #52... ## 🚦 Sprint Status: 67% complete (2/3 closed), 20% of
        sprint time elapsed, 🟢 on track.

You: QA found a rounding issue in the tax calc — file a bug. Severity high,
     repros on checkout with 3+ items, expected total matches line items,
     actual is off by $0.01.

Agent: This will create an issue in acme/storefront:

          Title:  [BUG] Tax rounding off by $0.01 with 3+ items
          Labels: bug, qa
          Body: (Platform, Severity: High, Steps to Reproduce, Expected vs.
                 Actual Result, Test Environment filled in from what you said)

        Create this issue?

You: yes

Agent: Created #56.

  [ ... #55 fixed, referencing #56 ... ]

You: Open a QA request for the tax rounding fix, related to #55, test on
     staging, acceptance: totals match to the cent for carts of 1-10 items.

Agent: This will create an issue in acme/storefront:

          Title:  QA REQUEST - Tax rounding fix
          Labels: qa-request
          Body: (Related Sprint Task Issue #55, What to Test, Environment +
                 Build Link: staging, Acceptance Criteria filled in)

        Create this issue?

You: yes

Agent: Created #57. auto-assign-qa will assign it to the configured
        QA_ASSIGNEES.

  [ ... QA tests it, comes back clean ... ]

You: Mark QA #57 as approved, looks good.

Agent: Checking gh auth status... authenticated as jane-qa, which matches this
        repo's QA_APPROVER. Posting:

          "looks good — verified on staging, totals match to the cent"

        on #57.

You: yes, post it

Agent: Posted. Now close #55 to update the sprint burn-down?

You: yes

Agent: Closed #55. Sprint 14 is now 100% complete — auto-close-sprint closed
        #52 and posted a completion comment.

You: Open a production release for storefront v2.4.1, sprint #52, summary
     "checkout revamp: new cart summary, saved payment methods, tax rounding
     fix", QA evidence: #57.

Agent: This will create an issue in acme/storefront:

          Title:  PRODUCTION RELEASE - storefront - v2.4.1
          Labels: release, production, approval
          Body:
            ### Sprint Reference (Sprint Planning Issue #)
            #52
            ### Version / Build Number
            v2.4.1
            ### Release Summary
            Checkout revamp: new cart summary, saved payment methods, tax
            rounding fix
            ### QA Summary + Evidence Links
            #57
            ### Overall QA Recommendation
            Approve for Production
            ### Deployment Authorized
            No

        Create this issue?

You: yes

Agent: Created #58. notify-release-approver posted a comment tagging this
        repo's RELEASE_APPROVER (john-lead).

  [ ... some time later, as john-lead ... ]

You: Approve release #58.

Agent: Checking gh auth status... authenticated as john-lead, which matches
        RELEASE_APPROVER. Posting "approved" on #58.

You: yes

Agent: Posted. authorize-deployment will add ready-for-deploy once both
        approvers (release + QA) have a qualifying comment on record.

Each "yes" above is a real confirmation gate — the agent shows the exact issue/comment content before it creates or posts anything, since it's a visible action in the repo.

Install from a terminal

No clone, no config. From your repo root, just run:

--with-labels needs gh auth. Add --with-agents (any AI agent) or --with-skill (Claude Code) for the instructions, and --dry-run to preview first.

Check and update from a terminal

Check what's installed and whether a newer version is available:

Then pull the latest workflows, templates, labels, and skill. --update replaces files that are already installed; without it, existing files are skipped:

For a reminder in any terminal whenever you cd into an out-of-date repo: