/gate-check

name: gate-check
type: workflow
description: "Validates a software product, service, or feature against readiness gates before advancing to the next delivery phase. Use when planning a phase transition or when the user mentions gate check, phase review, or readiness validation."
argument-hint: "[target-phase: systems-design | technical-setup | pre-production | production | polish | release]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Bash, Write
effort: 3
when_to_use: "When validating software delivery readiness to advance to the next development phase"

Phase Gate Validation

This skill validates whether the software project is ready to advance to the next delivery phase. It checks for required artifacts, quality standards, and operational blockers.

**Distinct from `/project-stage-detect`**: That skill is diagnostic ("where are we?"). This skill is prescriptive ("are we ready to advance?" with a formal verdict).

Production Stages (7)

The project progresses through these stages:

1. **Concept** - Problem framing, product concept document 2. **Systems Design** - Requirements, workflows, architecture boundaries 3. **Technical Setup** - Stack selection, CI/CD, environments, architecture decisions 4. **Pre-Production** - Spikes, prototypes, acceptance criteria, delivery planning 5. **Production** - Feature development and integration work 6. **Polish** - Stabilization, QA hardening, performance, operational readiness 7. **Release** - Go-live prep, support readiness, rollback and communication planning

**When a gate passes**, write the new stage name to `production/stage.txt` (single line, e.g. `Production`). This updates the status line immediately.

---

1. Parse Arguments

• **With argument**: `/gate-check production` - validate readiness for that specific phase
• **No argument**: Auto-detect current stage using the same heuristics as

`/project-stage-detect`, then validate the NEXT phase transition

---

2. Phase Gate Definitions

Gate: Concept -> Systems Design

**Required Artifacts:**

• [ ] `design/docs/product-concept.md` exists and has content
• [ ] Product pillars defined (in concept doc or `design/docs/product-pillars.md`)
• [ ] Success metrics or launch goals captured in the concept or PRD seed notes

**Quality Checks:**

• [ ] Product concept has been reviewed (`/design-review` verdict not MAJOR REVISION NEEDED)
• [ ] Primary user workflow or business outcome is described and understood
• [ ] Target audience and problem statement are identified

---

Gate: Systems Design -> Technical Setup

**Required Artifacts:**

• [ ] Systems index exists at `design/docs/systems-index.md` with at least MVP systems enumerated
• [ ] At least 1 PRD in `design/docs/` (beyond product-concept.md and systems-index.md)

**Quality Checks:**

• [ ] PRD(s) pass design review (8 required sections present)
• [ ] System dependencies are mapped in the systems index
• [ ] MVP priority tier is defined
• [ ] Non-functional requirements are captured where relevant (performance, security, reliability, compliance)

---

Gate: Technical Setup -> Pre-Production

**Required Artifacts:**

• [ ] Stack chosen (CLAUDE.md Technology Stack is not `[CHOOSE]`)
• [ ] Technical preferences configured (`.claude/docs/technical-preferences.md` populated)
• [ ] At least 1 Architecture Decision Record in `docs/architecture/`
• [ ] CI/CD workflow, build script, or release automation exists
• [ ] Environment strategy documented (dev/staging/prod, secrets handling, deployment path)

**Quality Checks:**

• [ ] Architecture decisions cover core domains, data flow, integrations, and deployment concerns
• [ ] Technical preferences have naming conventions and performance budgets set
• [ ] Operational ownership is clear for build, deploy, and rollback paths

---

Gate: Pre-Production -> Production

**Required Artifacts:**

• [ ] At least 1 prototype, spike, or technical validation artifact exists with notes or a README
• [ ] First sprint plan exists in `production/sprints/`
• [ ] All MVP-tier PRDs from systems index are complete
• [ ] Initial delivery scope is defined for the first release or milestone

**Quality Checks:**

• [ ] Prototype or spike validates the riskiest technical assumption or critical user workflow
• [ ] Sprint plan references real work items from PRDs
• [ ] Acceptance criteria and release scope are defined
• [ ] Dependencies and sequencing risks are identified

---

Gate: Production -> Polish

**Required Artifacts:**

• [ ] `src/` has active code organized into subsystems
• [ ] All core workflows from PRD are implemented (cross-reference `design/docs/` with `src/`)
• [ ] Main user journey works end-to-end in a dev or staging environment
• [ ] Test files exist in `tests/`
• [ ] Deployment or release scripts exist
• [ ] QA/UAT evidence exists (test summary, checklist, sign-off notes, or release candidate results)

**Quality Checks:**

• [ ] Tests are passing (run test suite via `Bash`)
• [ ] No critical/blocker bugs in any bug tracker or known issues
• [ ] Critical acceptance criteria are satisfied (compare to PRD acceptance criteria)
• [ ] Performance and reliability are within target budgets (check technical-preferences.md targets)
• [ ] Logs, metrics, and error reporting exist for critical paths

---

Gate: Polish -> Release

**Required Artifacts:**

• [ ] All features from the milestone plan are implemented or explicitly deferred
• [ ] Environment variables, secrets, and feature flags are audited for release
• [ ] Localization strings are externalized (no hardcoded user-facing text in `src/`)
• [ ] QA test plan exists
• [ ] Release checklist completed (`/release-checklist` or `/launch-checklist` run)
• [ ] Deployment and rollback runbook exists
• [ ] Customer-facing release artifacts are prepared (release notes, support notes, status-page/internal comms as applicable)
• [ ] Changelog / patch notes drafted

**Quality Checks:**

• [ ] Full QA or UAT pass signed off by the ow