github-delivery-os 1.2.0 → 1.2.2

package/.github/scripts/authorize-deployment-verdict.js

@@ -0,0 +1,55 @@
+'use strict';
+
+// Pure verdict-computation logic for authorize-deployment.yml, extracted out
+// of the inline actions/github-script step so it can be unit tested directly
+// (see test/authorize-deployment-verdict.test.js) instead of only verified
+// by hand whenever it changes. Has no dependency on the `github`/`context`
+// globals actions/github-script injects — everything it needs is passed in.
+
+// Anchored to comment start + word boundary so keywords must lead the
+// comment (matches the documented convention) and can't match inside a
+// larger word (e.g. "ok" no longer matches "okay", "reject" no longer
+// matches "rejection") or as a substring anywhere in unrelated prose.
+const DECLINE_RE = /^(declined|rejected|reject|not approved)\b/i;
+const APPROVE_RE = /^(approved|approve|ok|go ahead)\b/i;
+const QA_APPROVE_RE = /^(qa approved|approved|qa ok|looks good)\b/i;
+
+const normalize = (s) => (s || '').toLowerCase();
+
+/**
+ * Walks comments in chronological order and keeps the LATEST verdict from
+ * each approver, rather than stopping at the first decline seen. This lets a
+ * release approver re-approve after an earlier decline (e.g. once fixes
+ * land) instead of being permanently stuck as declined.
+ *
+ * @param {Array<{ user?: { login?: string | null } | null, body?: string | null }>} comments
+ *   Chronological (oldest first), matching the order github.paginate(listComments) returns.
+ * @param {string} releaseApprover
+ * @param {string} qaApprover
+ * @returns {{ releaseVerdict: 'approved' | 'declined' | null, qaApproved: boolean }}
+ */
+function computeVerdict(comments, releaseApprover, qaApprover) {
+  let releaseVerdict = null;
+  let qaApproved = false;
+
+  for (const comment of comments) {
+    const login = comment.user && comment.user.login;
+    const body = (comment.body || '').trim();
+
+    if (normalize(login) === normalize(releaseApprover)) {
+      if (DECLINE_RE.test(body)) {
+        releaseVerdict = 'declined';
+      } else if (APPROVE_RE.test(body)) {
+        releaseVerdict = 'approved';
+      }
+    }
+
+    if (normalize(login) === normalize(qaApprover) && QA_APPROVE_RE.test(body)) {
+      qaApproved = true;
+    }
+  }
+
+  return { releaseVerdict, qaApproved };
+}
+
+module.exports = { computeVerdict, DECLINE_RE, APPROVE_RE, QA_APPROVE_RE };

package/.github/scripts/auto-close-sprint.js

@@ -0,0 +1,124 @@
+'use strict';
+
+// Pure burn-down/health computation for auto-close-sprint.yml, extracted so
+// it can be unit tested directly (see test/auto-close-sprint.test.js)
+// instead of only verified by hand.
+
+/**
+ * @param {string} body - a child issue's body
+ * @returns {number | null} the parent sprint issue number, or null if this
+ *   issue isn't a sprint child (no "Parent Sprint: #N" line).
+ */
+function parseParentSprintNumber(body) {
+  const match = (body || '').match(/Parent Sprint:\s*#(\d+)/);
+  return match ? parseInt(match[1], 10) : null;
+}
+
+/**
+ * Parses sprint dates out of a sprint issue's body, supporting both the
+ * combined "Sprint Dates: X to Y" format and the separate "Sprint Start" /
+ * "Sprint End" field format (the sprint_planning.yml template).
+ *
+ * @param {string} sprintBody - the sprint (parent) issue's body
+ * @returns {{ startDate: Date, endDate: Date } | null} null if neither
+ *   format matched.
+ */
+function parseSprintDates(sprintBody) {
+  const body = sprintBody || '';
+
+  const rangeMatch = body.match(/Sprint Dates[\s\S]*?(\d{4}-\d{2}-\d{2})\s*to\s*(\d{4}-\d{2}-\d{2})/i);
+  if (rangeMatch) {
+    return { startDate: new Date(rangeMatch[1]), endDate: new Date(rangeMatch[2]) };
+  }
+
+  const startMatch = body.match(/Sprint Start[\s\S]*?(\d{4}-\d{2}-\d{2})/i);
+  const endMatch = body.match(/Sprint End[\s\S]*?(\d{4}-\d{2}-\d{2})/i);
+  if (startMatch && endMatch) {
+    return { startDate: new Date(startMatch[1]), endDate: new Date(endMatch[1]) };
+  }
+
+  return null;
+}
+
+/**
+ * @param {Date} startDate
+ * @param {Date} endDate
+ * @param {Date} now
+ * @returns {number} percent of the sprint's duration elapsed as of `now`,
+ *   clamped to [0, 100]. Returns 100 for a zero-or-negative-length sprint
+ *   (Start >= End — a data-entry mistake) or an unparseable date (e.g. an
+ *   out-of-range "2026-13-05" typo, which regex-matches the YYYY-MM-DD
+ *   shape but produces an Invalid Date) instead of dividing by zero or NaN:
+ *   that NaN would otherwise flow into the posted burn-down as "Time
+ *   Elapsed: NaN%", and every NaN comparison in computeHealthEmoji is
+ *   false, so it'd silently default to the green/no-warning branch instead
+ *   of flagging the broken dates. `!(totalDuration > 0)` (rather than
+ *   `totalDuration <= 0`) catches NaN too, since every comparison against
+ *   NaN is false — `NaN <= 0` is false, but so is `NaN > 0`, and negating
+ *   that is true.
+ */
+function computeTimePercent(startDate, endDate, now) {
+  const totalDuration = endDate - startDate;
+  if (!(totalDuration > 0)) return 100;
+  const elapsed = now - startDate;
+  return Math.max(0, Math.min(100, Math.round((elapsed / totalDuration) * 100)));
+}
+
+/**
+ * @param {Array<{ state: string }>} children
+ * @returns {{ progressPercent: number, closedCount: number, totalCount: number }}
+ */
+function computeProgress(children) {
+  const totalCount = children.length;
+  const closedCount = children.filter((i) => i.state === 'closed').length;
+  const progressPercent = totalCount === 0 ? 0 : Math.round((closedCount / totalCount) * 100);
+  return { progressPercent, closedCount, totalCount };
+}
+
+/**
+ * Sprint health relative to time elapsed: red if progress trails time by
+ * more than 10 points, yellow if behind at all, green otherwise.
+ *
+ * @returns {'🟢' | '🟡' | '🔴'}
+ */
+function computeHealthEmoji(progressPercent, timePercent) {
+  if (progressPercent < timePercent - 10) return '🔴';
+  if (progressPercent < timePercent) return '🟡';
+  return '🟢';
+}
+
+/**
+ * @returns {string} a block-character progress bar, e.g. "████░░░░░░░░░░░░░░░░".
+ */
+function renderBurnDown(progressPercent, totalBars = 20) {
+  const filledBars = Math.round((progressPercent / 100) * totalBars);
+  return '█'.repeat(filledBars) + '░'.repeat(totalBars - filledBars);
+}
+
+/**
+ * Replaces any previous "## 🚦 Sprint Status" block in the sprint body with
+ * a freshly rendered one (appended at the end).
+ */
+function updateSprintBody(sprintBody, { progressPercent, timePercent, healthEmoji, burnDown }) {
+  let updatedBody = (sprintBody || '').replace(/## 🚦 Sprint Status[\s\S]*?---/g, '');
+
+  updatedBody +=
+    `\n\n---\n\n## 🚦 Sprint Status\n\n` +
+    `Progress: **${progressPercent}%**\n` +
+    `Time Elapsed: **${timePercent}%**\n\n` +
+    `Health: ${healthEmoji}\n\n` +
+    `### 📉 Burn-down\n` +
+    `\`${burnDown}\` ${progressPercent}%\n\n---`;
+
+  return updatedBody;
+}
+
+module.exports = {
+  parseParentSprintNumber,
+  parseSprintDates,
+  computeTimePercent,
+  computeProgress,
+  computeHealthEmoji,
+  renderBurnDown,
+  updateSprintBody,
+};

package/.github/scripts/package.json

@@ -0,0 +1,3 @@
+{
+  "type": "commonjs"
+}

package/.github/scripts/sprint-child-creator.js

@@ -0,0 +1,34 @@
+'use strict';
+
+// Pure parsing logic for sprint-child-creator.yml, extracted so it can be
+// unit tested directly (see test/sprint-child-creator.test.js) instead of
+// only verified by hand.
+
+/**
+ * Extracts the feature list from a sprint-planning issue body's
+ * "### Sprint Features" section (one feature per line, up to the next
+ * heading or end of body).
+ *
+ * @param {string} body - the sprint issue's body
+ * @returns {string[]} feature titles, in the order they appear. Empty if
+ *   there's no Sprint Features section, or it has no non-blank lines.
+ */
+function parseFeatures(body) {
+  const featuresMatch = (body || '').match(/### Sprint Features[\s\S]*?(?=###|$)/);
+  if (!featuresMatch) return [];
+
+  return featuresMatch[0]
+    .split('\n')
+    .map((line) => line.trim())
+    .filter((line) => line && !line.startsWith('###'));
+}
+
+/**
+ * @param {number} parentNumber - the sprint (parent) issue number
+ * @returns {string} body to use for each generated child issue
+ */
+function buildChildBody(parentNumber) {
+  return `Parent Sprint: #${parentNumber}\n\n---\n*Created by Delivery OS Sprint Child Creator*`;
+}
+
+module.exports = { parseFeatures, buildChildBody };

package/.github/workflows/authorize-deployment.yml

@@ -58,19 +58,40 @@ jobs:
 
             const { releaseVerdict, qaApproved } = computeVerdict(comments, releaseApprover, qaApprover);
 
-            const currentLabels = (context.payload.issue.labels || []).map((l) => l.name);
+            // Nothing to act on this run (most comments on a production issue
+            // are routine discussion, not a verdict-changing approval/decline)
+            // — return before the live label fetch below, which only matters
+            // once we actually have a verdict to check against current state.
+            const hasActionableVerdict =
+              releaseVerdict === "declined" || (releaseVerdict === "approved" && qaApproved);
+            if (!hasActionableVerdict) return;
+
+            // Fetch labels live rather than trusting context.payload.issue.labels:
+            // that's a snapshot fixed at the triggering event's delivery time.
+            // Two comments posted seconds apart queue under the concurrency
+            // group above and run sequentially, but each was still delivered
+            // (and its label snapshot captured) before either job actually ran
+            // — serializing execution order doesn't refresh an already-stale
+            // snapshot. A live re-fetch is what actually lets the second
+            // (queued) run see what the first one just did.
+            const { data: liveIssue } = await github.rest.issues.get({ owner, repo, issue_number: issueNumber });
+            const currentLabels = (liveIssue.labels || []).map((l) => (typeof l === "string" ? l : l.name));
             const alreadyDeclined = currentLabels.includes("declined");
             const alreadyReady = currentLabels.includes("ready-for-deploy");
 
             if (releaseVerdict === "declined") {
               if (alreadyDeclined) return; // avoid re-posting on every later comment
 
-              await github.rest.issues.addLabels({
-                owner,
-                repo,
-                issue_number: issueNumber,
-                labels: ["declined"]
-              });
+              try {
+                await github.rest.issues.addLabels({
+                  owner,
+                  repo,
+                  issue_number: issueNumber,
+                  labels: ["declined"]
+                });
+              } catch (e) {
+                console.log(`Failed to add 'declined' label: ${e.message || e}`);
+              }
 
               try {
                 await github.rest.issues.removeLabel({
@@ -103,12 +124,16 @@ jobs:
                 });
               } catch (e) {}
 
-              await github.rest.issues.addLabels({
-                owner,
-                repo,
-                issue_number: issueNumber,
-                labels: ["ready-for-deploy"]
-              });
+              try {
+                await github.rest.issues.addLabels({
+                  owner,
+                  repo,
+                  issue_number: issueNumber,
+                  labels: ["ready-for-deploy"]
+                });
+              } catch (e) {
+                console.log(`Failed to add 'ready-for-deploy' label: ${e.message || e}`);
+              }
 
               await github.rest.issues.createComment({
                 owner,

package/.github/workflows/auto-close-sprint.yml

@@ -70,17 +70,23 @@ jobs:
 
             // Paginate: a plain listForRepo call caps at one page (100 issues) and
             // would silently undercount children in repos with more open+closed
-            // issues than that, skewing the burn-down. Scoped to `sprint-active`
-            // (the label every child issue gets on creation) instead of every
-            // issue in the repo, so this stays cheap in repos with a lot of
-            // unrelated issue history — this workflow now runs serialized per
-            // repo, so an unscoped full-repo fetch on every child close would
-            // add up fast.
+            // issues than that, skewing the burn-down.
+            //
+            // Deliberately NOT scoped to labels: "sprint-active" (an earlier
+            // version of this workflow did that, for cost — cheaper in repos
+            // with a lot of unrelated issue history). That's wrong: a child
+            // issue relabeled away from sprint-active during triage (e.g. to
+            // "bug") while still open would silently drop out of BOTH the
+            // numerator and denominator of the progress calculation instead
+            // of just being excluded from the closed count — the sprint could
+            // report inflated progress, or even reach a false 100% and
+            // auto-close, while that untracked child is still open. Matches
+            // docs/governance.md's documented trigger ("body has Parent
+            // Sprint"), which is body-content-based, not label-based.
             const allIssues = await github.paginate(github.rest.issues.listForRepo, {
               owner: context.repo.owner,
               repo: context.repo.repo,
               state: "all",
-              labels: "sprint-active",
               per_page: 100
             });
 

package/.github/workflows/telegram-issues.yml

@@ -103,14 +103,20 @@ jobs:
             # Case-insensitive actor comparison: GitHub logins are case-insensitive,
             # but a plain bash == is not, so a RELEASE_APPROVER var with different
             # casing than the actual login would otherwise never match here.
-            # Anchored to the start of a line, matching the same keyword set and
-            # convention as authorize-deployment.yml's DECLINE_RE, so this alert
-            # can't fire for a comment that workflow wouldn't actually treat as a
-            # decline (e.g. "not approved" appearing mid-sentence).
-            if [[ "${ACTOR,,}" == "${RELEASE_APPROVER,,}" ]] && echo "$COMMENT_BODY" | grep -iqE "^(declined|rejected|reject|not approved)"; then
+            # Anchored to the start of a line + word boundary (\b), matching the
+            # same keyword set and convention as authorize-deployment.yml's real
+            # DECLINE_RE/APPROVE_RE, so this alert can't fire for a comment that
+            # workflow wouldn't actually treat as a decline/approval (e.g. "not
+            # approved" mid-sentence, or "okay, I'll look at this tomorrow" —
+            # "ok" without \b would otherwise match as a false approval).
+            if [[ "${ACTOR,,}" == "${RELEASE_APPROVER,,}" ]] && echo "$COMMENT_BODY" | grep -iqE "^(declined|rejected|reject|not approved)\b"; then
               MESSAGE="🔴🛑 RELEASE DECLINED%0A$TITLE%0A$URL%0A---%0A👤 $ACTOR%0A🕒 $TIMESTAMP"
 
-            elif [[ "${ACTOR,,}" == "${RELEASE_APPROVER,,}" ]] && echo "$COMMENT_BODY" | grep -iq "^approved"; then
+            # Matches authorize-deployment.yml's full APPROVE_RE keyword set
+            # (approved|approve|ok|go ahead), not just "approved" — it used to
+            # miss "ok"/"go ahead"/"approve", so a release could be approved
+            # for real with no Telegram alert sent for it.
+            elif [[ "${ACTOR,,}" == "${RELEASE_APPROVER,,}" ]] && echo "$COMMENT_BODY" | grep -iqE "^(approved|approve|ok|go ahead)\b"; then
               MESSAGE="🟢🛡️ RELEASE APPROVED%0A$TITLE%0A$URL%0A---%0A👤 $ACTOR%0A🕒 $TIMESTAMP"
 
             elif [[ "${{ contains(github.event.issue.labels.*.name || fromJSON('[]'), 'bug') }}" == "true" ]]; then

package/README.md

@@ -63,15 +63,15 @@ 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 |
+| Workflow | Trigger | Purpose |
+|----------|---------|---------|
+| `sprint-child-creator` | Issue opened, title contains `SPRINT -` | Parses "Sprint Features (One Per Line)" and creates one child issue per line, each linked back with `Parent Sprint: #N` |
+| `auto-close-sprint` | Issue closed, body contains `Parent Sprint` | Recomputes the parent sprint's burn-down/health and rewrites its status section; auto-closes the sprint at 100% |
+| `notify-release-approver` | Issue opened, labeled `production` | Comments on the issue tagging the repo's `RELEASE_APPROVER` |
+| `authorize-deployment` | Comment posted on a `production`-labeled issue | Checks the commenter and keyword against `RELEASE_APPROVER`/`QA_APPROVER`; once both approve, adds `ready-for-deploy` |
+| `auto-assign-qa` | Issue opened/labeled `qa` or `qa-request` | Assigns the repo's configured `QA_ASSIGNEES` |
+| `telegram-issues` | Issue/comment/PR events | Sends a Telegram alert if `TELEGRAM_BOT_TOKEN`/`TELEGRAM_CHAT_ID` are configured |
+| `setup-labels` | Manual (`workflow_dispatch`) | One-time run that creates all labels Delivery OS needs |
 
 Workflows and templates are **copied directly** into your repo. No `workflow_call` or external references.
 
@@ -104,6 +104,230 @@ When you open an issue using the **Sprint Planning** template with a title like
 
 ---
 
+## Operating From Claude Code (`--with-skill`)
+
+Installing with `--with-skill` drops a `.claude/skills/delivery-ops/SKILL.md` skill into the repo, scoped to *this* repo's Delivery OS install. It lets anyone using [Claude Code](https://claude.com/claude-code) drive the workflows above by asking in plain language — e.g. "create a sprint for the checkout redesign" — instead of hand-building `gh issue create` calls and remembering each template's exact field names.
+
+Before doing anything, it checks the target repo: confirms Delivery OS is actually installed, that `Setup Labels` has been run, and that `RELEASE_APPROVER` / `QA_APPROVER` / `QA_ASSIGNEES` are configured — flagging (or offering to fix) gaps instead of silently creating an issue that does nothing. It also always shows the constructed title/body/labels or comment text for confirmation before creating or posting for real, since these are visible actions in the repo's activity, not a local preview.
+
+### Create a sprint
+1. Ask: *"Create a sprint called Sprint 14 for \<goal>, running \<start> to \<end>, with features: \<one per line>"*
+2. It opens an issue titled `SPRINT - Sprint 14`, labeled `sprint` + `planning`, with `### Sprint Name` / `Start` / `End` / `Goal` / `Features (One Per Line)` / `Approved` fields filled in.
+3. On open, `sprint-child-creator` splits each feature line into its own child issue, labeled `sprint-active` and linked back with `Parent Sprint: #N`.
+4. Close each child issue as work finishes — that's what advances the burn-down; `auto-close-sprint` recomputes it and rewrites the parent's `## 🚦 Sprint Status` section, auto-closing the sprint at 100%.
+
+### Request a production release
+1. Ask: *"Open a production release for \<project> v1.2.0, sprint #N, summary: \<summary>"*
+2. It opens an issue titled `PRODUCTION RELEASE - <project> - v1.2.0`, labeled `release` + `production` + `approval`, with the sprint reference, version, release summary, QA summary/links, and `Deployment Authorized: No`.
+3. On open, `notify-release-approver` comments tagging the repo's configured `RELEASE_APPROVER`.
+
+### Approve or decline a release
+1. Ask: *"Approve release #N"* or *"Decline release #N — \<reason>"*.
+2. It checks that the currently authenticated `gh` login matches the repo's `RELEASE_APPROVER` — if not, it stops and says so instead of posting a comment that would silently do nothing.
+3. It posts a comment starting with a recognized keyword (`approved`, `ok`, `go ahead` to approve; `declined`, `rejected`, `not approved` to decline) — `authorize-deployment` only reacts to that leading keyword from the exact configured approver. A later comment from the same approver overrides an earlier one.
+
+### Request QA
+1. Ask: *"Open a QA request for \<feature>, related to issue #N, testing \<what/where>"*
+2. It opens an issue titled `QA REQUEST - <feature>`, labeled `qa-request`, with the related task, what to test, environment/build link, and acceptance criteria.
+3. On open, `auto-assign-qa` assigns the repo's configured `QA_ASSIGNEES`.
+
+### Approve QA
+1. Ask: *"Mark QA #N as approved"* (or *"looks good"*).
+2. Same login check as release approval, but against `QA_APPROVER`.
+3. Posts a comment starting with `qa approved`, `approved`, `qa ok`, or `looks good`.
+
+### Report a bug
+1. Ask: *"File a bug: \<one-line summary>, severity \<level>, steps: \<...>"*
+2. It opens an issue titled `[BUG] <summary>`, labeled `bug` + `qa`, with platform, severity, build/version, steps to reproduce, expected vs. actual result, and test environment.
+
+### Track a task
+1. Ask: *"Create a task to \<summary>, owner \<name>, priority P1"*
+2. It opens an issue titled `TASK - <summary>`, labeled `task`, with owner, priority, status, acceptance criteria, and links. (No workflow trigger — this is plain tracking.)
+
+### Check status
+- *"What's the status of issue #N?"* → current labels and latest comments.
+- *"How's Sprint 14 doing?"* → reads the parent issue's `## 🚦 Sprint Status` section (progress %, time elapsed, health, burn-down bar).
+- *"What releases are waiting on approval?"* / *"What sprints are active?"* / *"What QA requests are open?"* → lists issues by label (`production`, `sprint`, `qa-request`) so you don't need an issue number in hand.
+
+See [How To](docs/how-to.md) for the underlying workflows this drives, field by field.
+
+### Example: filing a bug and a task, step by step
+
+Worked against `jkaweesi22/klero`, a repo with Delivery OS installed. The bug part of this was actually run — that issue really exists at [jkaweesi22/klero#1](https://github.com/jkaweesi22/klero/issues/1); the task part follows the identical steps but wasn't actually created, shown for the field shape only.
+
+**Filing the bug:**
+
+1. In Claude Code, inside (or pointed at, via `--repo`) the target repo, describe the bug in plain language:
+   > *File a bug on jkaweesi22/klero — 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. Claude pre-flights the repo — confirms Delivery OS is installed and the `bug`/`qa` labels exist.
+3. Claude 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, field by field: `Platform(s) Affected` → Web, `Severity` → High, `Build / Version` → main (as deployed), `Bug Summary`, `Steps to Reproduce` (numbered), `Expected Result`, `Actual Result`, `Test Environment` → Chrome, desktop, production.
+4. Confirm ("yes") when asked to create it.
+5. Claude runs `gh issue create` and reports back the issue — [jkaweesi22/klero#1](https://github.com/jkaweesi22/klero/issues/1). Nothing else happens automatically; bug reports don't trigger a workflow, they're just labeled and tracked.
+
+**Filing the follow-up task:**
+
+1. Ask Claude 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 @jkaweesi22, priority P1, status Backlog, acceptance: form blocks submission until a valid phone number is entered. Link it to #1.*
+2. Claude shows the constructed issue:
+   - Title: `TASK - Add phone number validation to order form`
+   - Labels: `task`
+   - Body: `Task Summary`, `Description` (references #1), `Owner` → @jkaweesi22, `Priority` → P1 - High, `Status` → Backlog, `Acceptance Criteria`, `Artifacts / Links` → Related bug: #1.
+3. Confirm ("yes") to create it.
+4. Claude runs `gh issue create`. Same as the bug — no workflow trigger, just labeled and tracked, now linked back to the bug it addresses.
+
+### Full example: shipping a feature end-to-end
+
+A realistic Claude Code session, run from inside the consumer repo (the skill defaults to it since it was installed with `--with-skill` there). `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
+
+Claude: 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
+
+Claude: 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?
+
+Claude: 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.
+
+Claude: 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
+
+Claude: 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.
+
+Claude: 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
+
+Claude: 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.
+
+Claude: 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
+
+Claude: Posted. Now close #55 to update the sprint burn-down?
+
+You: yes
+
+Claude: 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.
+
+Claude: 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
+
+Claude: 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.
+
+Claude: Checking gh auth status... authenticated as john-lead, which matches
+        RELEASE_APPROVER. Posting "approved" on #58.
+
+You: yes
+
+Claude: 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 — Claude shows the exact issue/comment content before it creates or posts anything, since it's a visible action in the repo.
+
+---
+
 ## Documentation
 
 | Document | Description |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "github-delivery-os",
-  "version": "1.2.0",
+  "version": "1.2.2",
   "description": "A GitHub-native Delivery Governance Framework for structured sprint execution, QA review, and collaborative production release control.",
   "main": "src/install.js",
   "bin": {
@@ -45,6 +45,10 @@
     ".github/workflows/auto-assign-qa.yml",
     ".github/workflows/telegram-issues.yml",
     ".github/workflows/setup-labels.yml",
+    ".github/scripts/authorize-deployment-verdict.js",
+    ".github/scripts/auto-close-sprint.js",
+    ".github/scripts/sprint-child-creator.js",
+    ".github/scripts/package.json",
     ".github/ISSUE_TEMPLATE",
     ".claude/skills/delivery-ops"
   ],

package/src/install.js

@@ -20,6 +20,33 @@ const WORKFLOWS = [
   'setup-labels',
 ];
 
+// Pure logic some of the workflows above require() at runtime from
+// .github/scripts/<name>.js (see .github/workflows/authorize-deployment.yml
+// etc.) — these are required dependencies of those workflows, not optional,
+// so they're always copied alongside them, the same as WORKFLOWS. Also list
+// them explicitly in package.json's "files".
+const SCRIPTS = ['authorize-deployment-verdict', 'auto-close-sprint', 'sprint-child-creator'];
+
+// These scripts are CommonJS (`require`/`module.exports`). Node picks CJS vs.
+// ESM per-file by walking up to the nearest package.json — so a consumer repo
+// whose own root package.json has `"type": "module"` would otherwise make
+// Node treat these .js files as ES modules too, breaking `require()` at
+// runtime with "ReferenceError: module is not defined in ES module scope".
+// This override pins the .github/scripts subtree to CommonJS regardless of
+// the consumer's own type field. Always installed alongside SCRIPTS, same as
+// SCRIPTS is alongside WORKFLOWS — not itself require()'d by anything, but a
+// required dependency of every script that is.
+const SCRIPTS_PACKAGE_JSON = 'package.json';
+
+// Which workflow requires which script, so `status` can flag a workflow
+// that's present but whose required script is missing (an install that will
+// fail with MODULE_NOT_FOUND the next time that workflow actually runs).
+const REQUIRED_SCRIPT_BY_WORKFLOW = {
+  'authorize-deployment': 'authorize-deployment-verdict',
+  'auto-close-sprint': 'auto-close-sprint',
+  'sprint-child-creator': 'sprint-child-creator',
+};
+
 const LABELS = [
   ['intake', '0E8A16'],
   ['bug', 'D93F0B'],
@@ -101,6 +128,44 @@ function fetchLatestVersion(timeoutMs = 3000) {
   });
 }
 
+// Copies each `${name}${ext}` from srcDir to destDir for a fixed list of
+// expected filenames — the shared logic behind copying WORKFLOWS and SCRIPTS
+// (both: a required, always-on set of individually-named files, as opposed
+// to templates, which copies whatever's found in a directory, or the skill,
+// a single optional file). `label` is what's printed for each entry, e.g.
+// `.github/scripts/auto-close-sprint.js` — pass names already including
+// their directory prefix so log lines are self-explanatory on their own.
+function copyManagedFiles(names, ext, srcDir, destDir, { overwrite, dryRun, relDir }) {
+  let copied = 0;
+  let skipped = 0;
+
+  for (const name of names) {
+    const src = path.join(srcDir, `${name}${ext}`);
+    const dest = path.join(destDir, `${name}${ext}`);
+    const label = `${relDir}/${name}${ext}`;
+
+    if (!fs.existsSync(src)) {
+      console.log(`  Warning: source not found: ${label}`);
+      skipped++; // missing source must block a "clean install" claim, not just warn
+      continue;
+    }
+
+    if (fs.existsSync(dest) && !overwrite) {
+      console.log(`  Skipped (exists): ${label}`);
+      skipped++;
+    } else if (dryRun) {
+      console.log(`  [dry-run] Would create: ${label}`);
+      copied++;
+    } else {
+      fs.copyFileSync(src, dest);
+      console.log(`  Created: ${label}`);
+      copied++;
+    }
+  }
+
+  return { copied, skipped };
+}
+
 function getPackageRoot() {
   // When installed via npm, __dirname is node_modules/github-delivery-os/src
   const possibleRoots = [
@@ -129,6 +194,7 @@ function runInstall(options) {
   const pkgRoot = getPackageRoot();
   const workflowsSrc = path.join(pkgRoot, '.github', 'workflows');
   const templatesSrc = path.join(pkgRoot, '.github', 'ISSUE_TEMPLATE');
+  const scriptsSrc = path.join(pkgRoot, '.github', 'scripts');
   const skillSrc = path.join(pkgRoot, SKILL_REL_PATH);
   const targetAbs = path.resolve(process.cwd(), targetDir);
 
@@ -151,41 +217,57 @@ function runInstall(options) {
   // Ensure target structure
   const workflowsDest = path.join(targetAbs, '.github', 'workflows');
   const templatesDest = path.join(targetAbs, '.github', 'ISSUE_TEMPLATE');
+  const scriptsDest = path.join(targetAbs, '.github', 'scripts');
 
   if (!dryRun) {
     fs.mkdirSync(workflowsDest, { recursive: true });
     fs.mkdirSync(templatesDest, { recursive: true });
+    fs.mkdirSync(scriptsDest, { recursive: true });
   }
 
   let workflowsCopied = 0;
   let templatesCopied = 0;
+  let scriptsCopied = 0;
   let skillCopied = 0;
-  let workflowsSkipped = 0;
-  let templatesSkipped = 0;
-  let skillSkipped = 0;
-
-  // Copy workflows
-  for (const wf of WORKFLOWS) {
-    const src = path.join(workflowsSrc, `${wf}.yml`);
-    const dest = path.join(workflowsDest, `${wf}.yml`);
+  let workflowsSkipped;
+  let scriptsSkipped;
 
-    if (!fs.existsSync(src)) {
-      console.log(`  Warning: source not found: ${wf}.yml`);
-      continue;
-    }
+  // Copy workflows (always on — not optional)
+  ({ copied: workflowsCopied, skipped: workflowsSkipped } = copyManagedFiles(
+    WORKFLOWS,
+    '.yml',
+    workflowsSrc,
+    workflowsDest,
+    { overwrite, dryRun, relDir: '.github/workflows' }
+  ));
+
+  // Copy the scripts the workflows above require() at runtime — required,
+  // not optional, so (unlike templates/skill) this always runs too.
+  ({ copied: scriptsCopied, skipped: scriptsSkipped } = copyManagedFiles(
+    SCRIPTS,
+    '.js',
+    scriptsSrc,
+    scriptsDest,
+    { overwrite, dryRun, relDir: '.github/scripts' }
+  ));
+
+  // The CommonJS-pinning package.json (see SCRIPTS_PACKAGE_JSON above) —
+  // always installed alongside SCRIPTS, via the same helper, counted the
+  // same way (mirrors how scripts/install.sh reuses copy_managed_files for
+  // this exact file rather than hand-rolling the copy).
+  const { name: scriptsPkgName, ext: scriptsPkgExt } = path.parse(SCRIPTS_PACKAGE_JSON);
+  const scriptsPkgResult = copyManagedFiles(
+    [scriptsPkgName],
+    scriptsPkgExt,
+    scriptsSrc,
+    scriptsDest,
+    { overwrite, dryRun, relDir: '.github/scripts' }
+  );
+  scriptsCopied += scriptsPkgResult.copied;
+  scriptsSkipped += scriptsPkgResult.skipped;
 
-    if (fs.existsSync(dest) && !overwrite) {
-      console.log(`  Skipped (exists): ${wf}.yml`);
-      workflowsSkipped++;
-    } else if (dryRun) {
-      console.log(`  [dry-run] Would create: ${wf}.yml`);
-      workflowsCopied++;
-    } else {
-      fs.copyFileSync(src, dest);
-      console.log(`  Created: ${wf}.yml`);
-      workflowsCopied++;
-    }
-  }
+  let templatesSkipped = 0;
+  let skillSkipped = 0;
 
   // Copy templates
   if (withTemplates && fs.existsSync(templatesSrc)) {
@@ -291,12 +373,28 @@ function runInstall(options) {
   }
 
   // Record what got installed so `status` can report a version and detect
-  // drift. Only claim a version when the on-disk files actually match it: an
-  // overwrite, or a fresh install where nothing had to be skipped. A partial
-  // skip-mode install would leave older file content on disk, so don't
-  // overwrite a previously recorded (possibly accurate, possibly newer)
-  // version with a number that isn't actually true on disk yet.
-  const cleanInstall = overwrite || (workflowsSkipped === 0 && templatesSkipped === 0 && skillSkipped === 0);
+  // drift. Only claim a version when the on-disk files actually match it.
+  //
+  // Two ways this can go wrong, both of which must block the claim:
+  //  1. A skip-mode install left older content on disk for something that
+  //     WAS requested this run (tracked by the *Skipped counters below).
+  //  2. An --overwrite run touches only what was explicitly requested
+  //     (workflows + scripts always; templates/skill only if their flags
+  //     were passed) — templates or skill already on disk from an earlier
+  //     install, but not requested this run, are left untouched and stale,
+  //     even though --overwrite makes every *Skipped counter read 0. Naively
+  //     trusting `overwrite` alone would then claim the whole install is
+  //     current when part of it demonstrably wasn't touched.
+  const templatesPresentButNotTouched =
+    !withTemplates && TEMPLATES.some((t) => fs.existsSync(path.join(templatesDest, t)));
+  const skillPresentButNotTouched = !withSkill && fs.existsSync(skillPath(targetAbs));
+  const cleanInstall =
+    workflowsSkipped === 0 &&
+    templatesSkipped === 0 &&
+    scriptsSkipped === 0 &&
+    skillSkipped === 0 &&
+    !templatesPresentButNotTouched &&
+    !skillPresentButNotTouched;
   if (!dryRun && cleanInstall) {
     const pkgVersion = require(path.join(pkgRoot, 'package.json')).version;
     writeManifest(targetAbs, pkgVersion);
@@ -305,19 +403,28 @@ function runInstall(options) {
   // Summary
   console.log('');
   if (!dryRun && !cleanInstall) {
-    console.log('  Note: some files already existed and were skipped, so the recorded');
-    console.log('  Delivery OS version was not updated. Re-run with --overwrite to sync');
-    console.log('  all files (and the recorded version) to the latest release.');
+    if (templatesPresentButNotTouched || skillPresentButNotTouched) {
+      console.log('  Note: previously-installed templates and/or the Claude Code skill exist');
+      console.log('  on disk but were not requested this run, so the recorded Delivery OS');
+      console.log('  version was not updated. Re-run with --overwrite plus --with-templates');
+      console.log('  and/or --with-skill to bring everything (and the recorded version) in sync.');
+    } else {
+      console.log('  Note: some files already existed and were skipped, so the recorded');
+      console.log('  Delivery OS version was not updated. Re-run with --overwrite to sync');
+      console.log('  all files (and the recorded version) to the latest release.');
+    }
     console.log('');
   }
-  if (workflowsCopied > 0 || templatesCopied > 0 || skillCopied > 0 || labelsCreated > 0) {
+  if (workflowsCopied > 0 || templatesCopied > 0 || scriptsCopied > 0 || skillCopied > 0 || labelsCreated > 0) {
     if (dryRun) {
       if (workflowsCopied > 0) console.log(`Would install ${workflowsCopied} workflow(s).`);
       if (templatesCopied > 0) console.log(`Would copy ${templatesCopied} issue template(s).`);
+      if (scriptsCopied > 0) console.log(`Would install ${scriptsCopied} supporting script(s).`);
       if (skillCopied > 0) console.log('Would add the Claude Code delivery-ops skill.');
     } else {
       if (workflowsCopied > 0) console.log(`Installed ${workflowsCopied} workflow(s).`);
       if (templatesCopied > 0) console.log(`Copied ${templatesCopied} issue template(s).`);
+      if (scriptsCopied > 0) console.log(`Installed ${scriptsCopied} supporting script(s).`);
       if (skillCopied > 0) console.log('Added the Claude Code delivery-ops skill.');
       if (labelsCreated > 0) console.log(`Created ${labelsCreated} label(s).`);
     }
@@ -380,7 +487,31 @@ async function runStatus(options) {
   );
   const skillInstalled = fs.existsSync(skillPath(targetAbs));
 
-  if (installedWorkflows.length > 0 || installedTemplates.length > 0) {
+  // A workflow can be present while the script it require()s at runtime is
+  // not — e.g. an install from before this check existed, or a manual
+  // partial copy. That workflow will fail (MODULE_NOT_FOUND) the next time
+  // it actually runs, silently, since nothing here executes the workflow
+  // itself to notice.
+  const brokenWorkflows = installedWorkflows.filter((wf) => {
+    const requiredScript = REQUIRED_SCRIPT_BY_WORKFLOW[wf];
+    if (!requiredScript) return false;
+    return !fs.existsSync(path.join(targetAbs, '.github', 'scripts', `${requiredScript}.js`));
+  });
+
+  // A script can be present while the CommonJS-pinning package.json (see
+  // SCRIPTS_PACKAGE_JSON in src/install.js) is missing — e.g. an install from
+  // before this fix existed. That's fine in a repo whose own package.json
+  // has no "type" field or "type": "commonjs", but breaks with
+  // "ReferenceError: module is not defined in ES module scope" the moment
+  // the consumer repo's package.json has "type": "module". Flagged
+  // separately from brokenWorkflows since it's silent until that condition
+  // is hit, not an immediate break.
+  const scriptsRequiringPkgJson = installedWorkflows.some((wf) => REQUIRED_SCRIPT_BY_WORKFLOW[wf]);
+  const scriptsPkgJsonMissing =
+    scriptsRequiringPkgJson &&
+    !fs.existsSync(path.join(targetAbs, '.github', 'scripts', SCRIPTS_PACKAGE_JSON));
+
+  if (installedWorkflows.length > 0 || installedTemplates.length > 0 || skillInstalled) {
     const manifest = readManifest(targetAbs);
     if (manifest && manifest.version) {
       const installedOn = manifest.installedAt ? ` (installed ${manifest.installedAt.slice(0, 10)})` : '';
@@ -411,6 +542,26 @@ async function runStatus(options) {
     installedWorkflows.forEach((wf) => console.log(`  ✓ ${wf}.yml`));
     console.log('');
   }
+
+  if (brokenWorkflows.length > 0) {
+    console.log('⚠️  Broken install detected:');
+    brokenWorkflows.forEach((wf) => {
+      console.log(`  ${wf}.yml requires .github/scripts/${REQUIRED_SCRIPT_BY_WORKFLOW[wf]}.js, which is missing.`);
+    });
+    console.log('  That workflow will fail with MODULE_NOT_FOUND the next time it runs.');
+    console.log('  Fix: npx github-delivery-os@latest install --overwrite .');
+    console.log('');
+  }
+
+  if (scriptsPkgJsonMissing) {
+    console.log(`⚠️  .github/scripts/${SCRIPTS_PACKAGE_JSON} is missing.`);
+    console.log('  If this repo\'s own package.json has "type": "module", every workflow that');
+    console.log('  require()s a script under .github/scripts will fail with "module is not');
+    console.log('  defined in ES module scope" the next time it runs.');
+    console.log('  Fix: npx github-delivery-os@latest install --overwrite .');
+    console.log('');
+  }
+
   if (installedTemplates.length > 0) {
     console.log('Templates:');
     installedTemplates.forEach((t) => console.log(`  ✓ ${t}`));
@@ -424,7 +575,7 @@ async function runStatus(options) {
     console.log('');
   }
 
-  if (installedWorkflows.length > 0 || installedTemplates.length > 0) {
+  if (installedWorkflows.length > 0 || installedTemplates.length > 0 || skillInstalled) {
     console.log('Claude Code skill:');
     console.log(
       skillInstalled
@@ -434,7 +585,7 @@ async function runStatus(options) {
     console.log('');
   }
 
-  if (installedWorkflows.length === 0 && installedTemplates.length === 0) {
+  if (installedWorkflows.length === 0 && installedTemplates.length === 0 && !skillInstalled) {
     console.log('Delivery OS is not installed in this repository.');
     console.log('Run: npx github-delivery-os install --with-templates .');
   } else {
@@ -450,6 +601,7 @@ function runUninstall(options) {
   const targetAbs = path.resolve(process.cwd(), targetDir);
   const workflowsDest = path.join(targetAbs, '.github', 'workflows');
   const templatesDest = path.join(targetAbs, '.github', 'ISSUE_TEMPLATE');
+  const scriptsDest = path.join(targetAbs, '.github', 'scripts');
 
   console.log('=== GitHub Delivery Operating System — Uninstall ===');
   console.log(`Target: ${targetAbs}`);
@@ -458,6 +610,7 @@ function runUninstall(options) {
 
   let workflowsRemoved = 0;
   let templatesRemoved = 0;
+  let scriptsRemoved = 0;
 
   for (const wf of WORKFLOWS) {
     const dest = path.join(workflowsDest, `${wf}.yml`);
@@ -472,6 +625,34 @@ function runUninstall(options) {
     }
   }
 
+  // Scripts are a required dependency of the workflows above, not optional,
+  // so (like workflows) they're always removed, not gated behind a flag.
+  for (const name of SCRIPTS) {
+    const dest = path.join(scriptsDest, `${name}.js`);
+    if (fs.existsSync(dest)) {
+      if (dryRun) {
+        console.log(`  [dry-run] Would remove: .github/scripts/${name}.js`);
+      } else {
+        fs.unlinkSync(dest);
+        console.log(`  Removed: .github/scripts/${name}.js`);
+      }
+      scriptsRemoved++;
+    }
+  }
+
+  // The CommonJS-pinning package.json travels with SCRIPTS — same
+  // unconditional removal.
+  const scriptsPkgDest = path.join(scriptsDest, SCRIPTS_PACKAGE_JSON);
+  if (fs.existsSync(scriptsPkgDest)) {
+    if (dryRun) {
+      console.log(`  [dry-run] Would remove: .github/scripts/${SCRIPTS_PACKAGE_JSON}`);
+    } else {
+      fs.unlinkSync(scriptsPkgDest);
+      console.log(`  Removed: .github/scripts/${SCRIPTS_PACKAGE_JSON}`);
+    }
+    scriptsRemoved++;
+  }
+
   if (withTemplates) {
     for (const t of TEMPLATES) {
       const dest = path.join(templatesDest, t);
@@ -501,11 +682,27 @@ function runUninstall(options) {
     }
   }
 
-  // Remove the version manifest too — it has no meaning once Delivery OS is
-  // gone, and leaving it behind would make a later install/status think a
-  // stale version is still installed.
+  // Remove the version manifest too — but only once nothing Delivery-OS-
+  // related actually remains. Templates and the skill are kept by default
+  // (only removed with their own flags), and if they're still on disk, the
+  // manifest's version is still meaningful for them — deleting it would make
+  // a later `status` report "unknown version" for files that are, in fact,
+  // still fully present and version-tracked.
+  const anyWorkflowsRemain = WORKFLOWS.some((wf) => fs.existsSync(path.join(workflowsDest, `${wf}.yml`)));
+  const anyTemplatesRemain = TEMPLATES.some((t) => fs.existsSync(path.join(templatesDest, t)));
+  // Scripts are removed unconditionally just above, so this is normally
+  // always false by the time we get here — included anyway for the same
+  // reason the other three are checked explicitly rather than assumed:
+  // defensive completeness against a future change (e.g. a failed unlink,
+  // or script removal ever becoming flag-gated like templates/skill).
+  const anyScriptsRemain =
+    SCRIPTS.some((name) => fs.existsSync(path.join(scriptsDest, `${name}.js`))) ||
+    fs.existsSync(path.join(scriptsDest, SCRIPTS_PACKAGE_JSON));
+  const skillRemains = fs.existsSync(skillPath(targetAbs));
+  const nothingLeft = !anyWorkflowsRemain && !anyTemplatesRemain && !anyScriptsRemain && !skillRemains;
+
   const manifestDest = manifestPath(targetAbs);
-  if (fs.existsSync(manifestDest)) {
+  if (nothingLeft && fs.existsSync(manifestDest)) {
     if (dryRun) {
       console.log('  [dry-run] Would remove: delivery-os.json');
     } else {
@@ -528,6 +725,9 @@ function runUninstall(options) {
       if (!withSkill) {
         console.log('Claude Code skill (if installed) was kept. Re-run with --with-skill to remove it.');
       }
+      if (!nothingLeft) {
+        console.log('delivery-os.json was kept — something Delivery-OS-related is still on disk.');
+      }
     }
   } else {
     console.log('No Delivery OS files found to remove.');
@@ -550,5 +750,8 @@ module.exports = {
     SKILL_REL_PATH,
     WORKFLOWS,
     TEMPLATES,
+    SCRIPTS,
+    SCRIPTS_PACKAGE_JSON,
+    REQUIRED_SCRIPT_BY_WORKFLOW,
   },
 };