Skill

verification-slots

Explains verification slots as the core harness framework abstraction for constraints via linters, formatters, deterministic tools, and agent checks. Guides tool integration and enforcement types.

ESLint

Prettier

code-quality

npx claudepluginhub habitat-thinking/ai-literacy-superpowers --plugin ai-literacy-superpowers

Tool Access

This skill uses the workspace's default tool permissions.

Preview

The verification slot is the harness framework's core technical

Supporting Assets

references/tool-integration.md

SKILL.md

Similar Skills

constraint-design

Guides designing constraints for HARNESS.md: writes verifiable rules, selects enforcement types (deterministic/agent/unverified), tools, scopes (commit/PR/weekly/manual), and command risk classifications.

1 file

ai-literacy-superpowers

Harness Verification

Performs 3-level deep verification (EXISTS, SUBSTANTIVE, WIRED) of completed tasks with fresh evidence only. Use for milestones, PRs, or post-quick-gate audits.

1 file

harness-claude

verification-engine

692

Executes unbiased verification loops via sub-agent: git analysis, build, typecheck, lint, tests with auto-fixes/retries. Invoke /handoff-verify after code changes.

claude-forge

Stats

Parent Repo Stars25

Parent Repo Forks3

Last CommitApr 6, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Verification Slots

The verification slot is the harness framework's core technical abstraction. Every constraint — whether backed by a linter, a formatter, a structural test, or an LLM agent — is checked through the same interface. This uniformity means the rest of the system (hooks, CI, commands) does not care how a constraint is verified.

The Contract

Input:

Constraint definition (rule, enforcement type, tool)
Scope (commit, pr, weekly, manual)
File set (changed files, or all files)

Output:

Result: pass or fail
Findings: list of {file, line, message} (empty on pass)

How the Enforcer Decides

The harness-enforcer agent reads each constraint from HARNESS.md and dispatches verification based on the enforcement field:

Enforcement	What happens
`deterministic`	Execute the `tool` command, interpret exit code
`agent`	Read the `rule` text, review files, produce findings
`deterministic + agent`	Run both, merge findings
`unverified`	Skip — log as unchecked

Deterministic Tool Integration

To fill a verification slot with a deterministic tool:

Identify a tool that checks the constraint (linter, formatter, scanner, custom script)
Verify it runs locally and produces usable output
Update the constraint in HARNESS.md: set enforcement to deterministic and tool to the exact command
Run /harness-audit to confirm the tool works in the harness context

For detailed integration patterns for common tools (ESLint, Prettier, gitleaks, ArchUnit, custom scripts), consult references/tool-integration.md.

Agent-Based Verification

When no deterministic tool exists, the enforcer reads the constraint's prose rule and reviews code against it. The output format is identical to deterministic verification — pass/fail with file:line findings.

Agent-based checks are:

Flexible — work with any constraint that can be described in prose
Non-deterministic — may give different results on identical input
Token-intensive — each check costs LLM inference
Nuance-aware — can evaluate intent and context, not just syntax

Mixed Enforcement

Some constraints benefit from both levels. For example, a linter checks that doc comments exist (deterministic presence check) while the agent reviews that comments explain reasoning rather than restating signatures (quality check).

Use deterministic + agent in the enforcement field and list both tools.

Additional Resources

Reference Files

references/tool-integration.md — Step-by-step integration patterns for linters, formatters, type checkers, secret scanners, structural test frameworks, and custom scripts