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 skills add HugoRCD/evlog --skill linear-maintenancegit 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/linear-maintenance)<a href="https://agentmods.dev/skills/hugorcd/evlog/linear-maintenance"><img src="https://agentmods.dev/badge/skills/hugorcd/evlog/linear-maintenance/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/skills/hugorcd/evlog/linear-maintenance"><img src="https://agentmods.dev/badge/skills/hugorcd/evlog/linear-maintenance.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00089 | $0.01054 |
| Opus 5.5 | $0.00036 | $0.00422 |
| Sonnet 5.5 | $0.00018 | $0.00211 |
| Haiku 4.5 | $0.00009 | $0.00105 |
Grade A, and why
linear-maintenance 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 1mo 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.
Linear maintenance
A regular housekeeping sweep over the evlog team's Linear backlog so it stays readable and current between passes. The goal is a tidy, trustworthy backlog, not a census. Listing every issue is not the point; correcting the drift and flagging what needs a decision is.
Where the other skills draw the line: self-review owns the coherence and
reach of the agent's own surface, repo-health-sweep owns the repository and
docs, cost-watchdog owns gateway spend. This skill owns Linear housekeeping
only, and stops there. When a pass finds evidence that shipped work is now
live (a schedule, a skill, a merged PR), the finding belongs to this skill's
"close it" bucket, not to building anything.
Two halves, in order
Apply what is mechanically verifiable. These are the unambiguous fixes,
and they are the point of the run: the sibling set or the issue history is
evidence enough that a write is correct. Apply them directly via
linear__save_issue.
Surface what needs a judgement call about intent. Anything you cannot verify, or whose correct value is a matter of taste, stays open and is written down as a finding for Hugo. Never guess a decision that a sibling set or the issue history cannot support.
The lenses
Enumerate the open surface first: linear__list_issues on the evlog team,
across states. Then for each item check:
- Project: every open issue sits in the project its title and content
point to, or in
Triageif it is genuinely unplaced. An issue whose peers carry a project but it does not is a fix, not a finding. - Priority: an item
In Progressshould carry a priority consistent with its siblings; aBacklogitem with no priority next to prioritized peers is inconsistent. A priority change that relies on an estimate of intent is a finding. - Label: every open issue carries one of the team's labels. A feature request with no label is a fix. A label that duplicates another, or has a single use, is a hygiene finding.
- Stale: triage older than several months with no movement, parked next to a canceled sibling, or an investigation that outlived its question, is a finding (close it or kick it to the community).
- Done but open: an item whose work already shipped in another issue, a schedule, or a merged PR, and is still open, is a close. Only when the shipped evidence is verifiable from the issue history or linked work.
- Consistency: a true duplicate of a completed or archived sibling, a sub-issue misread as a duplicate, work whose state contradicts its neighbors.
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.
- 1mo ago First seen · 85 lines · 89 tokens per session scan A 677b88dc6648
linear-maintenance is a skill published in the GitHub repository HugoRCD/evlog (1,895 stars, last pushed 3d ago), licensed MIT. It adds 89 tokens to every session and 1,054 once invoked, about $0.0004 per session on Opus 5.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…
operating-github-cli
Default GitHub skill for the action agent. Use githubcli for any GitHub request — create/list/view/close issues and PRs, assign, labels, repos, releases, checks, github.com/owner/repo URLs, or gh api. Prefer over shellrun/!gh. Run these with githubcli in the current agent turn.
tracking-github-work-status
Use GitHub workflow tools to read work status, draft reports, summarize follow-ups, and execute only approved issue mutations.
dd-file-issue
File GitHub issues to the right repository (pup CLI or plugin).
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…