quality-run-quality-gates

What this skill does

# Run Quality Gates

## Purpose

Enforce Definition of Done by detecting and running all quality gates (type checking, linting, dead code detection, tests) for Python, JavaScript, Go, Rust, and other ecosystems. Provides actionable feedback for failures and blocks task completion until all gates pass.

## Table of Contents

**Quick Start** → [When to Use](#when-to-use-this-skill) | [What It Does](#what-this-skill-does) | [Simple Example](#quick-start)

**How to Implement** → [Detection Process](#quality-gate-detection) | [Execution Workflow](#execution-workflow) | [Outcomes](#expected-outcomes)

**Automation** → [Scripts](scripts/) | [Templates](templates/) | [Supporting Files](#supporting-files)

**Help** → [Anti-Patterns](#anti-pattern-prevention) | [Output Format](#output-format) | [Integration](#integration-with-existing-tools)

**Reference** → [Tool Reference](references/quality-gate-tools.md) | [Common Failures](references/common-failures.md)

---

## When to Use This Skill

**MANDATORY in these situations:**
- Before declaring a task "done" or "complete"
- Before marking a todo as completed
- Before creating a commit or pull request
- When user says "check all", "run quality gates", "validate code"
- After implementing new features or bug fixes
- After refactoring code

**User trigger phrases:**
- "run quality gates"
- "check all"
- "run tests and linting"
- "validate code quality"
- "is this done?"
- "run checks"
- "check before commit"

**Additional detection patterns:**
- After manually running individual tools (e.g., "I ran ruff check")
- When user says "I fixed linting" but hasn't run other gates
- After code changes but before marking task complete
- When only partial quality checks were performed

## What This Skill Does

Enforces the **Definition of Done** by:

1. **Detecting project type** (Python, JavaScript, TypeScript, etc.)
2. **Identifying quality gate tools** (check_all.sh script or individual tools)
3. **Running all quality gates** in parallel when possible
4. **Capturing and categorizing failures** (type errors, lint errors, dead code, test failures)
5. **Providing actionable fixes** for each failure category
6. **Re-running gates** after fixes until all pass
7. **Confirming zero errors** before declaring success

**Result:** ✅ All gates pass (task truly done) or ❌ Failures (with specific fixes needed)

## Quick Start

### Example 1: Task Completion Check

```
User: "I'm done implementing the new feature"

Claude invokes skill:
→ Detects Python project with check_all.sh
→ Runs: ./scripts/check_all.sh
→ Reports results

Output:
✅ All 6 checks passed (pyright, vulture, pytest, ruff, ruff format, ty)
✅ DEFINITION OF DONE: MET
Task is complete and ready for commit.
```

### Example 2: Failures Detected

```
User: "Run quality gates"

Claude invokes skill:
→ Runs quality gates
→ Detects 3 failures

Output:
❌ 3 of 6 checks failed: pyright, pytest, ruff

📋 pyright failures (3 errors):
  src/services/search.py:45 - Type "None" cannot be assigned to "str"
  src/utils/helper.py:12 - Argument of type "int" cannot be assigned to "Optional[str]"

📋 pytest failures (2 errors):
  tests/unit/test_search.py::test_search_empty - AssertionError

📋 ruff failures (1 error):
  src/services/search.py:23 - F401 Unused import: logging

Next steps:
1. Fix type errors (make parameters non-optional)
2. Fix test assertions
3. Remove unused imports
4. Re-run quality gates

❌ DEFINITION OF DONE: NOT MET
Task is NOT complete until all gates pass.
```

## Instructions

### Overview

Running quality gates involves 5 key steps:

1. **Detect project type and tools** - Identify language and available quality gate tools
2. **Run quality gates** - Execute all gates (unified script or individual tools)
3. **Parse results** - Categorize failures by type (type errors, lint, tests, dead code)
4. **Provide actionable fixes** - Generate specific fix recommendations for each failure
5. **Re-run after fixes** - Validate that all issues are resolved

See detailed workflow in [Execution Workflow](#execution-workflow) section below.

## Quality Gate Detection

### Detection Process

1. **Check for unified script** (preferred):
   - `./scripts/check_all.sh` (Python projects)
   - `npm run check` (JavaScript/TypeScript projects)
   - `make check` (Makefile-based projects)

2. **Fallback to individual tools** by detecting project type:

#### Python Projects
Detect via: `pyproject.toml`, `requirements.txt`, `setup.py`

Tools to run:
- **Type checking:** `uv run pyright` or `mypy`
- **Linting:** `uv run ruff check` or `pylint` or `flake8`
- **Dead code:** `uv run vulture src/ --min-confidence 80`
- **Tests:** `uv run pytest tests/ -q`
- **Formatting:** `uv run ruff format --check` or `black --check`

#### JavaScript/TypeScript Projects
Detect via: `package.json`, `tsconfig.json`

Tools to run:
- **Type checking:** `npx tsc --noEmit`
- **Linting:** `npx eslint src/`
- **Tests:** `npm test` or `npx jest` or `npx vitest`
- **Formatting:** `npx prettier --check src/`

#### Go Projects
Detect via: `go.mod`

Tools to run:
- **Type checking:** `go build ./...`
- **Linting:** `golangci-lint run`
- **Tests:** `go test ./...`
- **Formatting:** `go fmt ./...`

#### Rust Projects
Detect via: `Cargo.toml`

Tools to run:
- **Type checking:** `cargo check`
- **Linting:** `cargo clippy`
- **Tests:** `cargo test`
- **Formatting:** `cargo fmt --check`

### Project-Specific Configuration

Read project-specific quality gates from:
- `CLAUDE.md` (Definition of Done section)
- `pyproject.toml` (Python)
- `package.json` (JavaScript/TypeScript)
- `.pre-commit-config.yaml` (Pre-commit hooks)

## Execution Workflow

### Step 1: Detect Project and Tools

```bash
# Check for unified script
if [ -f ./scripts/check_all.sh ]; then
    RUNNER="./scripts/check_all.sh"
elif [ -f package.json ] && grep -q '"check"' package.json; then
    RUNNER="npm run check"
elif [ -f Makefile ] && grep -q "^check:" Makefile; then
    RUNNER="make check"
else
    # Fallback to individual tools (detect project type)
    ...
fi
```

### Step 2: Run Quality Gates

```bash
# Run unified script or individual tools
$RUNNER

# Capture output and exit code
EXIT_CODE=$?
```

### Step 3: Parse and Categorize Failures

Extract failures by tool:
- **Type errors:** Lines matching `error:` or `error[`
- **Lint errors:** Lines matching `.py:line:col:` or `.js:line:col:`
- **Dead code:** Lines matching `unused` or `dead code`
- **Test failures:** Lines matching `FAILED` or `ERROR collecting`

### Step 4: Provide Actionable Fixes

For each failure category, provide:
1. **File:line reference** (exact location)
2. **Error description** (what's wrong)
3. **Suggested fix** (how to resolve)
4. **Priority** (HIGH/MEDIUM/LOW based on error type)

### Step 5: Re-run After Fixes

After user applies fixes:
```bash
# Re-run quality gates
$RUNNER

# Verify all pass
if [ $? -eq 0 ]; then
    echo "✅ All quality gates passed"
    echo "✅ DEFINITION OF DONE: MET"
else
    echo "❌ Some gates still failing"
    # Repeat steps 3-4
fi
```

## Anti-Pattern Prevention

### ❌ Anti-Pattern 1: Declaring Done Without Running Gates

**User:** "I'm done with the feature"

**Wrong Response:**
```
✅ Great! The feature is complete.
```

**Correct Response (Invoke Skill):**
```
Let me verify the feature meets Definition of Done by running quality gates...

→ Runs quality gates
→ Reports results (pass/fail)
→ Only declares "done" if all gates pass
```

### ❌ Anti-Pattern 2: Ignoring Quality Gate Failures

**User:** "Some tests are failing but the main logic works"

**Wrong Response:**
```
✅ The core functionality is complete. The test failures are minor.
```

**Correct Response:**
```
❌ DEFINITION OF DONE: NOT MET

Quality gates must pass before declaring done:
- 2 tests failing in tests/unit/test_search.py
- 1 type error in src/services/search.py

Let me fix these issues...
[Proceeds to fix each failure]
```

### ❌ Anti-Pattern 3: "Will Fix Later" Mentality

**User:** "L