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 agentmods add skills/craigjmidwinter/getvect/katranpx skills add craigjmidwinter/getvect --skill katragit clone --depth 1 https://github.com/craigjmidwinter/getvectWrote 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/craigjmidwinter/getvect/katra)<a href="https://agentmods.dev/skills/craigjmidwinter/getvect/katra"><img src="https://agentmods.dev/badge/skills/craigjmidwinter/getvect/katra.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.00088 | $0.01897 |
| Opus 5 | $0.00044 | $0.00949 |
| Sonnet 5 | $0.00018 | $0.00379 |
| Haiku 4.5 | $0.00009 | $0.00190 |
Grade A, and why
katra 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 6d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- katra — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 156 lines — stays where its author put it; the contents beside it link to each section on GitHub.
katra
Keep a living dev log while you work, using the katra CLI (or the
katra-mcp MCP tools, if connected). The log is markdown entries with embedded
rich components, served as a live page and committed alongside the code.
The model (read this first)
- A katra lives in
katra/at the repo root:entries/(one markdown file per post) +media/+config.yml. Runkatra listto see if one exists; if not,katra init. - A draft is an entry with no commit hash. It renders in the "In Progress" panel immediately — there is no scratch file and no promote step. The draft is the running post; you stamp it at commit time (hash + diffstat) and it drops into the log. Nothing can get stuck.
You are writing a post, not a report
This is the part that goes wrong. Entries drift into flat technical documents — a wall of prose that reads like a handoff note to the next agent — and a log of those is one nobody, including you in a month, ever reads.
Your project-memory already captures the play-by-play, and katra ingests that memory into the log at commit time. So don't re-type the transcript. Spend your effort on the two things a text memory can't hold:
- Show the thing. Screenshots, renders, before/after sliders, diagrams, charts. A single capture is worth paragraphs.
- The reasoning. The decision and the why, the alternative you rejected, what broke first. That's the signal memory paraphrases away.
Write it the way you'd write it up for someone who wasn't there:
- Open with the stakes, not the filename. "The HUD was eating the city" beats "Implemented WorldHUD.cs changes in-place."
- Name the thing you rejected, and why it lost. A post with no discarded alternative reads as though the answer was obvious, which it wasn't.
- Land it. End on what's now true and what's still shaky — a
warningblock for the parts that need a device, a person, or a rerun to confirm.
Anti-patterns, all observed in real katras:
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.
- 6d ago First seen · 156 lines · 88 tokens per session scan A 4840f4f9cb83
katra is a skill published in the GitHub repository craigjmidwinter/getvect (90 stars, last pushed 9d ago), licensed MIT. It adds 88 tokens to every session and 1,897 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-30.
Other skills, from other repositories
imap-smtp-email
Read and send email via IMAP/SMTP. Check for new/unread messages, fetch content, search mailboxes, mark as read/unread, and send emails with attachments. Works with any IMAP/SMTP server including Gmail, Outlook, 163.com, vip.163.com, 126.com, vip.126.com, 188.com, and vip.188.com.
dark-mode-check
Audit SCSS and TSX files for dark mode issues — missing variable usage, hardcoded colors, icon gaps, selector misuse, and inline dark overrides outside the theme folder.
typescript-code-review
Perform comprehensive code reviews for TypeScript projects, analyzing type safety, best practices, performance, security, and code quality with actionable feedback.
release
Use when the maintainer wants to cut, prepare, or ship a code-by-wire release — e.g. says "bump version", "bump vX.Y.Z", "release it", "ship it", or "cut a release" — whether before the release (preparing the version bump and the changelog PR) or after the bump PR has merged (tagging and publishing).
qa-engineer
Analyze code changes and generate Playwright E2E tests in anytype-desktop-suite. Run after implementing features or modifying editor/component behavior to ensure new functionality has test coverage.
update-docs
Update README documentation in the folder of changed components/abstractions to reflect code changes — keeps docs lean, precise, and in sync.