Agent skill

Self Review

by evloghq in evloghq/evlog

Weekly pass over the evlog repository and Evi's own surface, in two halves: what has drifted out of coherence (a capability wired but never consumed, code contradicting a written guide, a…

MITAuto-check passedAgent Workflows

Install Self Review

skills CLI
$ npx skills add evloghq/evlog --skill self-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install evloghq/evlog self-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/evloghq/evlog.git skills-src && mkdir -p .claude/skills && cp -r skills-src/apps/evi/agent/skills/self-review .claude/skills/self-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
self-review
GitHub stars
1.9k
Token cost
~2.7k tokens
SKILL.md length
1,629 words
Files
1
Skills in repo
20
Repo updated
First seen
Licence
MIT

At a glance

Weekly pass over the evlog repository and Evi's own surface, in two halves: what has drifted out of coherence (a capability wired but never consumed, code contradicting a written guide, a…

  • Tasks that involve Static sites and blogs
  • SKILL.md covers Two kinds of output, two bars, A. Wiring gaps, B. Guides the code stopped… and C. Prose that outran the tools, plus 9 more sections
  • Calls pnpm

What it does

Self Review is an agent skill from evloghq/evlog. Weekly pass over the evlog repository and Evi's own surface, in two halves: what has drifted out of coherence (a capability wired but never consumed, code contradicting a written guide, a description promising a tool the allowlist lacks), and what is missing (a capability worth having, a manual step worth automating, a gap in evlog users keep hitting). Load this when the self-review schedule fires, or when Hugo asks for a self-review, an audit, ideas for what Evi should do next, or what is inconsistent in the repo.

Its SKILL.md is about 2.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows, covering Static sites and blogs. The repository describes itself as: Digging through logs is not observability. It's hope — wide events, structured errors, TypeScript-first, every runtime. The licence is MIT.

When your agent uses it

  • Tasks that involve Static sites and blogs

Example prompts

  • “/self-review”

What it can do on your machine

Read from SKILL.md and the folder at commit 54dcc50. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • pnpm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use pnpm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Self Review loads about 2.7k tokens when it runs. Until then it costs about 133 tokens; SKILL.md has 1,629 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~133
When it runs · the whole SKILL.md, loaded when a task matches
~2.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from evloghq/evlog at commit 54dcc50, republished under its MIT licence (© evloghq). 1,629 words, ~2,732 tokens.

Download SKILL.mdSave it as .claude/skills/self-review/SKILL.md (or your agent's skills folder).
name
self-review
description
Weekly pass over the evlog repository and Evi's own surface, in two halves: what has drifted out of coherence (a capability wired but never consumed, code contradicting a written guide, a description promising a tool the allowlist lacks), and what is missing (a capability worth having, a manual step worth automating, a gap in evlog users keep hitting). Load this when the self-review schedule fires, or when Hugo asks for a self-review, an audit, ideas for what Evi should do next, or what is inconsistent in the repo.

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_identifier sat 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

GuideCheck
Root AGENTS.mdA 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.mdEvery first-class framework integration exposes the same contract: evlog(), useLogger(), log.fork(). Guide-level integrations (Astro, AWS Lambda) document the generic API instead, and evlog/workers is the documented exception.
apps/evi/docs/capability-placement.mdThe 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.mdA framework test driving the app by hand instead of through its real request driver.
Root AGENTS.mdA behavior change whose matching .agents/skills/ or skills/ SKILL.md still describes the old shape.

C. Prose that outran the tools

Read the strings the model actually sees against the tools it actually has.

  • Each agent/connections/*.ts: does the description name a capability the tools.allow list omits?
  • Each agent/skills/*/SKILL.md and agent/instructions.md: every tool name mentioned must exist. A skill pointing at an unreachable tool fails silently at the worst moment.
  • Every output destination instructions.md names must be writable from the posture that reads it.

D. Production signals

Read-only, and these become issues, never PRs.

  • telemetry-stats: an error code climbing week over week, a command whose success rate is falling.
  • CI on main: a job failing intermittently is a finding even when the reruns go green.
  • vercel__get_runtime_errors (production): a runtime error cluster growing week over week, or one whose route has no docs page explaining it, is a docs proposal with a number attached.
  • Evi's own production runs: vercel__list_agent_run_projects to find the eve service project, then vercel__list_agent_runs for sessions that ended badly or never answered and the failed tool calls inside them. Drill into a failure with vercel__get_runtime_logs.

Part two: reach

E. Capability the platform gained

The frameworks under this agent ship faster than it adopts them.

  • eve registry search <query> and eve registry list: integrations that exist and are not installed. Read one with eve registry view <item> before proposing it. The repo rule is to check the registry before building an integration by hand, so a hand-rolled tool duplicating a registry item is both a proposal and a finding.
  • Connections already wired whose server grew: a Linear, Vercel or telemetry tool that did not exist when the allowlist was written.
  • upstream-sync owns version bumps and workaround removal. This lens is about capabilities never adopted, not versions behind. When the two overlap, leave it to that skill.

F. Surface already paid for and unused

The cheapest new capability is one already connected.

  • A tool in a tools.allow list that no skill and no instruction ever tells Evi to call. Either a workflow is missing or the entry is, and both are worth saying out loud.
  • Objects a connected service offers that Evi never touches: Linear milestones and status updates, Vercel analytics dimensions, telemetry breakdowns that no skill reads.
  • A schedule that could carry work it does not: the digest already gathers numbers that another skill re-fetches.

G. The step that keeps repeating

The strongest proposals come from your own friction, and it is only visible from the inside.

  • A sequence you have run by hand more than twice across sessions is a skill waiting to be written. That is the cheapest capability in capability-placement.md and needs no code.
  • A question Hugo asked in three different weeks is a skill or a schedule.
  • A turn where you lacked a tool and worked around it, or read fifteen files to answer one question, is evidence for a tool or a subagent. capability-placement.md states the observed trigger for a subagent; cite it or do not propose one.
Show full SKILL.md (694 more words)Show less

H. Where evlog itself falls short

Look outward, not only at the agent.

  • telemetry-adoption: a flag or custom field nobody uses two releases in is a deprecation candidate; a custom field spreading on its own is a workflow worth making first-class.
  • The top error code from telemetry-stats with no docs page covering it is a docs proposal with a number attached.
  • Community issues and discussions asking for the same integration, adapter or option a third time.
  • A docs lookup that came up empty during a session: it usually means a page is missing.

I. Ideas already written down and never filed

The repo carries proposals nobody turned into work.

  • apps/evi/docs/notes.md, section Open.
  • apps/evi/docs/observability.md, section Proposals.

These are pre-grounded: someone already did the reasoning. An entry that still holds and has no issue is the easiest proposal of the run. One that no longer holds should be deleted from the doc, which is a finding.


Grounding

The failure mode of this run is a confident output that is wrong, and the expensive version is claiming something does not exist.

  • Absence is proven by listing, never by recall. Before writing that a tool, option, field or export is missing, enumerate the real surface: connection_search for a connection's tools, the file for an exports map, the docs index for a page, eve registry list for an integration. A name you do not remember seeing is not a name that is absent.
  • Never describe a check you did not run. If you could not verify something, say so in those words and file it as a question. It never enters a PR body as evidence.
  • One counter-example kills a finding. Before filing "nothing consumes X", grep the whole repo for X, not just the directory you were reading.
  • A proposal names its cheapest form. Walk capability-placement.md in order and say which rung it lands on and why not the one above. A proposal that arrives as "we should build a tool for this" without that walk is not ready.

Dedupe

Before filing anything: linear__list_issues on the evlog team, and github__searchIssues for an open issue or PR on the same ground, including your own pull requests from earlier runs. An existing pull request that still applies gets an update, not a replacement. A finding or proposal Hugo closed once does not come back: the decision was made.

Deliver

Mechanical fix, readiness gate complete, no judgement needed → ready PR. One per finding, never bundled. Follow contributing: branch off main in /workspace/repo, run pnpm run lint, pnpm run typecheck and pnpm run test, add a changeset when the change touches a published package (an apps/evi change never needs one), read CI, then request hugorcd as reviewer. If the gate cannot be completed, report the blocker instead of opening a draft. The PR body shows the change (a snippet, captured output, or capture, not prose alone) and names the guide or declared capability the code contradicted.

Everything else → Linear issue via linear__save_issue on the evlog team. A finding states the problem, what it contradicts, where it is, and the decision to make. A proposal states the observation that triggered it, what the capability would do, the rung of capability-placement.md it lands on, and what it costs. Label the two apart so the backlog stays readable.

A proposal never ships as code on your own initiative. The repo forbids speculative code, and an unrequested capability is exactly that. The issue is the deliverable; building it is Hugo's call.

Cap a run at three ready PRs and two proposals: the two you would defend, not everything that came to mind. Anything past the cap is named in the summary with a count, so a heavy week is visible rather than silently trimmed.

Then post one line per artifact to the thread, links inline.

When nothing is warranted

One line: the lenses ran and nothing came up. Never invent a finding to fill the run, never file an issue to report that a lens was clean, and never open a PR for a rule the repo does not actually state. A quiet week is a real result, and both halves are allowed to be quiet.

© evloghq, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in apps/evi/agent/skills/self-review of evloghq/evlog.

Open the folder on GitHubat commit 54dcc50

Compare with similar skills

Self Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Self Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Self Review this skillevloghq/evlog1.9k—~2.7kAutomated safety check: PassMIT
Eisland Dev Update DocsJNTMTMTM/eIsland320—~1.4kAutomated safety check: PassGPL-3.0
Eisland Dev Update DocsJNTMTMTM/eIsland320—~1.8kAutomated safety check: PassGPL-3.0
Docouture Documenting ChangesInditexTech/weavejs226—~1.3kAutomated safety check: PassApache-2.0
Mintlifylilinji/ai-infra-odyssey130—~2.9kAutomated safety check: PassNone
DocsChorus-AIDLC/Chorus1.2k—~1.2kAutomated safety check: PassAGPL-3.0

Similar skills

  • Eisland Dev Update Docs

    JNTMTMTM/eIsland

    Update or create documentation in the eIsland VuePress docs site (web/eisland-web-docs).

    320 GitHub stars~1.4k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Eisland Dev Update Docs

    JNTMTMTM/eIsland

    Update or create documentation in the eIsland VuePress docs site (web/eisland-web-docs).

    320 GitHub stars~1.8k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • How to update an existing docouture documentation site when a feature, change, deprecation or fix lands in the repo — figuring out what's affected from a diff/commit/PR, confirming with the user…

    226 GitHub stars~1.3k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Mintlify

    lilinji/ai-infra-odyssey

    Comprehensive reference for building Mintlify documentation sites.

    130 GitHub stars~2.9k tokensUpdated 11 days ago
    Frontend & DesignAuto-check passed
  • Docs

    Chorus-AIDLC/Chorus

    Chorus documentation router for Hermes Agent — consult the live Chorus docs site to answer product-usage questions (UI workflow, agent/plugin setup, API/MCP, deployment, operations).

    1.2k GitHub stars~1.2k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Docs Chorus

    Chorus-AIDLC/Chorus

    Chorus documentation router — consult the live Chorus docs site to answer product-usage questions (UI workflow, agent/plugin setup, API/MCP, deployment, operations).

    1.2k GitHub stars~1.1k tokensUpdated today
    Agent WorkflowsAuto-check passed

More from evloghq/evlog

All 20 skills in this repo
  • Walks through adding a new built-in evlog drain adapter for an observability platform: source, build config, exports, tests, docs and PR scope.

    1.9k GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed
  • Guides adding a new built-in enricher to the evlog package, covering the source, tests, docs, README, a related skill and a changeset.

    1.9k GitHub stars~1.7k tokensUpdated yesterday
    Auto-check passed
  • Walks a contributor through adding a new HTTP framework integration to the evlog logging package: middleware source, build entry, exports, tests, example app and docs.

    1.9k GitHub stars~5k tokensUpdated yesterday
    Auto-check: notes
  • Walks through adding a new rule or framework adapter to `evlog map` in @evlog/cli, from the rule source and registry to types, tests, docs and the published skill.

    1.9k GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed
  • Rules for writing and reviewing evlog docs, blog posts, READMEs, skills and AGENTS.md files, with separate review and rewrite roles, a house voice and a catalog of AI-sounding tells.

    1.9k GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed
  • Before After

    evloghq/evlog

    Produce a before/after visual comparison of an evlog surface (landing, docs, telemetry, playgrounds) and share it as public Blob URLs.

    1.9k GitHub stars~2.7k tokensUpdated yesterday
    Auto-check passed

Questions about Self Review

What does Self Review do?

Weekly pass over the evlog repository and Evi's own surface, in two halves: what has drifted out of coherence (a capability wired but never consumed, code contradicting a written guide, a…. Self Review is an agent skill from evloghq/evlog. Weekly pass over the evlog repository and Evi's own surface, in two halves: what has drifted out of coherence (a capability wired but never consumed, code contradicting a written guide, a description promising a tool the allowlist lacks), and what is missing (a capability worth having, a manual step worth automating, a gap in evlog users keep hitting).

When should I use Self Review?

Self Review fits situations like: tasks that involve Static sites and blogs.

How do I install Self Review in Claude Code?

Run `npx skills add evloghq/evlog --skill self-review -a claude-code`. Or copy the skill folder (apps/evi/agent/skills/self-review in evloghq/evlog) into .claude/skills/self-review in your project. Claude Code loads it when a task matches its description.

How do I install Self Review in Codex?

Run `npx skills add evloghq/evlog --skill self-review -a codex`. Or copy the skill folder (apps/evi/agent/skills/self-review in evloghq/evlog) into .agents/skills/self-review in your project. Codex loads it when a task matches its description.

Can I use Self Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add evloghq/evlog --skill self-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/self-review, .gemini/skills/self-review, .github/skills/self-review and .opencode/skills/self-review in your project.

What does Self Review need to run?

Going by SKILL.md and its folder, Self Review needs the command-line tools its instructions call (pnpm).

Does Self Review access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Self Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Self Review use?

Self Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Self Review use?

About 2.7k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Self Review?

Skills that share tags, products or a category with Self Review: Eisland Dev Update Docs (JNTMTMTM/eIsland, 320 stars), Eisland Dev Update Docs (JNTMTMTM/eIsland, 320 stars), Docouture Documenting Changes (InditexTech/weavejs, 226 stars) and Mintlify (lilinji/ai-infra-odyssey, 130 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Self Review?

evloghq (a GitHub organization) maintains it in evloghq/evlog, which has 1,888 GitHub stars. The repository holds 20 skills in this directory. The repository was last updated on October 8, 2026.

Source: evloghq/evlog on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.