review

Name: review
Author: entireio

203stars11forks

How to install review?

entireio/skills/review

$npx -y skills add entireio/skills --skill review

Installs into the current project.

Summary

Review code changes on the current branch using checkpoint transcript context to understand developer intent before auditing the diff. Use when the user asks for a code review, wants to review branch changes, or asks to audit recent work before merging.

Files · 1

View on GitHub

SKILL.md

1	# Review
2
3	Review code changes on the current branch by first reading checkpoint transcripts to
4	understand the intent behind each change, then auditing the actual diff for issues.
5	This produces an intent-aware review that catches mismatches between what the developer
6	wanted and what the code actually does.
7
8	## Response Format
9
10	Begin the first response to this skill invocation with the line:
11
12	`Entire Review:`
13
14	followed by a blank line, then the content.
15
16	- Apply the header to the first response of the invocation only. Do not re-print it on
17	follow-up turns within the same invocation.
18	- Do not include the header on error or early-exit responses (e.g. "not a git repository",
19	"no commits found between branch and base").
20
21	## Rules
22
23	1. This is a read-only audit. Do not modify any files during the review.
24	2. Always show a scope banner before findings so the user knows what is being reviewed.
25	3. If checkpoint context is unavailable, still perform the review using only the diff and
26	commit messages. Clearly state that the review lacks intent context.
27	4. Group findings by file. Within each file, order by severity (Critical > High > Medium > Low).
28	5. Every finding must include a concrete suggestion or explanation, not just flag the issue.
29	6. After presenting findings, ask the user if they want a fix plan. Do not auto-fix.
30	7. Do not review generated files, lock files, or binary files unless the user explicitly
31	asks for them.
32
33	## Process
34
35	### 1. Verify environment
36
37	Run `entire version` to check if the CLI is available. If it is not installed, note that
38	the review will proceed without checkpoint intent context (degraded mode).
39
40	### 2. Detect base ref
41
42	Find the mainline branch to diff against. Try these refs in order and use the first that
43	exists:
44
45	```bash
46	git rev-parse --verify origin/HEAD 2>/dev/null
47	git rev-parse --verify origin/main 2>/dev/null
48	git rev-parse --verify origin/master 2>/dev/null
49	git rev-parse --verify main 2>/dev/null
50	git rev-parse --verify master 2>/dev/null
51	```
52
53	If none exist, tell the user no base ref was found and ask them to specify one.
54
55	### 3. Compute scope
56
57	```bash
58	git rev-list --count <base>..HEAD
59	git diff --stat <base>..HEAD
60	```
61
62	Record the number of commits and files changed. This forms the scope banner.
63
64	### 4. Gather checkpoint intent (skip in degraded mode)
65
66	```bash
67	git log --format='%H%x00%s%x00%b' <base>..HEAD
68	```
69
70	Extract `Entire-Checkpoint:` trailer values from commit bodies. Deduplicate checkpoint IDs.
71
72	For each unique checkpoint ID (up to 20):
73
74	```bash
75	entire explain --checkpoint <checkpoint-id> --json --no-pager
76	```
77
78	Parse the JSON to extract session metadata. For each non-review session in the checkpoint,
79	prefer the summary (intent + outcome). If no summary is available, fall back to the latest
80	user prompt. Truncate each checkpoint detail to 320 characters.
81
82	If `--json` fails for a checkpoint, fall back to the bare human-readable output:
83
84	```bash
85	entire explain --checkpoint <checkpoint-id> --no-pager
86	```
87
88	Do not use `--full` in the review workflow — it produces long narrative text harder for
89	agents to parse in bulk. If that also fails, skip the checkpoint and note it was unavailable.
90
91	Additionally, read the current in-progress session (if any) for uncommitted work context:
92
93	```bash
94	entire session current --json
95	```
96
97	If this returns valid JSON, extract `last_prompt` and `files_touched` — these represent
98	the intent behind uncommitted changes that are not yet captured in any checkpoint.
99
100	Build an intent map: for each file in the diff (committed + uncommitted), collect the
101	relevant intent context from all checkpoints and the active session that touched it.
102
103	### 5. Read the diff
104
105	```bash
106	git diff <base>..HEAD
107	```
108
109	Also include uncommitted changes:
110
111	```bash
112	git diff HEAD
113	```
114
115	For large diffs (>5000 lines total), focus on the most critical files:
116	- Files with the most changes
117	- Files mentioned in checkpoint intents
118	- Source files over generated/config files
119
120	Read individual file diffs as needed rather than loading the entire diff at once.
121
122	### 6. Perform the review
123
124	Read the review rules:
125
126	```
127	references/review-rules.md
128	```
129
130	For each file in the diff, review it considering:
131
132	With checkpoint context:
133	- Does the implementation match the stated intent?
134	- Were the constraints from the transcript respected?
135	- Did the agent miss edge cases it discussed?
136	- Are there leftover debugging artifacts or TODOs?
137
138	Always (with or without context):
139	- Logic errors, off-by-one, null safety
140	- Security issues (injection, auth bypass, data exposure)
141	- Performance concerns (N+1 queries, unnecessary allocations)
142	- Error handling gaps
143	- API contract violations
144	- Dead code or unreachable branche

People who liked this also viewed

6 picks

Type

review

203stars11forks

View on GitHub

How to install review?

entireio/skills/review

$npx -y skills add entireio/skills --skill review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Review
2
3	Review code changes on the current branch by first reading checkpoint transcripts to
4	understand the intent behind each change, then auditing the actual diff for issues.
5	This produces an intent-aware review that catches mismatches between what the developer
6	wanted and what the code actually does.
7
8	## Response Format
9
10	Begin the first response to this skill invocation with the line:
11
12	`Entire Review:`
13
14	followed by a blank line, then the content.
15
16	- Apply the header to the first response of the invocation only. Do not re-print it on
17	follow-up turns within the same invocation.
18	- Do not include the header on error or early-exit responses (e.g. "not a git repository",
19	"no commits found between branch and base").
20
21	## Rules
22
23	1. This is a read-only audit. Do not modify any files during the review.
24	2. Always show a scope banner before findings so the user knows what is being reviewed.
25	3. If checkpoint context is unavailable, still perform the review using only the diff and
26	commit messages. Clearly state that the review lacks intent context.
27	4. Group findings by file. Within each file, order by severity (Critical > High > Medium > Low).
28	5. Every finding must include a concrete suggestion or explanation, not just flag the issue.
29	6. After presenting findings, ask the user if they want a fix plan. Do not auto-fix.
30	7. Do not review generated files, lock files, or binary files unless the user explicitly
31	asks for them.
32
33	## Process
34
35	### 1. Verify environment
36
37	Run `entire version` to check if the CLI is available. If it is not installed, note that
38	the review will proceed without checkpoint intent context (degraded mode).
39
40	### 2. Detect base ref
41
42	Find the mainline branch to diff against. Try these refs in order and use the first that
43	exists:
44
45	```bash
46	git rev-parse --verify origin/HEAD 2>/dev/null
47	git rev-parse --verify origin/main 2>/dev/null
48	git rev-parse --verify origin/master 2>/dev/null
49	git rev-parse --verify main 2>/dev/null
50	git rev-parse --verify master 2>/dev/null
51	```
52
53	If none exist, tell the user no base ref was found and ask them to specify one.
54
55	### 3. Compute scope
56
57	```bash
58	git rev-list --count <base>..HEAD
59	git diff --stat <base>..HEAD
60	```
61
62	Record the number of commits and files changed. This forms the scope banner.
63
64	### 4. Gather checkpoint intent (skip in degraded mode)
65
66	```bash
67	git log --format='%H%x00%s%x00%b' <base>..HEAD
68	```
69
70	Extract `Entire-Checkpoint:` trailer values from commit bodies. Deduplicate checkpoint IDs.
71
72	For each unique checkpoint ID (up to 20):
73
74	```bash
75	entire explain --checkpoint <checkpoint-id> --json --no-pager
76	```
77
78	Parse the JSON to extract session metadata. For each non-review session in the checkpoint,
79	prefer the summary (intent + outcome). If no summary is available, fall back to the latest
80	user prompt. Truncate each checkpoint detail to 320 characters.
81
82	If `--json` fails for a checkpoint, fall back to the bare human-readable output:
83
84	```bash
85	entire explain --checkpoint <checkpoint-id> --no-pager
86	```
87
88	Do not use `--full` in the review workflow — it produces long narrative text harder for
89	agents to parse in bulk. If that also fails, skip the checkpoint and note it was unavailable.
90
91	Additionally, read the current in-progress session (if any) for uncommitted work context:
92
93	```bash
94	entire session current --json
95	```
96
97	If this returns valid JSON, extract `last_prompt` and `files_touched` — these represent
98	the intent behind uncommitted changes that are not yet captured in any checkpoint.
99
100	Build an intent map: for each file in the diff (committed + uncommitted), collect the
101	relevant intent context from all checkpoints and the active session that touched it.
102
103	### 5. Read the diff
104
105	```bash
106	git diff <base>..HEAD
107	```
108
109	Also include uncommitted changes:
110
111	```bash
112	git diff HEAD
113	```
114
115	For large diffs (>5000 lines total), focus on the most critical files:
116	- Files with the most changes
117	- Files mentioned in checkpoint intents
118	- Source files over generated/config files
119
120	Read individual file diffs as needed rather than loading the entire diff at once.
121
122	### 6. Perform the review
123
124	Read the review rules:
125
126	```
127	references/review-rules.md
128	```
129
130	For each file in the diff, review it considering:
131
132	With checkpoint context:
133	- Does the implementation match the stated intent?
134	- Were the constraints from the transcript respected?
135	- Did the agent miss edge cases it discussed?
136	- Are there leftover debugging artifacts or TODOs?
137
138	Always (with or without context):
139	- Logic errors, off-by-one, null safety
140	- Security issues (injection, auth bypass, data exposure)
141	- Performance concerns (N+1 queries, unnecessary allocations)
142	- Error handling gaps
143	- API contract violations
144	- Dead code or unreachable branche

People who liked this also viewed

6 picks

Type