merge: PR #321 - feat: add distribution pipeline checks across skill workflow

Author: garrytan

office-hours/SKILL.md.tmpl

@@ -334,7 +334,8 @@ Before proposing solutions, challenge the premises:
 1. **Is this the right problem?** Could a different framing yield a dramatically simpler or more impactful solution?
 2. **What happens if we do nothing?** Real pain point or hypothetical one?
 3. **What existing code already partially solves this?** Map existing patterns, utilities, and flows that could be reused.
-4. **Startup mode only:** Synthesize the diagnostic evidence from Phase 2A. Does it support this direction? Where are the gaps?
+4. **If the deliverable is a new artifact** (CLI binary, library, package, container image, mobile app): **how will users get it?** Code without distribution is code nobody can use. The design must include a distribution channel (GitHub Releases, package manager, container registry, app store) and CI/CD pipeline — or explicitly defer it.
+5. **Startup mode only:** Synthesize the diagnostic evidence from Phase 2A. Does it support this direction? Where are the gaps?
 
 Output premises as clear statements the user must agree with before proceeding:
 ```
@@ -474,6 +475,11 @@ Supersedes: {prior filename — omit this line if first design on this branch}
 ## Success Criteria
 {measurable criteria from Phase 2A}
 
+## Distribution Plan
+{how users get the deliverable — binary download, package manager, container image, web service, etc.}
+{CI/CD pipeline for building and publishing — GitHub Actions, manual release, auto-deploy on merge?}
+{omit this section if the deliverable is a web service with existing deployment pipeline}
+
 ## Dependencies
 {blockers, prerequisites, related work}
 
@@ -526,6 +532,10 @@ Supersedes: {prior filename — omit this line if first design on this branch}
 ## Success Criteria
 {what "done" looks like}
 
+## Distribution Plan
+{how users get the deliverable — binary download, package manager, container image, web service, etc.}
+{CI/CD pipeline for building and publishing — or "existing deployment pipeline covers this"}
+
 ## Next Steps
 {concrete build tasks — what to implement first, second, third}
 

plan-eng-review/SKILL.md.tmpl

@@ -94,6 +94,12 @@ Before reviewing anything, answer these questions:
 
 5. **Completeness check:** Is the plan doing the complete version or a shortcut? With AI-assisted coding, the cost of completeness (100% test coverage, full edge case handling, complete error paths) is 10-100x cheaper than with a human team. If the plan proposes a shortcut that saves human-hours but only saves minutes with CC+gstack, recommend the complete version. Boil the lake.
 
+6. **Distribution check:** If the plan introduces a new artifact type (CLI binary, library package, container image, mobile app), does it include the build/publish pipeline? Code without distribution is code nobody can use. Check:
+   - Is there a CI/CD workflow for building and publishing the artifact?
+   - Are target platforms defined (linux/darwin/windows, amd64/arm64)?
+   - How will users download or install it (GitHub Releases, package manager, container registry)?
+   If the plan defers distribution, flag it explicitly in the "NOT in scope" section — don't let it silently drop.
+
 If the complexity check triggers (8+ files or 2+ new classes/services), proactively recommend scope reduction via AskUserQuestion — explain what's overbuilt, propose a minimal version that achieves the core goal, and ask whether to reduce or proceed as-is. If the complexity check does not trigger, present your Step 0 findings and proceed directly to Section 1.
 
 Always work through the full interactive review: one section at a time (Architecture → Code Quality → Tests → Performance) with at most 8 top issues per section.
@@ -111,6 +117,7 @@ Evaluate:
 * Security architecture (auth, data access, API boundaries).
 * Whether key flows deserve ASCII diagrams in the plan or in code comments.
 * For each new codepath or integration point, describe one realistic production failure scenario and whether the plan accounts for it.
+* **Distribution architecture:** If this introduces a new artifact (binary, package, container), how does it get built, published, and updated? Is the CI/CD pipeline part of the plan or deferred?
 
 **STOP.** For each issue found in this section, call AskUserQuestion individually. One issue per call. Present options, state your recommendation, explain WHY. Do NOT batch multiple issues into one AskUserQuestion. Only proceed to the next section after ALL issues in this section are resolved.
 

review/checklist.md

@@ -125,6 +125,18 @@ To do this: use Grep to find all references to the sibling values (e.g., grep fo
 - Small utility additions (<5KB gzipped)
 - Server-side-only dependencies
 
+#### Distribution & CI/CD Pipeline
+- CI/CD workflow changes (`.github/workflows/`): verify build tool versions match project requirements, artifact names/paths are correct, secrets use `${{ secrets.X }}` not hardcoded values
+- New artifact types (CLI binary, library, package): verify a publish/release workflow exists and targets correct platforms
+- Cross-platform builds: verify CI matrix covers all target OS/arch combinations, or documents which are untested
+- Version tag format consistency: `v1.2.3` vs `1.2.3` — must match across VERSION file, git tags, and publish scripts
+- Publish step idempotency: re-running the publish workflow should not fail (e.g., `gh release delete` before `gh release create`)
+
+**DO NOT flag:**
+- Web services with existing auto-deploy pipelines (Docker build + K8s deploy)
+- Internal tools not distributed outside the team
+- Test-only CI changes (adding test steps, not publish steps)
+
 ---
 
 ## Severity Classification
@@ -141,7 +153,8 @@ CRITICAL (highest severity):      INFORMATIONAL (lower severity):
                                    ├─ Time Window Safety
                                    ├─ Type Coercion at Boundaries
                                    ├─ View/Frontend
-                                   └─ Performance & Bundle Impact
+                                   ├─ Performance & Bundle Impact
+                                   └─ Distribution & CI/CD Pipeline
 
 All findings are actioned via Fix-First Review. Severity determines
 presentation order and classification of AUTO-FIX vs ASK — critical

ship/SKILL.md.tmpl

@@ -83,6 +83,33 @@ If the Eng Review is NOT "CLEAR":
 
 ---
 
+## Step 1.5: Distribution Pipeline Check
+
+If the diff introduces a new standalone artifact (CLI binary, library package, tool) — not a web
+service with existing deployment — verify that a distribution pipeline exists.
+
+1. Check if the diff adds a new `cmd/` directory, `main.go`, or `bin/` entry point:
+   ```bash
+   git diff origin/<base> --name-only | grep -E '(cmd/.*/main\.go|bin/|Cargo\.toml|setup\.py|package\.json)' | head -5
+   ```
+
+2. If new artifact detected, check for a release workflow:
+   ```bash
+   ls .github/workflows/ 2>/dev/null | grep -iE 'release|publish|dist'
+   ```
+
+3. **If no release pipeline exists and a new artifact was added:** Use AskUserQuestion:
+   - "This PR adds a new binary/tool but there's no CI/CD pipeline to build and publish it.
+     Users won't be able to download the artifact after merge."
+   - A) Add a release workflow now (GitHub Actions cross-platform build + GitHub Releases)
+   - B) Defer — add to TODOS.md
+   - C) Not needed — this is internal/web-only, existing deployment covers it
+
+4. **If release pipeline exists:** Continue silently.
+5. **If no new artifact detected:** Skip silently.
+
+---
+
 ## Step 2: Merge the base branch (BEFORE tests)
 
 Fetch and merge the base branch into the feature branch so tests run against the merged state: