Files
agent-skills/entry/CLAUDE.md
T
naps62 d7c62c8ce3 feat: split machine-specific section out of CLAUDE.md
The entry file assumed passwordless root and LAN-exposed dev servers,
which is only true on yolo. It now @imports ~/.claude/machine.md, linked
from claude-md/machines/<name>.md via programs.agentSkills.machine.
Defaults to the conservative profile.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 08:38:01 +00:00

3.5 KiB

Global Context

@~/.claude/machine.md

Browser automation

  • Use the agent-browser CLI (headless, via Bash) for anything browser-shaped: checking pages, dev servers, screenshots, form flows, console/eval. agent-browser --help lists commands; snapshot gives an accessibility tree with refs for AI use.
  • The claude-in-chrome extension is disabled by default. Only reach for it if the task genuinely needs my real logged-in browser session or open tabs — and if its tools aren't available, ask me to enable it rather than working around it.

@~/.claude/writing.md

@~/.claude/operating.md

Rev code reviews

  • Code-change reviews use the always-on rev server on :7373. A review is just a URL — never start crit or any per-review server for code diffs.
  • Global hooks do the plumbing: SessionStart injects the review URL and full instructions in any rev-known repo, and a Stop hook prompts to (re)arm the comment watcher (~/tea/rev/scripts/rev-watch.sh <dir>, background). Follow the injected instructions; there is nothing to set up.
  • The watcher is plumbing: arm and re-arm it silently, never announce its state (armed, exited, re-armed) in chat.
  • Fallback if no instructions were injected: the URL to hand me is https://rev.n62.casa/review?dir=<url-encoded worktree>&base=<base>, while the API to call is http://localhost:7373; long-poll GET /api/comments?dir=&since=&wait=1, reply in-thread via POST /api/comments with author "agent" + parentId and a real multi-line markdown body (pipe a heredoc through jq -Rs, never a body inlined on one line), never mark threads resolved.

Crit reviews (plans, live pages, HTML files — code diffs go to rev)

  • crit live / crit preview write comments to a local review FILE, not an API — there is NO notification and crit fetch does NOT apply (it needs a prior crit share). /api/comments on the daemon is the WRONG place (stays []). If I launched the crit server myself, I must poll the review file myself.
  • Whenever I start a crit live/crit preview review for the user, immediately arm the watcher so they don't have to babysit it: ~/.claude/scripts/crit-watch.sh — run it via the Bash tool with run_in_background: true. It auto-finds the active live/preview review file (~/.crit/reviews/<id>/review.json), baselines existing comment IDs, and re-invokes me with any NEW comments once they settle. When it fires: read the comments, address them, reply to each via crit comment --reply-to <id> <body>, then re-arm the watcher. Keep doing this until the user says they're done.
  • Review file shape: comments live under .files["<path>"].comments[] (each has id, body, dom_anchor.outer_html, pin_number). crit status prints the file path + unresolved count. Note multiple review files can exist (one per crit invocation); the watcher picks the most-recently-updated live/preview one.
  • crit live <url> serves TWO ports: the app proxy (target port + 1, e.g. :41701) with crit's overlay injected, and the review dashboard at :<api>/live (e.g. :41700/live) which also renders the proxied app. The user comments on the /live dashboard (highlight an element, press t).
  • crit injects <script data-crit-route-announcer> into the proxied app but does NOT forward the query string — so a ?flag dev toggle won't reach the app under crit; detect the injected marker instead.
  • For GitHub PR reviews use crit pull (comments live on GitHub); for shared web reviews use crit fetch after crit share.

@~/.claude/RTK.md