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/task-verify)<a href="https://agentmods.dev/commands/thixpin/pitway/task-verify"><img src="https://agentmods.dev/badge/commands/thixpin/pitway/task-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/task-verify"><img src="https://agentmods.dev/badge/commands/thixpin/pitway/task-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.00817 |
| Opus 5.5 | $0.00000 | $0.00327 |
| Sonnet 5.5 | $0.00000 | $0.00163 |
| Haiku 4.5 | $0.00000 | $0.00082 |
Grade A, and why
task-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
task-verify
Role: Orchestrator
pitway task-verify <id> [--typecheck <command>] [--timeout <ms>] [--json]
Runs an in_progress task's own approved command/tdd verification
command (plus optional --typecheck <command> and --timeout <ms> -- 1000..3600000; when omitted, the task's own verification.timeout_ms applies if declared, else 120000) and persists a
verification record — a full task_verify_evidence journal entry
covering the run's exit code, pass/fail counts, and a fingerprint of the
task's declared write_scope/relevant_files. Each record is named by an
evidence id (e.g. tve-a1b2c3). This is the formal replacement for an
ad hoc independent rerun-and-eyeball of the verification command — see
../protocol-driver.md. It does not replace your own diff/write_scope
review, which still happens first, every time.
On a failed attempt the record may additionally carry failures beside the
existing passCount/failCount — 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 capped evidence string and its own
failures: summary are unchanged. The human output renders each entry as
an indented - <entry> line under the one-line report (whose inline counts
are unchanged). failures is absent — and no extra lines render — on a
passing attempt, when a failing command's output matched none of the
patterns, and on every record written before this feature existed.
Must run while the task is in_progress — before pitway task-update <id> review, not after (review's own tasks.yaml rewrite never invalidates a
recorded evidence record). If completion later refuses because no recorded
record resolves cleanly, pitway task-update <id> in_progress is a legal
recovery transition from review — run task-verify again from there to
produce a fresh record.
pitway task-update <id> completed then resolves one record — implicitly,
the newest one whose own run passed (searched newest-to-oldest, so a later
failing re-run never masks an earlier passing record), or explicitly via
--evidence <id> (strict: no such search, a failing or stale record named
explicitly still refuses) — and validates it (task identity, run success,
attempt match, command match, write_scope match, fingerprint match) before
completing. On success, its captured evidence unconditionally becomes the
persisted result evidence — the final, capped string that lands in
task.result.evidence — replacing whatever --result's file carried for
that field.
Once any evidence record exists for a task, plain --result/--message
completion can no longer bypass it. But a task is never permanently
stuck: if no recorded record resolves cleanly at completion, recover with
pitway task-update <id> in_progress, then run task-verify again to
produce a fresh, valid record.
See ../protocol-driver.md and ../dispatch.md. Run pitway task-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 · +12 lines 4d7a315b5a8a
- 1mo ago First seen · 50 lines · 0 tokens per session scan A 6ed794181e40
task-verify is a command published in the GitHub repository thixpin/pitway (20 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 817 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
implement
Execute all implementation tasks from tasks.md with test-driven development, parallel batching, and atomic commits.
tasks
Generate TDD task breakdown from plan.md with test-first sequencing and mockup-first mode (--ui-first).
conventions-check
Check AGENTS.md, CLAUDE.md, and the projected agent artifacts (skills, subagents, commands) against the repo's conventions.
debug
Systematic root-cause investigation, then fix with TDD — never proposes a fix before finding the cause; resumable diagnosis + regression test in .orc/ state. Workspace-aware. For a quick one-off look without session state, prefer the bundled /debug.
avance-rapido
Crear todos los artefactos de planificación de un golpe (fast-forward).
tdd
Guide a Test-Driven Development workflow for the current task.