evlog is a TypeScript-first logging and observability project built around wide events and structured errors across runtimes. It is intended to help developers record application behavior and diagnose failures.
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/hugorcd/evlog/self-reviewnpx skills add HugoRCD/evlog --skill self-reviewgit clone --depth 1 https://github.com/HugoRCD/evlogWrote 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/hugorcd/evlog/self-review)<a href="https://agentmods.dev/skills/hugorcd/evlog/self-review"><img src="https://agentmods.dev/badge/skills/hugorcd/evlog/self-review.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.00117 | $0.02392 |
| Opus 5 | $0.00059 | $0.01196 |
| Sonnet 5 | $0.00023 | $0.00478 |
| Haiku 4.5 | $0.00012 | $0.00239 |
Grade A, and why
self-review 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 5d 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 — 139 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Self review
Two halves, run together, because they fail in opposite directions.
Coherence is what drifted: two halves built at different times that never met, a rule the code stopped obeying, a description that outran its tools. Nothing is broken, no test fails, nobody files it.
Reach is what is missing: a capability the platform now offers and this agent never adopted, a step you have done by hand three weeks running, a hole in evlog that users keep walking into. Nothing is wrong, so nothing prompts it.
Skipping the second half turns this run into a regression sweep. Skipping the first turns it into a wishlist. Run both.
Two kinds of output, two bars
A finding contradicts something written down or something declared: a rule in a guide, a capability the app announces, a description that promises behavior the tools do not deliver. Name the prose or the declaration it contradicts, or drop it.
A proposal is a capability worth having that nothing yet argues for. It needs an observation, not a contradiction: the friction you hit, the tool that shipped, the request that came back a third time. Name what you observed and when, or drop it.
Neither bar is met by taste. "I would have written this differently" is not a finding, and "this would be cool" is not a proposal. Both are refusals to do the work of grounding.
Part one: coherence
A. Wiring gaps
Something is produced and nothing consumes it. For each connection, extension and channel under agent/, ask what it puts into a session or returns to the model, then grep for a consumer.
- Context blocks eve injects, session
state, channel metadata.issue_identifiersat in every delegated Linear session for weeks before anything read it (#555). - Values computed in
agent/lib/and returned to no one. - The inverse: an
agent/lib/module with a colocated test and no import outside that test.
B. Guides the code stopped obeying
| Guide | Check |
|---|---|
Root AGENTS.md |
A new entrypoint registered in all three of package.json#exports, package.json#typesVersions, tsdown.config.ts. No evlog/shared import (evlog/toolkit is the public name). No HTML comment in a Vue <template>. |
Root AGENTS.md |
Every framework integration exposes the same contract: evlog(), useLogger(), log.fork(). evlog/workers is the documented exception. |
apps/evi/docs/capability-placement.md |
The two-layer rule: a file under agent/ outside agent/lib/ holding logic instead of wiring, an agent/lib/ module with no colocated *.test.ts, or a caller check written inline instead of going through agent/lib/trust.ts. |
packages/evlog/test/README.md |
A framework test driving the app by hand instead of through its real request driver. |
Root AGENTS.md |
A behavior change whose matching .agents/skills/ or skills/ SKILL.md still describes the old shape. |
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.
- 5d ago First seen · 139 lines · 117 tokens per session scan A 2fda18d3dbc8
self-review is a skill published in the GitHub repository HugoRCD/evlog (1,831 stars, last pushed 3d ago), licensed MIT. It adds 117 tokens to every session and 2,392 once invoked, about $0.0006 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
gh-issue
Size-audit, write, and split BanyanDB issues that somebody else or an automated TDD workflow can implement. Use whenever the user asks to file or revise an issue, decide whether an issue is too large, make an issue TDD-ready, turn a design into tickets, or split an umbrella into executable leaves. Do not draft or file…
gh-pull-request
Create a GitHub pull request for SkyWalking BanyanDB. Use when the user asks to create a PR, submit changes, or open a pull request.
vendor-update
Upgrade Go/Node.js vendor dependencies and sync tool versions. Use whenever the user says "upgrade dependencies", "update vendors", "vendor update", "run vendor-upgrade", "bump dependencies", "update packages", or asks to run the vendor-update Make target. This skill also checks scripts/build/version.mk after…
monitoring-observability
Monitoring and observability patterns for Prometheus metrics, Grafana dashboards, Langfuse v4 LLM tracing (astype, scorecurrentspan, shouldexportspan, LangfuseMedia), and drift detection. Use when adding logging, metrics, distributed tracing, LLM cost tracking, or quality drift monitoring.
bydbql
Generate, validate, and optionally execute read-only BanyanDB BydbQL for STREAM, MEASURE, TRACE, and PROPERTY resources. Use when the user asks to query BanyanDB, translate natural language to BydbQL, inspect BanyanDB schema or data, validate BydbQL, or fetch raw BanyanDB records.
compiling
Compile and build the SkyWalking BanyanDB project. Use when the user asks to compile, build, or generate code for this project.