// Establish workflow boundary checklists with clear pass/fail criteria and escalation procedures
| name | Creating Quality Gates |
| description | Establish workflow boundary checklists with clear pass/fail criteria and escalation procedures |
| when_to_use | when creating pre-merge checklists, establishing workflow boundaries, building verification procedures, or defining quality gates between development phases |
| version | 1.0.0 |
Create structured quality gates at workflow boundaries with clear "Must Pass" vs "Should Review" criteria, exact commands, and escalation procedures.
Announce at start: "I'm using the creating-quality-gates skill to establish this quality gate."
Wrong: Vague criteria ("ensure quality", "review code") Right: Explicit criteria with commands and pass/fail definitions
Quality gates must be:
Determine where the gate belongs:
| Boundary | Purpose | Example Gate |
|---|---|---|
| Before merge | Code quality | Pre-merge checklist |
| Before deploy | Production readiness | Deploy checklist |
| After design | Implementation readiness | Design review gate |
| After implement | Test readiness | Implementation complete gate |
Brainstorm everything that should be verified:
Separate into two categories:
Must Pass (Automated)
Should Review (Manual)
For each check, provide:
### [Check Name]
- [ ] **[What to verify]**
```bash
[exact command to run]
Expected: [what success looks like]
If fails: [what to do]
Be specific:
- ❌ "Run tests"
- ✅ "Run unit tests: `cargo test --lib` - Expected: All tests pass (0 failures)"
### Step 5: Document Failure Procedures
For automated checks:
```markdown
### If Automated Checks Fail
**STOP. Do not proceed.**
1. Read the error message carefully
2. Check if recent commit caused failure
3. Fix the issue (don't work around)
4. Re-run full check suite
5. If stuck > 30 minutes, ask for help
For manual checks:
### If Manual Review Has Issues
| Severity | Action |
|----------|--------|
| Blocking | Must fix before proceeding |
| Non-blocking | Create follow-up task |
| Discussion | Flag for team review |
Prerequisites - What must be true before starting:
Sign-Off - How to record completion:
Verify the gate is usable:
Add gate to workflow documentation:
# [Workflow Stage] Verification Checklist
**Purpose:** [What this validates]
**When:** [At what point]
## Prerequisites
- [ ] [What must be true first]
## Automated Checks (MUST PASS)
### [Category]
- [ ] **[Check]**
```bash
[command]
Expected: [success criteria]
[Procedures]
| Category | Status | Notes |
|---|---|---|
| Automated | ✅/❌ | |
| Manual | ✅/⚠️ |
**Use template:** `${CLAUDE_PLUGIN_ROOT}templates/verification-checklist-template.md`
## Anti-Patterns
**Don't:**
- Use vague criteria ("ensure quality")
- Skip the failure procedures
- Mix Must Pass with Should Review
- Make gates so long they get skipped
- Forget to test commands work
**Do:**
- Provide exact commands
- Separate blocking from advisory
- Keep gates focused and timely
- Update when processes change
- Automate what can be automated
## Example: Pre-Merge Gate
```markdown
# Pre-Merge Checklist
## Prerequisites
- [ ] All changes committed
- [ ] Branch rebased on main
## Automated Checks (MUST PASS)
### Tests
- [ ] **Unit tests**
```bash
cargo test --lib
Expected: 0 failures
cargo nextest run
cargo clippy -- -D warnings
STOP. Fix issues. Re-run all checks.
## Related Skills
- **Organizing documentation:** `${CLAUDE_PLUGIN_ROOT}skills/organizing-documentation/SKILL.md`
- **Creating research packages:** `${CLAUDE_PLUGIN_ROOT}skills/creating-research-packages/SKILL.md`
- **Documenting debugging workflows:** `${CLAUDE_PLUGIN_ROOT}skills/documenting-debugging-workflows/SKILL.md`
## References
- Standards: `${CLAUDE_PLUGIN_ROOT}standards/documentation-structure.md`
- Template: `${CLAUDE_PLUGIN_ROOT}templates/verification-checklist-template.md`
Use boolean decision trees instead of imperatives for 100% compliance under pressure
Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes
Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches cipherpowers:code-review-agent subagent to review implementation against plan or requirements before proceeding
Use when you've developed a broadly useful skill and want to contribute it upstream via pull request - guides process of branching, committing, pushing, and creating PR to contribute skills back to upstream repository
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
Safe refactoring workflow for replacing old types with new type-safe implementations through integration-test-first, file-by-file migration with incremental verification