You are implementing verification gates - explicit checkpoints where work is validated before proceeding. This prevents cascading errors and ensures quality at each phase.
Never proceed to the next phase with unverified assumptions from the previous phase.
A verification gate is a deliberate pause to confirm that prerequisites are met before continuing.
Before starting design:
Actions:
Before starting implementation:
Actions:
Before calling task complete:
Actions:
Before merging:
Actions:
Before marking complete:
Actions:
Gates that can be enforced automatically:
# CI Pipeline Gates
gates:
- name: lint
command: npm run lint
required: true
- name: type-check
command: npm run typecheck
required: true
- name: unit-tests
command: npm test
required: true
coverage: 80%
- name: build
command: npm run build
required: true
Gates requiring human judgment:
## Manual Verification Checklist
Before Code Review:
- [ ] I've tested my changes locally
- [ ] I've written/updated tests
- [ ] I've read my own diff
- [ ] I've checked for security issues
- [ ] I've updated documentation
Before Deployment:
- [ ] Code review approved
- [ ] QA verified (if applicable)
- [ ] Stakeholder approved (if required)
- [ ] Deployment plan reviewed
Gates that apply in specific situations:
| Condition | Required Gates |
|---|---|
| Security-related | Security review |
| Public API change | API review + migration plan |
| Database change | DBA review + backup plan |
| Performance-sensitive | Performance test |
| Breaking change | Deprecation notice + migration |
Task Start
│
▼
┌─────────────────┐
│ Gate: Prereqs │ ← Verify before starting
│ - Requirements │
│ - Dependencies │
└────────┬────────┘
│
▼
Do the work
│
▼
┌─────────────────┐
│ Gate: Completion│ ← Verify before proceeding
│ - Tests pass │
│ - Code reviewed │
└────────┬────────┘
│
▼
Task Complete
## Gate: [Name]
**When:** [Before what action]
**Purpose:** [What this gate ensures]
**Checklist:**
- [ ] Item 1
- [ ] Item 2
- [ ] Item 3
**Verification Method:**
- [How to verify each item]
**Failure Actions:**
- [What to do if gate fails]
**Approver:** [Who can approve passage]
Good gates have high effectiveness (catch most issues), low overhead (quick to pass), and high value (prevent expensive downstream fixes). Track which gate caught an issue and how much time was spent at each gate to tune your process over time.
# GitHub Actions example
jobs:
gate-lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm ci
- run: npm run lint
gate-test:
needs: gate-lint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm ci
- run: npm test
gate-build:
needs: gate-test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm ci
- run: npm run build
deploy:
needs: gate-build
# Only deploys if all gates pass
| Phase | Gate Before | Key Checks |
|---|---|---|
| Design | Requirements | Clear, complete, approved |
| Implementation | Design | Reviewed, feasible |
| Review | Implementation | Tests, conventions, working |
| Merge | Review | Approved, conflicts resolved |
| Deploy | Merge | Environment ready, plan exists |