# Sdlc Phase Gate

> SDLC Phase Gate

- Skill: `sethdford/sdlc-phase-gate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/sdlc-phase-gate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/sdlc-phase-gate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/sdlc-phase-gate

---

# SDLC Phase Gate

Validates that work meets criteria before moving between SDLC phases. Implements gates for: Requirements → Design → Implementation → Testing → Deployment → Operations.

## Domain Context

Software lifecycle is a series of phases, each with distinct concerns and responsibilities:

| Phase          | Primary Role         | Key Questions                                         |
| -------------- | -------------------- | ----------------------------------------------------- |
| Requirements   | Product Manager      | What problem are we solving? Is it worth solving?     |
| Design         | Architect            | How will we solve it? What are the risks?             |
| Implementation | Engineer             | Can we actually build this?                           |
| Testing        | QA                   | Does it work as designed?                             |
| Deployment     | Tech Lead / Engineer | Is the rollout safe? Can we roll back?                |
| Operations     | Tech Lead            | Is it stable in production? Can we respond to issues? |

A phase gate ensures that before moving to the next phase, the current phase is sufficiently complete and the next phase has what it needs.

Phase gates are **guardrails**, not bureaucratic checkpoints. They catch misalignment early, when changes are cheap.

**ISO/IEC 12207 Reference:**

- 5.2.1 Stakeholder Needs and Requirements Definition
- 5.3.1 System Requirements Analysis
- 5.3.3 Architectural Design
- 5.3.4 Detailed Design
- 5.3.5 Implementation
- 5.3.6 Integration
- 5.3.7 Verification
- 5.3.8 Transition
- 5.3.9 Operation and Maintenance

## Instructions

### Step 1: Identify Current Phase and Work Item

- **Input**: Work item (feature, task, epic, release)
- **Ask**: What phase is this in? (Requirements, Design, Implementation, Testing, Deployment, Operations)
- **Ask**: What's the scope? (feature, bug fix, infrastructure, tech debt)

### Step 2: Validate Current Phase Completion

For **Requirements → Design Gate**:

- Is the problem statement clear and agreed by all stakeholders?
- Is the success metric defined and measurable?
- Have edge cases and failure modes been identified?
- Has the security threat landscape been scoped?
- Is the scope bounded (no hidden assumptions)?

Output: Requirements completeness checklist

For **Design → Implementation Gate**:

- Has the system architecture been decomposed into components?
- Have trade-offs been explicitly documented (performance vs. complexity, flexibility vs. cost)?
- Has the security architecture been threat-modeled (STRIDE or equivalent)?
- Have dependency risks been identified (external services, rate limits, SLAs)?
- Has the accessibility design been reviewed?
- Is the design reviewable and approved by architect and security?

Output: Design completeness checklist

For **Implementation → Testing Gate**:

- Is the code complete for the feature (or slice)?
- Does the code follow team conventions and pass static analysis?
- Have unit tests been written and pass?
- Has the test strategy been defined (what will QA validate)?
- Are deployment rollback procedures documented?
- Have performance baselines been captured?

Output: Implementation readiness checklist

For **Testing → Deployment Gate**:

- Have all test scenarios passed (happy path, edge cases, error cases)?
- Has the test coverage met the team's threshold?
- Have security scans passed (SAST, dependency audit, secrets scan)?
- Have accessibility tests passed (WCAG, screen reader, keyboard navigation)?
- Have performance benchmarks met targets?
- Is the rollback procedure tested and documented?

Output: Testing completeness checklist

For **Deployment → Operations Gate**:

- Is the deployment plan approved by tech lead and ops?
- Is the rollout strategy clear (blue-green, canary, gradual)?
- Are monitoring and alerting configured?
- Is the runbook written (how to debug in production)?
- Have team members been trained on the feature?
- Is the incident response plan ready?

Output: Deployment readiness checklist

For **Operations → Closure Gate**:

- Is the feature stable in production (no critical alerts)?
- Are the monitoring metrics showing expected behavior?
- Have incident reports been reviewed and closed?
- Are there improvement items from operations feedback?
- Can the team move on to the next feature?

Output: Operations closure checklist

### Step 3: Identify Blocking Issues

For each failed criterion:

- **What's missing?** (artifact, approval, test, documentation)
- **Who owns fixing it?** (architect, engineer, PM, security, QA, designer)
- **How long to fix?** (estimate in hours)
- **Does it block the phase transition?** (blocking, warning, informational)

Output: Blocking issues list with owners and estimates

### Step 4: Make the Gate Decision

**Go Decision:**

- All blocking criteria are satisfied
- No critical risks remain unmitigated
- Next phase team has what it needs to succeed
- Document: "Gate approved, ready to transition"

**Conditional Go Decision:**

- Critical criteria are satisfied
- Non-critical criteria have acceptable workarounds
- Risk is documented and accepted
- Document: "Gate approved with accepted risks: [list]"

**No-Go Decision:**

- Critical criteria are not satisfied
- Risks cannot be mitigated in the next phase
- Recommend: Fix the issue in current phase
- Document: "Gate blocked. Required fixes: [list]. Re-evaluate in [timeframe]"

### Step 5: Communicate the Decision

- **To Current Phase Team**: "Gate decision is [go/conditional/no-go]. [Issues to fix]. [Next steps]."
- **To Next Phase Team**: "You're cleared to proceed. Here's what you're inheriting: [scope, risks, dependencies]."
- **To Leadership**: "Feature [X] is [on track / at risk] for [target date]. Blocker: [if any]."

## Anti-Patterns

1. **Using phase gates to rubber-stamp completion**
   - Mistake: "All checkboxes are checked, so the gate passes automatically"
   - Correct: Checklists inform the decision, but the decision is a judgment call
   - Fix: Require explicit human sign-off for go/no-go decisions

2. **Making gates too early in the phase**
   - Mistake: "Let's do the testing gate after the first sprint of development"
   - Correct: Gates should be at natural phase boundaries, when work is substantially complete
   - Fix: Define phase boundaries clearly; gate when "done" is achievable

3. **Skipping gates because "we're fast"**
   - Mistake: "Agile teams don't need phase gates, we ship continuously"
   - Correct: Continuous delivery still needs guardrails; gates work at sprint granularity
   - Fix: Apply phase gates to features or epics, not individual PRs

4. **Treating gates as single-role decisions**
   - Mistake: "The architect decides if design is complete"
   - Correct: Design completeness requires architect + security + engineer input
   - Fix: Make gates cross-functional; require sign-off from the role entering the phase

5. **Not capturing risk and context**
   - Mistake: "Gate passed, move on" (without documenting assumptions or risks)
   - Correct: Gate decisions should capture trade-offs and accepted risks
   - Fix: Always document: "This decision assumes [X]. If [Y] changes, re-evaluate."

6. **Gates that are too strict**
   - Mistake: "100% test coverage required; gates don't pass without it"
   - Correct: Thresholds should be evidence-based, not arbitrary
   - Fix: Define thresholds based on team data (velocity, defect rates, severity)

## Further Reading

- **ISO/IEC 12207** — Software lifecycle processes (Section 5.2, Process implementation)
- **Stage-Gate Process** — Cooper, R. G., "Winning at New Products" (Harvard Business Review Press)
- **Lean Phase Gates** — Reinertsen, D., "The Principles of Product Development Flow" (Celeritas Publishing)
- **Risk Management in Phase Gates** — PMI, "Project Management Institute Body of Knowledge" (PMBOK)