packages/core/src/methodology/packs/planning/verification-gates/SKILL.md
Creates explicit validation checkpoints (verification gates) between project phases to catch errors early and ensure quality before proceeding. Use when the user asks about quality gates, milestone checks, phase transitions, approval steps, go/no-go decision points, or preventing cascading errors across a multi-step workflow. Produces acceptance criteria checklists, automated CI gate configurations, manual sign-off requirements, and conditional review rules for scenarios such as security changes, API changes, or database migrations.
npx skillsauth add rohitg00/skillkit verification-gatesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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 |
tools
Discovers, searches, and installs skills from multiple AI agent skill marketplaces (400K+ skills) using the SkillKit CLI. Supports browsing official partner collections (Anthropic, Vercel, Supabase, Stripe, and more) and community repositories, searching by domain or technology, and installing specific skills from GitHub. Use when the user wants to find, browse, or install new agent skills, plugins, extensions, or add-ons; asks 'is there a skill for X' or 'find a skill for X'; wants to explore a skill store or marketplace; needs to extend agent capabilities in areas like React, testing, DevOps, security, or APIs; or says 'browse skills', 'search skill marketplace', 'install a skill', or 'what skills are available'.
development
Applies proven testing patterns — Arrange-Act-Assert (AAA), Given-When-Then, Test Data Builders, Object Mother, parameterized tests, fixtures, spies, and test doubles — to help write maintainable, reliable, and readable test suites. Use when the user asks about writing unit tests, integration tests, or end-to-end tests; structuring test cases or test suites; applying TDD or BDD practices; working with mocks, stubs, spies, or fakes; improving test coverage or reducing flakiness; or needs guidance on test organization, naming conventions, or assertions in frameworks like Jest, Vitest, pytest, or similar.
development
Guides the red-green-refactor TDD workflow: write a failing test first, implement the minimum code to make it pass, then refactor while keeping tests green. Use when a user asks to practice TDD, write tests first, follow red-green-refactor, do test-driven development, write failing tests before code, or phrases like 'make the test pass', 'test coverage', or 'unit tests before implementation'.
development
Reviews test code to identify and fix common testing anti-patterns including flaky tests, over-mocking, brittle assertions, test interdependency, and hidden test logic. Flags bad patterns, explains the specific defect, and provides corrected implementations. Use when reviewing test code, debugging intermittent or unreliable test failures, or when the user mentions flaky tests, test smells, brittle tests, test isolation issues, mock overuse, slow tests, or test maintenance problems.