Skill: Verification Gate

Purpose

Define and enforce minimum verification gates that must pass before a feature may advance between workflow phases.

This skill ensures the system is:

• •runnable
• •integrable
• •minimally validated before proceeding to product validation or “done”.

It does NOT replace QA or comprehensive testing.

Trigger

Use this skill whenever ANY of the following occur:

• •implementation for a feature is declared “complete”
• •a feature attempts to move from Implementation → Verification
• •a feature attempts to move from Verification → Product validation
• •a significant integration slice is completed
• •uncertainty exists about whether work is safe to advance

Authoritative references

This skill treats the following as authoritative:

• •docs/team/WORKFLOW.md → defines when verification is required
• •docs/team/HANDOFF.md → records verification state and blockers
• •feature artifacts under docs/features/<feature-slug>/

Inputs

• •feature implementation artifacts
• •integration slice outcomes
• •available test commands or checks
• •build/run instructions
• •environment assumptions (local, CI, etc.)

Outputs

This skill MUST produce all of the following:

1. •

   Verification record

   • •written to the feature’s verification or QA artifact
     (e.g. docs/features/<feature-slug>/04-qa-report.md or a Verification section in implementation notes)
   • •includes:
     • •what was verified
     • •how it was verified
     • •pass/fail status
     • •known limitations or gaps
2. •

   HANDOFF update

   • •verification status: pending | passed | failed
   • •blockers if verification failed
   • •owner for remediation

Minimum verification expectations

Verification MUST establish, at minimum, that:

• •the backend starts without runtime errors
• •the frontend starts and renders relevant flows
• •the integrated feature path works for the happy path
• •authentication/authorization behaves as expected (if applicable)
• •no obvious contract mismatches exist

These are baseline safety checks, not exhaustive tests.

Verification rules (strict)

• •Verification MUST be evidence-based; “looks good” is insufficient.
• •Verification MUST reference concrete actions (commands run, flows exercised).
• •Verification failures MUST block advancement.
• •Partial verification MUST be explicitly documented.
• •Deferred verification MUST be intentional and visible.

Skipping verification is prohibited.

Explicit non-responsibilities

This skill MUST NOT:

• •write automated tests
• •define test strategy or coverage targets
• •judge product value or usability
• •approve features as “done”
• •optimize performance or reliability

It enforces readiness, not completeness.

Interaction with other skills

This skill works in coordination with:

• •

  integration-slice-orchestration → verifies each slice before advancing

• •

  workflow-enforcement → blocks phase advancement when verification is incomplete

• •

  handoff-coordination → records verification state and ownership

• •

  bug-management → logs defects discovered during verification

• •

  bug-phase-classification → classifies detected and injected phases

This skill does not replace any of them.

Failure handling

If verification fails:

1. •Record failure details in the verification artifact
2. •Update HANDOFF with:
   • •failure status
   • •blocking reason
   • •owning role
3. •Log a bug if a defect is discovered
4. •Stop progression until resolved

Workarounds or silent failures are not allowed.

Acceptance criteria

This skill is successful when:

• •unsafe or broken features are blocked early
• •integration issues surface before product validation
• •verification evidence is visible and auditable
• •late-stage surprises decrease over time
• •verification failures trend toward earlier phases

Design principle

This skill exists to ensure nothing moves forward on hope.

If advancement relies on assumptions instead of evidence, the verification gate has failed.