@tduyng/pi-review 0.0.2 → 0.0.3

package/README.md

@@ -1,45 +1,41 @@
 # @tduyng/pi-review
 
-A `/review` command that works out what to review and sends one focused review prompt.
+`/review` that works out what changed and pays only for that. Every run snapshots the worktree, so the next one reviews the delta instead of the branch.
+
+## What it costs
+
+No tool, no schema, no system prompt block. A slash command and a snapshot object that git prunes on its own.
+
+The saving is the second review of the same code. A branch reviewed after every commit costs one diff the first time and one commit's diff after that, rather than the whole branch four times.
 
 ## The incremental loop
 
-Every bare `/review` snapshots the whole worktree (tracked and untracked) as a dangling git commit. No ref, no stash change, no branch commit. The snapshot sha sits in the session as a custom entry that never enters model context.
+Every bare `/review` snapshots the worktree, tracked and untracked, as a dangling git commit. No ref, no stash entry, no branch commit. The snapshot sha sits in the session as a custom entry that never enters model context.
 
-Run `/review` and the agent reviews what moved since the last run. The delta is a tree-to-tree diff, so it covers edits to files that were untracked at checkpoint time and deletions of tracked files. When nothing moved, the command says so and sends nothing.
+The next `/review` reviews what moved since. The delta is a tree-to-tree diff, so it covers edits to files that were untracked at checkpoint time and deletions of tracked files. When nothing moved, the command says so and sends nothing, which is the cheapest review there is.
 
-The checkpoint moves only after a review has read that work. `--staged` and a described target leave it alone, so their unstaged work is still waiting for the next bare `/review`. A branch review records HEAD, not the worktree, so uncommitted edits stay in the next delta. Git prunes the snapshot objects after roughly two weeks, and a pruned snapshot falls back to the default below. In an ephemeral `--no-session` run the snapshot lasts only for that process.
+The checkpoint moves only after a review has read that work. `--staged` and a described target leave it alone, so their unstaged work is still waiting for the next bare `/review`. A branch review records HEAD rather than the worktree, so uncommitted edits stay in the next delta. Git prunes the snapshot objects after about two weeks, and a pruned snapshot falls back to the default target. In an ephemeral `--no-session` run the snapshot lasts only for that process.
 
 ## Targets
 
-A bare `/review` is resolved in code, with no model in the loop:
+A bare `/review` resolves in code, with no model in the loop:
 
-1. The staged changes with `--staged`, which names the target outright, whatever the snapshot says.
+1. The staged changes, with `--staged`.
 2. What moved since the last snapshot, if that snapshot still exists.
 3. Any uncommitted work, untracked files included.
 4. This branch against its merge base with the default branch.
 
-## What it adds
-
-- `/review [target]`. Bare resolves as above, anything else is passed through.
-- `--lean`. Adds a second pass for removable implementation complexity in the same change, and prints `Lean already.` when there is none.
-- `--extra "<text>"`. Acceptance criteria for the review. Repeatable, last wins.
-- `--model provider/model`. Runs the review on that model through the `subagent` tool. Without that tool the review runs inline and says the override could not be honored.
-- `--staged`. Reviews only the staged changes.
-
-Anything you type is the reviewer's request and goes to the prompt as written: `/review the change between main and HEAD`, `/review src/auth`, `/review first commit on this branch`. The prompt caps target resolution at three commands and tells the reviewer not to narrate them.
-
-## Focused review contract
-
-The extension resolves the diff and hands it over with two lines of context around each change, so the reviewer spends no tool calls on git. The diff is capped at 12,000 characters. Past that the stat still lists every file, and the reviewer is told how many characters it did not read.
+## Options
 
-The reviewer writes the change's intent in one line first and judges the implementation against it. Supplied criteria replace that line. It reads the diff before opening any file, opens at most two files the diff does not already show, and runs at most one targeted command, all inside a budget of eight tool calls including any target resolution.
+- `/review [target]`. Bare resolves as above, anything else passes through.
+- `--lean` adds a second pass for removable implementation complexity in the same change, and prints `Lean already.` when there is none.
+- `--extra "<text>"` gives acceptance criteria, repeatable, last wins.
+- `--model provider/model` runs the review on that model through the `subagent` tool. Without that tool the review runs inline and says the override could not be honored.
+- `--staged` reviews only the staged changes.
 
-The response is under 15 lines: a verdict, the intent line, one line per finding with a P0 to P3 severity and a concrete fix, and one `Checks:` line.
+Anything you type is the reviewer's request and reaches the prompt as written: `/review the change between main and HEAD`, `/review src/auth`, `/review first commit on this branch`. Target resolution is capped at three commands, and the reviewer is told not to narrate them.
 
-## Examples
-
-```
+```text
 /review                                    # what moved, or the branch default
 /review --staged                           # staged changes only
 /review the change between main and HEAD   # any target you describe
@@ -47,6 +43,14 @@ The response is under 15 lines: a verdict, the intent line, one line per finding
 /review --model opencode-go/gpt-6-luna the retry logic
 ```
 
+## The contract
+
+The extension resolves the diff and hands it over with two lines of context around each change, so the reviewer spends no tool calls on git. The diff is capped at 12,000 characters. Past that the stat still lists every file and the reviewer is told how many characters it did not read.
+
+The reviewer writes the change's intent in one line first and judges the implementation against it, unless you supplied criteria. It reads the diff before opening any file, opens at most two files the diff does not already show, and runs at most one targeted command, all inside a budget of eight tool calls including target resolution.
+
+The reply is under 15 lines: a verdict, the intent line, one line per finding with a P0 to P3 severity and a concrete fix, and one `Checks:` line.
+
 ## Install
 
 ```bash
@@ -55,6 +59,4 @@ pi install npm:@tduyng/pi-review
 
 Local checkout: `pi install /path/to/dotfiles/pi/agent/extensions/pi-review`
 
-## Configure
-
-None. It works out of the box inside a git repository.
+No configuration. It works inside any git repository.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@tduyng/pi-review",
-  "version": "0.0.2",
-  "description": "/review resolves a target from git, collects project ground truth, and sends a structured review prompt inline or through a subagent.",
+  "version": "0.0.3",
+  "description": "Review only the delta. /review snapshots the worktree, so the next run pays for what moved since.",
   "keywords": [
     "pi",
     "pi-package",