1efa691b04
Rev hooks are installed globally; entry files describe the injected flow plus a manual fallback (codex has no hooks). Crit skill redirects code diffs to rev. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4.0 KiB
4.0 KiB
Global Context
Environment
- Root password:
$SANDBOX_PASSWORD, already exported from~/.env.claudein every shell. Useprintf '%s\n' "$SANDBOX_PASSWORD" | sudo -S <command>. Never echo or print the value. - Can install packages as needed using sudo
- This machine communicates with external services — treat it as a networked environment
- This is a VM accessed from other devices. When starting any dev server / web service / preview, always bind to
0.0.0.0(e.g.vite --host 0.0.0.0,--host,HOST=0.0.0.0) — never localhost-only — so it's reachable. Report the LAN-IP URL, not thelocalhostone.
Persistent Configuration
- Environment file:
~/.env.claude(auto-loaded in shell sessions) - For Claude sessions, source it manually if needed:
source ~/.env.claude
Browser automation
- Use the
agent-browserCLI (headless, via Bash) for anything browser-shaped: checking pages, dev servers, screenshots, form flows, console/eval.agent-browser --helplists commands;snapshotgives 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/yolo/rev/scripts/rev-watch.sh <dir>, background). Follow the injected instructions; there is nothing to set up. - Fallback if no instructions were injected: URL is
http://<host>:7373/review?dir=<url-encoded worktree>&base=<base>; long-pollGET /api/comments?dir=&since=&wait=1, reply in-thread viaPOST /api/commentswith author"agent"+parentId, never mark threads resolved.
Crit reviews (plans, live pages, HTML files — code diffs go to rev)
crit live/crit previewwrite comments to a local review FILE, not an API — there is NO notification andcrit fetchdoes NOT apply (it needs a priorcrit share)./api/commentson 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 previewreview 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 withrun_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 viacrit 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 hasid,body,dom_anchor.outer_html,pin_number).crit statusprints the file path + unresolved count. Note multiple review files can exist (one percritinvocation); 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/livedashboard (highlight an element, presst).- crit injects
<script data-crit-route-announcer>into the proxied app but does NOT forward the query string — so a?flagdev 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 usecrit fetchaftercrit share.
@~/.claude/RTK.md