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/CATWILLgh/MAINFRAMEWrote 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/catwillgh/mainframe/mainframe-tickets-verify)<a href="https://agentmods.dev/commands/catwillgh/mainframe/mainframe-tickets-verify"><img src="https://agentmods.dev/badge/commands/catwillgh/mainframe/mainframe-tickets-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/catwillgh/mainframe/mainframe-tickets-verify"><img src="https://agentmods.dev/badge/commands/catwillgh/mainframe/mainframe-tickets-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.02353 |
| Opus 5.5 | $0.00000 | $0.00941 |
| Sonnet 5.5 | $0.00000 | $0.00471 |
| Haiku 4.5 | $0.00000 | $0.00235 |
Grade A, and why
mainframe-tickets-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 8d 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.
How it starts
The opening of the file, as written. The whole thing — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify implemented project tickets
This is a user-invocable command. Execute it only because the current invocation explicitly selected it. It takes no arguments: every invocation processes the complete current project queue awaiting independent verification.
Independently verify each eligible implementation, record one evidence-backed verdict, and continue until no ticket remains that this command can reliably process. Do not discover unrelated problems, repair code or tests, deploy, or perform product-wide or release acceptance during this command.
When the user starts a native goal and then invokes this command separately, process the queue under that existing goal. The ticket-only write boundary applies to the entire verification campaign, including continuations and delegated work. Do not create a second goal or switch to implementation after finding a failed check.
Read the initialized ticket contract
Read docs/tickets/AGENTS.md and check its directory, record-format, and lifecycle rules before queue writes. If the root, contract, or required layout is missing or conflicts with effective project rules, report that mainframe-tickets-init must initialize or reconcile it; do not run initialization implicitly, invent another tracker, or migrate unrelated records. Use docs/tickets/ in the current project only. The directory is state: do not add a YAML status field. Preserve string IDs, required frontmatter, meaningful evidence and links. Exclude .campaigns/ and .migration/ from every ticket scan.
Select only docs/tickets/open/needs-verification/, preserving the recorded execution route. Add Verification with the independence basis, current checks, verdict, adjacent risk evidence and limitations, plus a Blocker or User decision section when required. Move a proved correction to archive/resolved/, a failed implementation to open/ready/, missed investigation to open/needs-scope-review/, user-owned choices to open/needs-decision/, and disproved, superseded or duplicate claims to archive/rejected/. A blocked observation may remain in needs-verification with the exact resumption condition. Preserve IDs, required YAML and execution markers; returning a user-approved record to ready does not convert it into autonomous work. Update only ticket records and their paths/links; progress stays in them and native goal state. Do not edit .campaigns/, root rules, README, or recovery files during verification.
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.
- 8d ago Changed fbb7b247aac6
- 9d ago Changed · +5 lines 6d563a7d8a10
- 14d ago First seen · 89 lines · 0 tokens per session scan A b66cd3a32596
mainframe-tickets-verify is a command published in the GitHub repository CATWILLgh/MAINFRAME (2 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,353 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-10-02.
Other commands, from other repositories
qa-plan
Generate QA test plan for sprint or feature.
convert-to-test-driven-prompt
Transform user requests into Test-Driven Development (TDD) style prompts that explicitly define expected outcomes, test cases, and success criteria before implementation.
complete
Review implementation evidence and plan the spec completion transaction.
test
Design or run focused test validation for a task, bug, or diff.
traceability-gen
A command that rebuilds a Markdown table linking requirements to project plans and tests. It reads requirement files, plan files, and test markers, then records what is planned or covered.
amazing-e2e-check
Run explicitly requested E2E, browser, device, or installed-deployment scenarios in an independent verification workflow.