[Extension]: Add gates (Quality Gates — Enforcement Layer)

[schwichtgit]

Extension ID

gates

Extension Name

Quality Gates (Enforcement Layer)

Version

0.1.0

Description

Deterministic quality enforcement for Spec Kit projects at three boundaries — agent hooks, git pre-commit, CI — with one policy file and provable enforcement (attestations, canaries, verified parity).

Author

schwichtgit

Repository URL

https://github.com/schwichtgit/spec-gates

Download URL

https://github.com/schwichtgit/spec-gates/releases/download/v0.1.0/gates-0.1.0.zip

License

MIT

Homepage (optional)

https://github.com/schwichtgit/spec-gates

Documentation URL (optional)

https://github.com/schwichtgit/spec-gates/blob/main/docs/how-it-works.md

Required Spec Kit Version

=0.12.0

Required Tools (optional)

• jq — required (policy parsing, attestations)
• git — optional (git boundary hooks, mutation detection; agent/CI boundaries work without it)
• node with pinned linters (prettier, markdownlint-cli2) — optional, only the linters your policy enables
• shellcheck — optional, only if your policy lints shell

Number of Commands

5

Number of Hooks (optional)

1

Tags

quality, enforcement, hooks, ci, governance

Key Features

• One policy, three boundaries: the same verify.sh and policy.json run at the agent boundary (Claude Code PreToolUse/PostToolUse/Stop hooks), the git boundary (pre-commit), and CI (projected GitHub Actions / GitLab CI / Jenkins) — identical results everywhere
• Provable enforcement: every run appends an attestation record (policy SHA-256, per-gate tool version, lockfile pin, candidate vs checked counts); a canary suite plants known violations in sandboxes and fails if any gate stops blocking; a synthetic parity gate fails on lockfile drift
• Spec-conformance gate: fenced ```accept blocks in specs/*/tasks.md are executable acceptance criteria; a feature whose spec declares `Status: Complete` blocks the run on any unchecked task or failing criterion
• Projected runtime: enforcement is copied into the repo, survives extension removal, works offline in CI, and every collaborator gets it on clone
• User-owned policy: init infers and seeds policy.json, upgrade never overwrites it; schema validation rejects unknown fields

Testing Checklist

• Extension installs successfully via download URL
• All commands execute without errors
• Documentation is complete and accurate
• No security vulnerabilities identified
• Tested on at least one real project

Submission Requirements

• Valid extension.yml manifest included
• README.md with installation and usage instructions
• LICENSE file included
• GitHub release created with version tag
• All command files exist and are properly formatted
• Extension ID follows naming conventions (lowercase-with-hyphens)

Testing Details

Tested on:

• macOS (Darwin 25.5, bash 3.2 floor, BSD awk/sed) with Spec Kit CLI v0.12.4
• Ubuntu (GNU toolchain) via GitHub Actions on every PR

Test project: the extension's own repository dogfoods it — CI projects the runtime and runs verify.sh --boundary ci, the full canary suite, and 8 test suites (~180 cases) on every PR: https://github.com/schwichtgit/spec-gates/actions

Test scenarios:

1. Installed from the release asset URL into a scratch project with specify extension add gates --from <download-url> (verified: 5 commands + 1 hook registered, v0.1.0)
2. Dev-installed with specify extension add --dev and exercised init → verify → doctor
3. Canary suite proves each gate still blocks (known violations must be rejected; an accepted probe fails the suite naming the gate)
4. The repo's own specs are enforced by the spec gate it ships (executable acceptance criteria, enforced since the feature was marked complete)

Example Usage

# Install
specify extension add gates --from https://github.com/schwichtgit/spec-gates/releases/download/v0.1.0/gates-0.1.0.zip

# In Claude Code:
/speckit.gates.init        # infer policy, project runtime, wire agent + git hooks, self-test
/speckit.gates.ci github   # project the CI boundary (github | gitlab | jenkins)
/speckit.gates.verify      # run the full suite on demand
/speckit.gates.doctor      # health check (+ --canary to prove gates still block)

Proposed Catalog Entry

{
  "gates": {
    "name": "Quality Gates (Enforcement Layer)",
    "id": "gates",
    "description": "Deterministic quality enforcement for Spec Kit projects at three boundaries — agent hooks, git pre-commit, CI — with one policy file and provable enforcement (attestations, canaries, verified parity).",
    "author": "schwichtgit",
    "version": "0.1.0",
    "download_url": "https://github.com/schwichtgit/spec-gates/releases/download/v0.1.0/gates-0.1.0.zip",
    "repository": "https://github.com/schwichtgit/spec-gates",
    "homepage": "https://github.com/schwichtgit/spec-gates",
    "license": "MIT",
    "requires": {
      "speckit_version": ">=0.12.0"
    },
    "provides": {
      "commands": 5
    },
    "tags": ["quality", "enforcement", "hooks", "ci", "governance"],
    "verified": false,
    "downloads": 0,
    "stars": 0,
    "created_at": "2026-07-08T00:00:00Z",
    "updated_at": "2026-07-08T00:00:00Z"
  }
}

Additional Context

spec-gates is the enforcement counterpart to Spec Kit's guidance: lifecycle hooks and workflow gates in core are advisory (they pause and prompt), while this extension binds them to hard failure surfaces — the bash call is rejected, the protected file is refused, the commit is blocked, CI goes red. The enforcement layer is designed to prove it is still enforcing: attestation records per run, canary self-tests in CI, and a no-op-signature check in doctor. Note: the download URL points at a flat release asset (extension.yml at the package root) rather than the source archive, because the manifest lives in extension/ inside the repository.

[schwichtgit]

Version update while this submission awaits triage: v0.2.0 has been released and is the version to list.

• Version: 0.2.0
• Download URL: https://github.com/schwichtgit/spec-gates/releases/download/v0.2.0/gates-0.2.0.zip
• Commands: 7 (adds speckit.gates.sync and speckit.gates.propose)
• Updated catalog-entry fields: version, download_url, provides.commands: 7; everything else from the original submission is unchanged.

New since 0.1.0: the spec-conformance gate (acceptance criteria in tasks.md run as executable, enforced checks), policy-as-versioned-contract (extends an org baseline at a pinned version with offline drift-proving, reviewable updates, and upstream proposals), and signed releases — each asset now ships with a sha256 checksum and a sigstore keyless signature produced and self-verified by the release workflow. Install tested with Spec Kit CLI 0.12.8.

[github-actions]

cc @github/spec-kit-maintainers — new catalog submission for review.

[github-actions]

Pull request created: #3431

Generated by Add Community Extension from Issue Submission · 510.6 AIC · ⌖ 39.9 AIC · ⊞ 32.9K