evlog agents
Wiring evlog into an app is half the job. The other half is the assistant writing the handlers, which keeps reaching for console.log and throw new Error(...) until something in the repository tells it not to.
evlog agents writes that something.
evlog agents
nuxt
✓ created AGENTS.md
✓ created CLAUDE.md
✓ installed skills · npx skills add https://www.evlog.dev
What it writes
| File | What happens |
|---|---|
AGENTS.md | Created if missing. Otherwise the evlog block is replaced in place, between <!-- evlog:start --> and <!-- evlog:end --> — everything outside those markers is left exactly as it was. |
CLAUDE.md | Created as a one-line @AGENTS.md if missing. If it exists and already mentions AGENTS.md, it is left alone. |
The block is short on purpose — it is loaded into every agent turn. It states the rules (one wide event per operation, grouped context, structured errors, audit on sensitive actions, what never gets logged) and points at the skills for the depth. The logger accessor named in it follows your framework: useLogger(event) on Nuxt and Nitro, useLogger() from your lib/evlog.ts on Next.js, req.context.log on TanStack Start. When no framework is detected the block is still written with a generic accessor — the conventions apply just as well on Express or Hono.
The skills are not ours to install
The agent skills come from npx skills, which evlog agents shells out to — the same way evlog init runs your package manager instead of unpacking a tarball itself.
That is deliberate. Every agent reads a different directory (.claude/skills, .agents/skills, .codex/skills, …), and the skills CLI already resolves them per agent, symlinks a canonical copy, and supports a global scope. It also keeps no manifest, so any copy we wrote behind its back would be a second one it could never update. Delegating means one copy, and npx skills update / remove / list keep working on it.
Before running anything, evlog agents looks for evlog skills already installed — any agent, project-local or global — and leaves them alone if it finds them:
· AGENTS.md is up to date
· CLAUDE.md already points at AGENTS.md
✓ skills already installed · .agents/skills, .claude/skills
npx skills update to refresh them
evlog agents hands over the terminal rather than answering on your behalf. Non-interactive runs (--json, --yes, CI, no TTY) pass --yes so nothing blocks on a prompt nobody will answer.Safe to re-run
Running it again refreshes the block against the current CLI. Anything already identical is reported rather than rewritten, so a second run leaves the working tree clean. Run it after upgrading @evlog/cli.
Flags
| Flag | What it does |
|---|---|
--skills <list> | Comma-separated skill names, passed to npx skills add --skill (default: all of them) |
--no-skills | Write the AGENTS.md block only — nothing is spawned |
--global, -g | Install the skills for every project instead of just this one |
--source <url> | Where the skills are published (default: https://www.evlog.dev) |
--dry-run | Show the plan without writing or running anything |
--yes, -y | Apply without confirming |
evlog agents --skills review-logging-patterns
evlog agents --global
evlog agents --no-skills
evlog agents --dry-run
If the skills CLI fails — no network, no npx — the block is still on disk and the command reports the failure and exits 1. The AGENTS.md block never needs the network.
As part of evlog init
evlog init offers this as its last question. The AGENTS.md and CLAUDE.md writes land in the same plan as the evlog wiring — one list, one confirmation — and the skills run alongside the package-manager install. Skip it with --no-agents:
evlog init --no-agents
Next Steps
- Agent Skills — what each skill teaches
evlog map— score what your agent still has not covered- Wide Events — the conventions the block is summarising
telemetry
What the evlog CLI collects about its own usage, how to see it, and the three ways to turn it off — DO_NOT_TRACK, EVLOG_TELEMETRY=0, or evlog telemetry disable.
Overview
Wire evlog into your stack — pick a framework integration to capture requests automatically, then pick adapters to ship events to Axiom, Sentry, PostHog, OTLP, and more. Frameworks decide where the logger lives; adapters decide where events go.