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
✓ installed the evlog skills for Claude Code, Codex and the others
  ran      npx --yes skills add https://www.evlog.dev --agent universal --agent claude-code --global --yes

What it writes

CLAUDE.md is not written. Most agents read AGENTS.md directly, and Claude Code does too unless a CLAUDE.md sits above it. If you want an explicit pointer, add a one-line @AGENTS.md yourself. An existing CLAUDE.md is never touched.

The block is short on purpose, because 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, and 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
✓ skills already installed · .agents/skills, .claude/skills
   npx skills update to refresh them

What you are trusting

Delegating means running third-party code, so it is worth being explicit about the trust model.

• What runs. Exactly one command, never assembled from anything you did not pass: npx --yes skills add <source> --agent universal --agent claude-code --global, plus --skill when you asked for a selection, --local in place of --global when you asked for a project install, and a trailing --yes when the run is non-interactive. Interactively it is shown twice: in the plan you confirm, and again as the step starts. Non-interactively (--json, --yes, CI, no TTY) it appears in the report the run prints afterward. Either way the string is the command argument for argument, so re-typing it reproduces the run exactly; --dry-run shows it without running anything.
• Not pinned. npx resolves the latest skills at run time. That is the point, since skills guidance tracks the docs site rather than a CLI release, but it does mean the version you get today is not the one you got last month. If your policy needs a fixed version, use --no-skills and run your own pinned npx skills@<version> add https://www.evlog.dev.
• --source is validated. It must be a plain http: / https: origin: letters, digits, and . _ ~ : / - only, so no query string and no shell metacharacters. --skills entries must be lowercase dashed names. On Windows the spawn needs a shell to resolve npx (Node refuses to run a .cmd without one), so both are checked before anything is spawned rather than trusted down the chain.
• Nothing is spawned without a decision. --no-skills skips it entirely, and the interactive flow will not reach the command until you confirm the plan.

If none of that fits your policy, evlog agents --no-skills still writes AGENTS.md, which never touches the network, and you can install the skills however you prefer.

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.

Flags

Earlier versions took --global. Global is now the default, so that flag is gone.

evlog agents --skills review-logging-patterns
evlog agents --local
evlog agents --no-skills
evlog agents --dry-run

If the skills CLI fails, from no network or 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 write lands in the same plan as the evlog wiring, in one list with 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