gate-check
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.
git clone --depth 1 https://github.com/tranhieutt/software_development_department /tmp/gate-check && cp -r /tmp/gate-check/.claude/skills/gate-check ~/.claude/skills/gate-checkSKILL.md
# 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 owning team
- [ ] All automated checks and release validations are passing
- [ ] Performance, availability, and operational targets are met for the release surface
- [ ] No known critical or high-severity bugs; medium-severity items have documented accepted risk
- [ ] Accessibility basics covered for the release surface
- [ ] Localization verified for all target languages
- [ ] Legal, privacy, and security requirements are met (privacy policy, consent, licenses, terms as applicable)
- [ ] Production deployment, packaging, or publish flow completes cleanly
- [ ] Monitoring, aThe Accessibility Specialist ensures the software is accessible to the widest possible audience. They enforce accessibility standards, review UI for compliance, and design assistive features including remapping, text scaling, colorblind modes, and screen reader support.
The AI Programmer implements intelligent system features: recommendation engines, classification pipelines, LLM integrations, decision logic, and autonomous agent behavior. Use this agent for AI/ML feature implementation, model integration, intelligent automation, or AI system debugging.
The Analytics Engineer designs telemetry systems, user behavior tracking, A/B test frameworks, and data analysis pipelines. Use this agent for event tracking design, dashboard specification, A/B test design, or user behavior analysis methodology.
The Backend Developer builds and maintains server-side logic, APIs, databases, authentication, and integrations. Use this agent for REST/GraphQL API implementation, database operations, authentication systems, background jobs, microservices, server performance, and backend testing. Works from API design contracts and PRDs.
The Community Manager handles user-facing communications, feedback synthesis, support escalation, and community engagement. Use this agent for drafting release announcements, synthesizing user feedback into actionable insights, writing support documentation, or coordinating community-facing communication around releases and incidents.
The CTO (Chief Technical Officer) owns the high-level technical vision, architecture decisions, technology choices, and technical strategy. Use this agent for architecture-level decisions, technology evaluations, cross-system conflicts, and when a technical choice will constrain or enable product possibilities. This is the highest technical authority in the department.
The Data Engineer designs database schemas, builds data pipelines, manages migrations, and owns the data infrastructure. Use this agent for schema design, complex migrations, data modeling, ETL/ELT pipelines, database performance optimization, analytics infrastructure, and data integrity strategies.
The DevOps Engineer maintains build pipelines, CI/CD configuration, version control workflow, and deployment infrastructure. Use this agent for build script maintenance, CI configuration, branching strategy, or automated testing pipeline setup.