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.
npx skills add CATWILLgh/MAINFRAME --skill mainframe-tickets-refinegit 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/skills/catwillgh/mainframe/mainframe-tickets-refine)<a href="https://agentmods.dev/skills/catwillgh/mainframe/mainframe-tickets-refine"><img src="https://agentmods.dev/badge/skills/catwillgh/mainframe/mainframe-tickets-refine.svg" alt="Measured on agentmods" 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.00080 | $0.00882 |
| Opus 5 | $0.00040 | $0.00441 |
| Sonnet 5 | $0.00016 | $0.00176 |
| Haiku 4.5 | $0.00008 | $0.00088 |
Grade A, and why
mainframe-tickets-refine 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 7d 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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Refine open tickets
Treat the native Goal objective and any plain-language scope supplied with the
explicit invocation as the run boundary. An empty scope means every eligible
ticket in docs/tickets/open/observations/ and
docs/tickets/open/needs-scope-review/. Process one ticket at a time until the
selected queue is exhausted, the user pauses or cancels the run, or no eligible
work can continue because of an evidenced external blocker.
Before changing a ticket, read ticket-format.md.
Verify the problem
Restate the ticket as a falsifiable claim. Confirm or challenge it using the current repository, existing tests or saved outputs, and current owning documentation when the claim depends on a changing external contract. Check at least one plausible alternative explanation before treating the observation as a confirmed problem.
Do not run project code, tests, builds, linters, servers, containers, migrations, benchmarks, or external environments. Do not create verification code and do not implement a fix. If confirmation requires a new measurement and no existing contract supplies the boundary, preserve the exact evidence gap instead of inventing certainty. Continue with other eligible tickets.
Establish scope and identity
Find the affected locations and meaningful consequences far enough to establish the known blast radius. Separate independently fixable problems into separate tickets with new ids while preserving the original observation, history, and links. Keep one problem per ticket.
Search the open queue for semantic duplicates, not merely matching words. Keep
the clearest ticket as the canonical open record and append only material
evidence from duplicates. Move confirmed duplicates to archive/rejected/ with
a link to the canonical ticket and a concise reason. Never edit an archived
ticket.
Route the result
- Move a disproved, superseded, or duplicated ticket to
archive/rejected/. - Move a confirmed, sufficiently scoped problem to
open/ready/withexecution: autonomousonly when current cited evidence fixes the expected behavior and no product, business-logic, material infrastructure, destructive-action, data, authority, or irreducible preference choice remains. Add the autonomous boundary required by the ticket format. - Move it to
open/needs-decision/for every genuine or uncertain user-owned choice. State the exact decision and known consequences plainly; do not turn ordinary engineering judgment into a user decision, but never infer autonomy merely from confidence in a proposed solution or an existingreadypath. - Leave an unconfirmed ticket in
open/needs-scope-review/only when the forbidden new measurement or unavailable evidence is genuinely required. Record exactly what is missing and why inspection alone cannot establish it.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 7d ago First seen · 85 lines · 80 tokens per session scan A 612f371c4866
mainframe-tickets-refine is a skill published in the GitHub repository CATWILLgh/MAINFRAME (2 stars, last pushed 17d ago), licensed MIT. It adds 80 tokens to every session and 882 once invoked, about $0.0004 per session on Opus 5. 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-31.
Other skills, from other repositories
at-zentao
Handle ZenTao (禅道) Bugs and Tasks end to end, including updating or writing back an item after code changes, managing Task status and hours, and reading linked Stories. Use for referenced ZenTao items, requirements, status changes, time entries, or post-implementation synchronization.
issue-triage
3-phase issue backlog management with audit, deep analysis, and validated triage actions. Use when triaging GitHub issues, sorting bug reports, cleaning up stale tickets, or detecting duplicate issues. Args: 'all' to analyze all, issue numbers to focus (e.g. '42 57'), 'en'/'fr' for language, no arg = audit only.
plan-pipeline
Orchestrates the complete planning pipeline: product direction (ceo-review) -> architecture (eng-review) -> implementation plan (start) -> validation (validate) -> execution (execute). Run stages individually or let the orchestrator coordinate the full flow.
honest-closeout
Close a task with a report a reviewer can trust — every acceptance line answered with evidence or a recorded blocking reason, human corrections credited to whoever made them, refuted hypotheses kept, background processes proven stopped, and the chat message copied verbatim from the report. Use when reporting work as…
handoff-resume
Load a handoff document and resume work from where a previous session left off. Parses scope, file references, completed work, and next steps, then confirms understanding before proceeding.
expo-eas-submit
App Store Connect and Google Play Console upload flow with EAS Submit, metadata, build-artifact selection, review notes, and phased release. Triggers on eas submit, app store connect, google play, asc api key, service account, metadata, screenshot, phased release, review notes, testflight, internal testing, production…