@tduyng/pi-review 0.0.3 → 0.0.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +23 -41
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,55 +1,30 @@
|
|
|
1
1
|
# @tduyng/pi-review
|
|
2
2
|
|
|
3
|
-
`/review`
|
|
3
|
+
`/review` reviews from git ground truth. It resolves the target from the repository, sends one prompt with the diff attached, and advances a checkpoint so the next run covers only what moved.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
A review from memory covers code the model remembers writing, and re-reviews the parts already fixed.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
## How it works
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
A bare `/review` asks git what changed since the last checkpoint. With nothing there it takes what is uncommitted, and with nothing there either, this branch against its merge base.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
The command writes its snapshot through a throwaway `GIT_INDEX_FILE`. That produces a dangling tree with no ref and no commit, so repository history stays untouched. The checkpoint is that same tree, and a review moves it.
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
A `--staged` review, or one with a described target, leaves the checkpoint where it was, so unstaged work is not skipped next time.
|
|
14
14
|
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
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.
|
|
18
|
-
|
|
19
|
-
## Targets
|
|
20
|
-
|
|
21
|
-
A bare `/review` resolves in code, with no model in the loop:
|
|
22
|
-
|
|
23
|
-
1. The staged changes, with `--staged`.
|
|
24
|
-
2. What moved since the last snapshot, if that snapshot still exists.
|
|
25
|
-
3. Any uncommitted work, untracked files included.
|
|
26
|
-
4. This branch against its merge base with the default branch.
|
|
27
|
-
|
|
28
|
-
## Options
|
|
29
|
-
|
|
30
|
-
- `/review [target]`. Bare resolves as above, anything else passes through.
|
|
31
|
-
- `--lean` adds a second pass for removable implementation complexity in the same change, and prints `Lean already.` when there is none.
|
|
32
|
-
- `--extra "<text>"` gives acceptance criteria, repeatable, last wins.
|
|
33
|
-
- `--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.
|
|
34
|
-
- `--staged` reviews only the staged changes.
|
|
35
|
-
|
|
36
|
-
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.
|
|
15
|
+
## Commands
|
|
37
16
|
|
|
38
17
|
```text
|
|
39
|
-
/review
|
|
40
|
-
/review
|
|
41
|
-
/review the
|
|
42
|
-
/review --lean
|
|
43
|
-
/review --model
|
|
18
|
+
/review what moved since the last review, else uncommitted, else the branch base
|
|
19
|
+
/review src/session.ts a target you describe, passed to the prompt as written
|
|
20
|
+
/review --staged the index only
|
|
21
|
+
/review --lean the review prompt without the rubric
|
|
22
|
+
/review --model provider/id run the review on another model
|
|
23
|
+
/review --extra "check error paths" add an instruction
|
|
24
|
+
/review --base main compare against another base
|
|
44
25
|
```
|
|
45
26
|
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
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.
|
|
49
|
-
|
|
50
|
-
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.
|
|
51
|
-
|
|
52
|
-
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.
|
|
27
|
+
The command caps the reply at 15 lines and eight tool calls in total, including the calls that resolve the target. A review that needs more than eight calls has started refactoring.
|
|
53
28
|
|
|
54
29
|
## Install
|
|
55
30
|
|
|
@@ -59,4 +34,11 @@ pi install npm:@tduyng/pi-review
|
|
|
59
34
|
|
|
60
35
|
Local checkout: `pi install /path/to/dotfiles/pi/agent/extensions/pi-review`
|
|
61
36
|
|
|
62
|
-
|
|
37
|
+
It needs `git` on PATH and a git repository. Outside one, the command says so and stops. `--model` uses the `subagent` tool when it is installed, and runs inline on the current model when it is not.
|
|
38
|
+
|
|
39
|
+
## Limits
|
|
40
|
+
|
|
41
|
+
- The diff is capped at 12,000 characters. A larger change needs two reviews or a narrower target.
|
|
42
|
+
- A review is one pass. A model asked to re-review its own findings mostly finds its earlier findings.
|
|
43
|
+
- The checkpoint lives as a session entry, so a new session starts from the last one in the same repository. A fresh clone starts from nothing.
|
|
44
|
+
- Snapshot trees are unreferenced by design, so git's pruning collects them after about two weeks. A checkpoint older than that resolves to a full review.
|