naps62
d7c62c8ce3
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>
41 lines
3.5 KiB
Markdown
41 lines
3.5 KiB
Markdown
# 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
|