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/kkollsga/codingest/read-inboxnpx skills add kkollsga/codingest --skill read-inboxgit clone --depth 1 https://github.com/kkollsga/codingestWrote 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/kkollsga/codingest/read-inbox)<a href="https://agentmods.dev/skills/kkollsga/codingest/read-inbox"><img src="https://agentmods.dev/badge/skills/kkollsga/codingest/read-inbox.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 | $0.00073 | $0.01103 |
| Opus 5 | $0.00036 | $0.00551 |
| Sonnet 5 | $0.00015 | $0.00221 |
| Haiku 4.5 | $0.00007 | $0.00110 |
Grade A, and why
read-inbox 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 3d 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 — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
read-inbox
Triage inbox/unread/ (feedback / bug / coordination notes, named
YYYY-MM-DD-from-<sender>-<topic>.md). The goal: nothing important stays
trapped in a message — it lands as a durable dev-docs/ note plus a lean
todos.md backlink — and unread/ ends empty. See AGENTS.md "Inbox hygiene".
1. Auto-purge the read archive (always first)
At skill start, hard-delete inbox/read/ entries older than 7 days. The durable
record lives in dev-docs/, so the week-old archive copy is redundant:
find inbox/read -type f -mtime +7 -print -delete
Report what was purged (path list, or "nothing aged out").
2. Read every unread message
List inbox/unread/. Read each file fully. For each, decide: does it carry
durable info, an open action, a decision, or is it a no-action ack?
3. Lift durable info → dev-docs/ + todos
Route per the dev-docs/README.md layout map:
- Actionable content → file it as a todo using the
add-todoskill's entry rules (it's the authority on todo shape): classify → the righttodos.mdsection, scope the detail into aplans/doc (reuse one by theme), add the lean one-line backlink + the source-message link. A message that surfaces several actions is add-todo's batch mode — decompose, group by theme, file each. - Design choice / trade-off / parity-strategy content → a
dev-docs/designs/reference doc instead of aplans/doc (no todo — it's reference, not an action). - A no-action ack needs no todo — just note it in the move footer (step 5).
Don't restate the todo-entry format here — follow add-todo. This skill owns the inbox-specific parts: per-message triage, routing (step 4), the Status footer, and archival (step 5).
4. Route actionable items to the party who can act
If a message carries an actionable task for another project, file a note to
their inbox via the notify skill's schema, named
YYYY-MM-DD-from-codingest-<topic>.md. The most common case: a parity-relevant
bug or an API affordance that must land upstream in KGLite — route it to
KGLite's inbox (../../KGLite/inbox/unread/). KGLite source is read-only here,
so a note is the correct channel, not a local patch. Only route if there's
genuinely something for them to do — don't clutter their unread/. Batch the
routing: all actionable items for one target from this triage session go in
ONE note, not one per source message. Route a reply only if the sender
requested one or your content changes their next action — a bare ack or "done
on our side" belongs in the Status footer (step 5), never in their unread/.
The notify skill's "Send discipline" section is the authority on the outbound
bar.
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.
- 3d ago First seen · 80 lines · 73 tokens per session scan A e909e5fb150e
read-inbox is a skill published in the GitHub repository kkollsga/codingest (0 stars, last pushed 3d ago), licensed MIT. It adds 73 tokens to every session and 1,103 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
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…