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 skills add https://github.com/rohitg00/skillkit --skill verification-gates
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 |
Expert database architect specializing in data layer design from scratch, technology selection, schema modeling, and scalable database architectures. Masters SQL/NoSQL/TimeSeries database selection, normalization strategies, migration planning, and performance-first design. Handles both greenfield architectures and re-architecture of existing systems. Use PROACTIVELY for database architecture, technology selection, or data modeling decisions.
>- Configures GKE Backup Plans and restore workflows. Use for backup policies, disaster recovery, or GKE cluster restores. Don't use for database backups.
Unified CloudBase execution guide for all-in-one skill installs. Use this first for CloudBase app tasks, especially existing apps with TODOs, fixed pages, or active handlers. Routes PostgreSQL / CloudBase PG / app.rdb() / queryPgDatabase / managePgDatabase work away from legacy NoSQL and old auth patterns.
Implement, review, or improve data persistence using SwiftData. Use when defining @Model classes with @Attribute, @Relationship, @Transient, #Unique, or #Index; when querying with @Query, #Predicate, FetchDescriptor, or SortDescriptor; when configuring ModelContainer and ModelContext for SwiftUI or background work with @ModelActor; when planning schema migrations with VersionedSchema and SchemaMigrationPlan; when setting up CloudKit sync with ModelConfiguration; or when coexisting with or migrating from Core Data.
Plan and run backups, set recovery objectives, and run disaster recovery drills. Use this skill when defining RPO/RTO targets, designing backup architecture, deciding what to back up and how often, planning for full-region or platform outages, or running a restoration drill. Triggers on backup, restore, RPO, RTO, disaster recovery, DR, business continuity, what if the database is gone, what if our hosting goes down, recovery drill, ransomware planning. Also triggers when an incident reveals a gap in restoration capability.
Expert database architect specializing in data layer design from scratch, technology selection, schema modeling, and scalable database architectures. Masters SQL/NoSQL/TimeSeries database selection, normalization strategies, migration planning, and performance-first design. Handles both greenfield architectures and re-architecture of existing systems. Use PROACTIVELY for database architecture, technology selection, or data modeling decisions.
> System architecture design and review. Use when designing architecture, evaluating microservices vs monolith, writing ADRs, choosing a database, planning for scalability, reviewing system design, or generating architecture diagrams.
This skill should be used whenever users ask food-related questions, meal suggestions, nutrition advice, recipe recommendations, or dietary planning. On first use, the skill collects comprehensive user preferences (allergies, dietary restrictions, goals, likes/dislikes) and stores them in a persistent database. All subsequent food-related responses are personalized based on these stored preferences.
Take rohitg00/verification-gates from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.