quality-gates

Run project verification commands and report exit codes after code changes.

2|Updated Apr 10, 2026
One-click install
npx skills add https://github.com/t0lab/harness-kit --skill quality-gates-t0lab
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: quality-gates
Source: https://github.com/t0lab/harness-kit/tree/main/.agents/skills/quality-gates
Command: npx skills add https://github.com/t0lab/harness-kit --skill quality-gates-t0lab

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents premature completion claims by requiring fresh, executable evidence that changes behave as intended rather than relying on optimism, stale logs, or superficial inspection.

Core Features & Use Cases

  • Fresh verification rule: Mandates running the commands that prove the claim after the last edit and reading their actual output.
  • Targeted guidance: Helps choose the minimal honest verification set based on change type (tests for bug fixes, build/typecheck for API changes, lint for style).
  • Use case: Before marking a PR ready, run the project's verification commands covering touched files and report passing results or residual risk.

Quick Start

Run the project's appropriate verification commands for the changed files and report the fresh pass or fail evidence before declaring the work complete.

Frequently Asked Questions about quality-gates

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce running tests and lint before marking a pull request as done?

To enforce verification before marking a pull request done, you mandate running the project's appropriate tests, lint, or typecheck commands after the last code edit and reading their actual output as evidence.

What is a quality gate in CI for verifying code changes?

A quality gate for code changes is a rule requiring fresh execution of verification commands like tests, builds, or lint, ensuring that completion claims are backed by actual passing exit codes rather than stale logs.

How do I choose the right verification commands for different types of code changes?

Choosing the right verification commands involves selecting the minimal honest set based on change type: tests for bug fixes, build and typecheck for API changes, and lint for style modifications.

Can I use automated code review to require fresh test execution for modified files?

Automated code review can require fresh test execution by enforcing a rule that mandates running verification commands covering touched files and reporting passing results or residual risk before declaring work complete.

What should I report after running typecheck and lint commands for a PR handoff?

After running typecheck and lint commands for a PR handoff, you should report the fresh passing or failing evidence, including exit codes, failure counts, and any remaining risk to prove the changes behave as intended.

Why does claiming a task is done without fresh verification cause integration issues?

Claiming a task is done without fresh verification causes integration issues because it relies on optimism or stale logs, bypassing the executable proof from tests or builds that changes actually behave as intended.