Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/thixpin/pitwayWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/thixpin/pitway/verify)<a href="https://agentmods.dev/commands/thixpin/pitway/verify"><img src="https://agentmods.dev/badge/commands/thixpin/pitway/verify/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/thixpin/pitway/verify"><img src="https://agentmods.dev/badge/commands/thixpin/pitway/verify.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.00588 |
| Opus 5.5 | $0.00000 | $0.00235 |
| Sonnet 5.5 | $0.00000 | $0.00118 |
| Haiku 4.5 | $0.00000 | $0.00059 |
Grade A, and why
verify scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
verify
Role: Orchestrator (runs, --check records) · either (--status)
pitway verify [id] [--status] [--json]
pitway verify [id] --check <ctid> [--json]
pitway verify [id] --check <ctid> --pass|--fail --evidence <text> [--json]
Runs the milestone's approved command checks and records the results;
--check <id> --pass|--fail --evidence <text> records a manual/review
check a human (or you, on the human's behalf, for a review-type check)
had to actually evaluate. Only ever runs the commands approved at
milestone-confirm time (verification_approved_hash) — never an
agent-authored command that wasn't part of that approval.
Use it once every task in a milestone is done, to check the milestone's
acceptance criteria as a whole before milestone-complete.
When a command check fails, its verification-results.yaml entry (and
the matching --json result) may additionally carry fail_count,
pass_count, and failures — a structured record of what failed, kept
beside the 200-char evidence string, never inside it. The counts come
from the runner's own Tests N failed | M passed summary line; failures
lists the failing test names (vitest's FAIL / × lines, capped at 12)
followed by the first error lines (any <Word>Error: line — Error:,
AssertionError:, TypeError:, ReferenceError:, ... — capped at 3).
That wider error matcher belongs to the structured extractor only; the
evidence string's own failures: summary is unchanged. The human output
renders them as indented lines under the failed check, on a full run and on
a --check <ctid> rerun alike: a count line listing only the counts present
(failed: 7 (passed: 3), or just failed: 7 when the runner reported no
passed count — never a fabricated 0), then one - <entry> line per
failure. The fields are absent — and nothing extra renders — for passing
checks, for developer-recorded manual/review results, for a failing
command whose output matched none of the patterns, and for every entry
recorded before this feature existed.
See ../protocol-driver.md. Run pitway verify --help for flags.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago Changed · +19 lines 4357e3c941e4
- 1mo ago First seen · 27 lines · 0 tokens per session scan A f25a28e38b63
verify is a command published in the GitHub repository thixpin/pitway (20 stars, last pushed 4d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 588 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
conventions-check
Check AGENTS.md, CLAUDE.md, and the projected agent artifacts (skills, subagents, commands) against the repo's conventions.
gjalla-review
Review a spec OR a code change against master spec, rules, and production readiness.
audit-agents-skills
Audit quality of agents, skills, and commands in a Claude Code project.
review
A command for reviewing code with security checks and a check for compliance with MX tags. The available description does not explain what MX tags are.
auditar-refactor
Invoca refactor-safety-auditor — gate canônico antes de qualquer refactor. Coleta evidências (linhas, contrato externo, coverage, mutation) e retorna veredito GO/BLOCK/WARN/GO-OVERRIDE.
avance-rapido
Crear todos los artefactos de planificación de un golpe (fast-forward).