---
name: quality-gates
description: Adaptive quality gates based on project type. Configures which validation steps the ticket-implementation workflow enforces depending on whether the project is a prototype, internal tool, production system, or shared library.
---

# Quality Gates Skill

**Version**: 1.0.0
**Category**: Development Workflow
**Type**: Configuration + Shell Script

## Purpose

Not every project needs the same level of process. A weekend prototype should not require security scans and formal reviews, while a production API absolutely should. This skill provides a configuration layer that the ticket-implementation agent reads to decide which of its 16 steps to enforce versus skip.

The quality gates system does not modify the ticket-implementation agent. It stores a profile in `.artifex/config.json` that the agent consults at runtime.

## Project Profiles

### prototype
**Use when**: Hackathons, spikes, throwaway experiments, proof-of-concepts.
**Gates enabled**: lint
**Gates skipped**: test, review, security_scan, docs_check, api_compat
**Rationale**: Move fast. Lint catches syntax errors and obvious issues. Everything else slows down exploration.

### internal
**Use when**: Internal tools, admin dashboards, team utilities, automation scripts.
**Gates enabled**: lint, test
**Gates skipped**: review, security_scan, docs_check, api_compat
**Rationale**: Internal tools need basic correctness (tests catch regressions) but don't need formal review or security audits.

### production
**Use when**: Customer-facing applications, APIs with external consumers, anything deployed to production.
**Gates enabled**: lint, test, review, security_scan
**Gates skipped**: docs_check, api_compat
**Rationale**: Full quality treatment. Lint, tests, self-review, and security scanning before every commit.

### library
**Use when**: Shared libraries, SDKs, packages consumed by other projects, open-source modules.
**Gates enabled**: lint, test, review, security_scan, docs_check, api_compat
**Gates skipped**: (none)
**Rationale**: Libraries have downstream consumers. Breaking changes, missing docs, or security issues cascade to every project that depends on you.

## Quality Gate Definitions

Each gate maps to specific steps in the 16-step ticket-implementation workflow:

| Gate | Workflow Step | What It Checks |
|------|--------------|----------------|
| `lint` | Step 10 (Run Tests and Verify) | Linter passes with no errors or warnings |
| `test` | Steps 9-10 (Write/Run Tests) | Tests written for acceptance criteria, all tests pass |
| `review` | Step 12 (Review Changes) | Self-review of diff for debugging code, unintended changes, code quality |
| `security_scan` | Step 12 (Review Changes) | No hardcoded secrets, no known vulnerable patterns, no unsafe operations |
| `docs_check` | Step 11 (Update Documentation) | Documentation updated to reflect changes, IMPLEMENTATION_LOG.md entry |
| `api_compat` | New check for library projects | Public API surface unchanged or explicitly versioned, no breaking changes |

### Gate Details

**lint** -- Always runs. Detects the project's linter from configuration files (eslint, ruff, clippy, golangci-lint, etc.) and runs it. If no linter is configured, this gate passes with a warning.

**test** -- Runs the project's test suite. Requires tests to exist for each acceptance criterion in the ticket. Uses the test command detected from package.json, pyproject.toml, Cargo.toml, or equivalent.

**review** -- Self-review via `git diff`. Checks for: console.log/print statements, commented-out code, TODO markers, files changed outside the ticket scope. For production and library profiles, also checks for proper error handling.

**security_scan** -- Scans the diff for: hardcoded API keys, tokens, or passwords; use of eval() or equivalent unsafe patterns; known vulnerable dependency patterns; SQL injection risks; path traversal vulnerabilities. This is a best-effort static check, not a replacement for dedicated security tools.

**docs_check** -- Verifies that IMPLEMENTATION_LOG.md has an entry for this ticket. For library projects, also checks that README or API docs are updated if public interfaces changed.

**api_compat** -- Library-only gate. Checks that exported functions, types, and interfaces have not changed in breaking ways. Compares the current public API surface against the previous commit. Flags removals, signature changes, and type changes as potential breaking changes.

## Configuration File

The quality gates configuration lives at `.artifex/config.json` in the project root:

```json
{
  "project_type": "production",
  "quality_gates": {
    "lint": true,
    "test": true,
    "review": true,
    "security_scan": true,
    "docs_check": false,
    "api_compat": false
  },
  "overrides": {}
}
```

### Fields

- **project_type**: The active profile name (prototype, internal, production, library)
- **quality_gates**: Boolean map of each gate. `true` means enforced, `false` means skipped.
- **overrides**: Per-ticket overrides. Keys are ticket IDs, values are gate maps. Example:
  ```json
  {
    "overrides": {
      "3.2": {
        "security_scan": true,
        "test": false
      }
    }
  }
  ```

## Integration with Ticket-Implementation Workflow

The ticket-implementation agent should consult `.artifex/config.json` at the start of each ticket to determine which gates to enforce. The logic is:

1. Read `.artifex/config.json`
2. Get the base gates from `quality_gates`
3. Check if `overrides` has an entry for the current ticket ID
4. Merge: ticket overrides take precedence over profile defaults
5. Use the resulting gate map to decide which steps to enforce vs. skip

### Step Behavior When Gates Are Disabled

| Gate Disabled | Effect on Workflow |
|--------------|-------------------|
| `lint` off | Step 10 skips linter (still runs tests if test gate is on) |
| `test` off | Steps 9-10 are skipped entirely (no test writing, no test running) |
| `review` off | Step 12 is reduced to a quick `git diff` scan for debugging code only |
| `security_scan` off | Step 12 skips the security-focused checks |
| `docs_check` off | Step 11 only creates minimal IMPLEMENTATION_LOG entry |
| `api_compat` off | No API compatibility check is performed |

## Per-Ticket Overrides

Sometimes a specific ticket needs different gates than the project profile. For example, a "production" project might have a ticket for an experimental feature that should use prototype-level gates, or a "prototype" project might have one critical ticket that needs security scanning.

### Via Technical Notes

When a ticket's technical notes contain quality gate directives, the agent should honor them:

```
Technical Notes:
  - quality-gates: security_scan=on, test=off
```

The agent parses these directives and applies them as overrides for that ticket only.

### Via the Override Command

```bash
quality-gates.sh set-override <ticket_id> <gate> <on|off>
```

This writes the override to `.artifex/config.json` under the `overrides` key.

## /afx-quality-gates Command

The `/afx-quality-gates` slash command provides a conversational interface:

**View current configuration:**
```
/afx-quality-gates
```
Displays the active profile, which gates are on/off, and any ticket overrides.

**Switch profile:**
```
/afx-quality-gates profile production
```
Changes the project profile and updates all gate settings accordingly.

**Toggle a gate:**
```
/afx-quality-gates set security_scan on
```
Turns on a specific gate without changing the profile.

**Check effective gates for a ticket:**
```
/afx-quality-gates check 2.5
```
Shows which gates will be enforced for that ticket (profile + overrides).

## Integration with Project Init

When the project-init skill runs, it can call `quality-gates.sh init <project_type>` to bootstrap the configuration based on the project stage identified during the interview:

| Project Stage (from interview) | Suggested Profile |
|-------------------------------|-------------------|
| Early prototype | prototype |
| Active development (internal) | internal |
| Active development (users) | production |
| Mature / maintenance | production |
| Library / SDK / package | library |

The project-init skill should suggest the profile and let the user confirm or override.

## When NOT to Use This Skill

- When the project has its own CI/CD pipeline that handles quality gates externally
- When the team has a custom quality process that doesn't map to these gates
- When working on a one-off script that doesn't use the ticket-implementation workflow