nebula: Skill for Claude Code

A pull request review here answers one question first: what happens to the people running nebula in production if this merges? Nebula is a DAEMON that owns every agent PTY on a developer's box, speaks to its TUI over an unauthenticated DAEMON SOCKET, installs MANAGED HOOKS into the user's own ~/.claude, ~/.codex, ~/.cursor and ~/.pi, spawns claude / codex / cursor-agent / pi with a composed argv and system prompt, runs curl | sh on remote hosts over NEBULA SSH, and migrates a SQLITE STORE on every user's disk at the first launch of a new binary. A wrong line in the wrong place is not a bug report; it is every user's sessions gone, or every user's shell running someone else's script. So the review weighs security and merge risk first and hardest, performance second, and fit with the codebase's patterns third — and says which of the three every finding belongs to.

The second rule shapes everything else: the reviewer reads; it never runs. Not the PR's code, not its tests, not the build, not the binary, not a script the PR adds. Three reasons, each sufficient on its own. A PR — above all one from a fork (isCrossRepository: true) — is untrusted input, and even cargo check executes its build.rs and proc-macros as you, with your gh token, ~/.claude and ssh keys in reach. The SHARED CHECKOUT belongs to several sessions at once, so a gh pr checkout, a merge or a stash yanks the tree out from under them. And a review that says "I ran the tests" asserts something the reader cannot audit anyway: CI's verdict is the test gate — and on this repo nothing on GitHub builds or tests a PR at all (claude-code-review.yml is the only PR workflow; release.yml runs on tags), which is itself a fact the review states. What reading cannot settle goes into the review as unsettled, named precisely enough that a human can run it. It is never quietly run.

Read, never run

Allowed — every one of these is a read: it touches no working tree and executes nothing from the PR.

gh pr view <n> --json …                          # metadata, description, files, checks, reviews
gh pr diff <n>                                   # the unified diff
gh pr checks <n>                                 # CI state as GitHub reports it (exit 8 = pending)
gh api repos/<owner>/<repo>/pulls/<n>/comments   # inline review comments — not a --json field
git fetch origin && git fetch origin pull/<n>/head   # refresh origin/<base>; the PR head lands in FETCH_HEAD, no ref, no checkout
git merge-base origin/<base> <headRefOid>        # the commit the PR branched from — origin/<base> has moved on since, and is not the base
git show <headRefOid>:<path>                     # the PR's whole file (the SHA is stable; FETCH_HEAD is not, other sessions fetch too)
git show <mergeBase>:<path>                      # the same file as the PR saw it — what `gh pr diff` is relative to
git log · git grep · grep · cat · sed -n · wc · diff   # over files, never through them

Forbidden, whatever the PR is — when a review seems to need one of these, it needs a human instead:

• cargo anything, including cargo check, cargo fmt --check, cargo clippy, cargo metadata and cargo tree — build scripts and proc-macros run under all of them; make anything; the nebula binary or anything under target/; INSTALL.SH; python3, node, sh, bash, source on any file the PR adds or changes — reading a script means cat, not sh -n.
• gh pr checkout, git checkout, git switch, git merge, git rebase, git apply, git cherry-pick, git stash, git worktree add, git reset — nothing that moves the SHARED CHECKOUT or creates a tree; editing or creating any file inside the repo. Nothing from the PR ever lands on disk; the review itself is written to the scratchpad, outside the repo.
• gh pr review --approve, gh pr review --request-changes, gh pr merge, gh pr edit, gh pr close, gh pr comment — the skill posts exactly one --comment review and changes nothing else about the PR. Approval is a human's signature.