Eisland Dev Update Docs
JNTMTMTM/eIsland
Update or create documentation in the eIsland VuePress docs site (web/eisland-web-docs).
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…
$ npx skills add evloghq/evlog --skill self-review -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install evloghq/evlog self-review --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "self-review" agent skill from https://github.com/evloghq/evlog/tree/main/apps/evi/agent/skills/self-review into .claude/skills/self-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "self-review", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/evloghq/evlog/tree/main/apps/evi/agent/skills/self-reviewType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add evloghq/evlog --skill self-review -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install evloghq/evlog self-review --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/evloghq/evlog.git skills-src && mkdir -p .agents/skills && cp -r skills-src/apps/evi/agent/skills/self-review .agents/skills/self-review && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "self-review" agent skill from https://github.com/evloghq/evlog/tree/main/apps/evi/agent/skills/self-review into .agents/skills/self-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "self-review", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add evloghq/evlog --skill self-review -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install evloghq/evlog self-review --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/evloghq/evlog.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/apps/evi/agent/skills/self-review .cursor/skills/self-review && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "self-review" agent skill from https://github.com/evloghq/evlog/tree/main/apps/evi/agent/skills/self-review into .cursor/skills/self-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "self-review", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/evloghq/evlog.git --path apps/evi/agent/skills/self-review--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add evloghq/evlog --skill self-review -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install evloghq/evlog self-review --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/evloghq/evlog.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/apps/evi/agent/skills/self-review .gemini/skills/self-review && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "self-review" agent skill from https://github.com/evloghq/evlog/tree/main/apps/evi/agent/skills/self-review into .gemini/skills/self-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "self-review", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install evloghq/evlog self-reviewInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add evloghq/evlog --skill self-review -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/evloghq/evlog.git skills-src && mkdir -p .github/skills && cp -r skills-src/apps/evi/agent/skills/self-review .github/skills/self-review && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "self-review" agent skill from https://github.com/evloghq/evlog/tree/main/apps/evi/agent/skills/self-review into .github/skills/self-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "self-review", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add evloghq/evlog --skill self-review -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install evloghq/evlog self-review --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/evloghq/evlog.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/apps/evi/agent/skills/self-review .opencode/skills/self-review && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "self-review" agent skill from https://github.com/evloghq/evlog/tree/main/apps/evi/agent/skills/self-review into .opencode/skills/self-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "self-review", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
self-reviewWeekly 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). 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.
Read from SKILL.md and the folder at commit 54dcc50. It shows what the files ask for, not the result of running them.
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.
Shell commands in SKILL.md call:
pnpmFrom the folder's file list and the shell code blocks in SKILL.md.
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.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
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.
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.
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.
The full file from evloghq/evlog at commit 54dcc50, republished under its MIT licence (© evloghq). 1,629 words, ~2,732 tokens.
.claude/skills/self-review/SKILL.md (or your agent's skills folder).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.
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.
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.
state, channel metadata. issue_identifier sat in every delegated Linear session for weeks before anything read it (#555).agent/lib/ and returned to no one.agent/lib/ module with a colocated test and no import outside that test.| 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 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.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. |
Read the strings the model actually sees against the tools it actually has.
agent/connections/*.ts: does the description name a capability the tools.allow list omits?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.instructions.md names must be writable from the posture that reads it.Read-only, and these become issues, never PRs.
telemetry-stats: an error code climbing week over week, a command whose success rate is falling.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.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.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.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.The cheapest new capability is one already connected.
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.The strongest proposals come from your own friction, and it is only visible from the inside.
capability-placement.md and needs no code.capability-placement.md states the observed trigger for a subagent; cite it or do not propose one.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.telemetry-stats with no docs page covering it is a docs proposal with a number attached.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.
The failure mode of this run is a confident output that is wrong, and the expensive version is claiming something does not exist.
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.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.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.
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.
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
Just SKILL.md in apps/evi/agent/skills/self-review of evloghq/evlog.
Open the folder on GitHubat commit 54dcc50
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Self Review this skillevloghq/evlog | 1.9k | — | ~2.7k | Automated safety check: Pass | MIT | |
| Eisland Dev Update DocsJNTMTMTM/eIsland | 320 | — | ~1.4k | Automated safety check: Pass | GPL-3.0 | |
| Eisland Dev Update DocsJNTMTMTM/eIsland | 320 | — | ~1.8k | Automated safety check: Pass | GPL-3.0 | |
| Docouture Documenting ChangesInditexTech/weavejs | 226 | — | ~1.3k | Automated safety check: Pass | Apache-2.0 | |
| Mintlifylilinji/ai-infra-odyssey | 130 | — | ~2.9k | Automated safety check: Pass | None | |
| DocsChorus-AIDLC/Chorus | 1.2k | — | ~1.2k | Automated safety check: Pass | AGPL-3.0 |
JNTMTMTM/eIsland
Update or create documentation in the eIsland VuePress docs site (web/eisland-web-docs).
JNTMTMTM/eIsland
Update or create documentation in the eIsland VuePress docs site (web/eisland-web-docs).
InditexTech/weavejs
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…
lilinji/ai-infra-odyssey
Comprehensive reference for building Mintlify documentation sites.
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).
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).
evloghq/evlog
Walks through adding a new built-in evlog drain adapter for an observability platform: source, build config, exports, tests, docs and PR scope.
evloghq/evlog
Guides adding a new built-in enricher to the evlog package, covering the source, tests, docs, README, a related skill and a changeset.
evloghq/evlog
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.
evloghq/evlog
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.
evloghq/evlog
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.
evloghq/evlog
Produce a before/after visual comparison of an evlog surface (landing, docs, telemetry, playgrounds) and share it as public Blob URLs.
Categories
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).
Self Review fits situations like: tasks that involve Static sites and blogs.
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.
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.
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.
Going by SKILL.md and its folder, Self Review needs the command-line tools its instructions call (pnpm).
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.
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.
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.
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.
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.
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.