@in-the-loop-labs/pair-review 3.2.2 → 3.2.3
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/package.json +1 -1
- package/plugin/.claude-plugin/plugin.json +1 -1
- package/plugin-code-critic/.claude-plugin/plugin.json +1 -1
- package/plugin-code-critic/skills/analyze/references/orchestration-balanced.md +9 -1
- package/plugin-code-critic/skills/analyze/references/orchestration-fast.md +8 -1
- package/plugin-code-critic/skills/analyze/references/orchestration-thorough.md +8 -7
- package/public/js/modules/analysis-history.js +11 -7
- package/src/ai/prompts/baseline/consolidation/balanced.js +6 -4
- package/src/ai/prompts/baseline/consolidation/fast.js +6 -2
- package/src/ai/prompts/baseline/consolidation/thorough.js +7 -6
- package/src/ai/prompts/baseline/orchestration/balanced.js +13 -1
- package/src/ai/prompts/baseline/orchestration/fast.js +12 -1
- package/src/ai/prompts/baseline/orchestration/thorough.js +8 -7
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "pair-review",
|
|
3
|
-
"version": "3.2.
|
|
3
|
+
"version": "3.2.3",
|
|
4
4
|
"description": "pair-review app integration — Open PRs and local changes in the pair-review web UI, run server-side AI analysis, and address review feedback. Requires the pair-review MCP server.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "in-the-loop-labs",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "code-critic",
|
|
3
|
-
"version": "3.2.
|
|
3
|
+
"version": "3.2.3",
|
|
4
4
|
"description": "AI-powered code review analysis — Run three-level AI analysis and implement-review-fix loops directly in your coding agent. Works standalone, no server required.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "in-the-loop-labs",
|
|
@@ -97,6 +97,14 @@ Prioritize suggestions in this order:
|
|
|
97
97
|
- **Preserve reviewer autonomy** - you're a pair programming partner, not an enforcer
|
|
98
98
|
- **Provide context** for why each suggestion matters to the reviewer
|
|
99
99
|
|
|
100
|
+
## Summary Structure
|
|
101
|
+
The summary field should synthesize the findings, but it should not be one big paragraph.
|
|
102
|
+
- Start with 1-2 sentences describing the overall assessment
|
|
103
|
+
- Then include a markdown bullet list using "- " bullets for the key specific points
|
|
104
|
+
- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
|
|
105
|
+
- Focus on WHAT was found, not HOW it was found
|
|
106
|
+
- Write as if a single reviewer produced this analysis
|
|
107
|
+
|
|
100
108
|
## Output Format
|
|
101
109
|
|
|
102
110
|
**>>> CRITICAL: Output ONLY valid JSON. No markdown, no ```json blocks. Start with { end with }. <<<**
|
|
@@ -126,7 +134,7 @@ Output JSON with this structure:
|
|
|
126
134
|
"confidence": 0.0-1.0,
|
|
127
135
|
"reasoning": ["Step-by-step reasoning explaining why this issue was flagged (optional)"]
|
|
128
136
|
}],
|
|
129
|
-
"summary": "
|
|
137
|
+
"summary": "Formatted markdown summary following the Summary Structure guidance above."
|
|
130
138
|
}
|
|
131
139
|
|
|
132
140
|
### GitHub Suggestion Syntax
|
|
@@ -76,6 +76,13 @@ Max 2-3 praise items. Prefer line-level over file-level. Include actionable sugg
|
|
|
76
76
|
### Framing
|
|
77
77
|
Use "Consider...", "Worth noting..." - guidance not mandates.
|
|
78
78
|
|
|
79
|
+
### Summary
|
|
80
|
+
The summary field should be markdown, not one big paragraph.
|
|
81
|
+
- Start with 1-2 sentences describing the overall assessment
|
|
82
|
+
- Then include a markdown bullet list using "- " bullets for the key specific points
|
|
83
|
+
- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
|
|
84
|
+
- Write as a single reviewer; do not mention levels or orchestration
|
|
85
|
+
|
|
79
86
|
## JSON Schema
|
|
80
87
|
{
|
|
81
88
|
"level": "orchestrated",
|
|
@@ -99,7 +106,7 @@ Use "Consider...", "Worth noting..." - guidance not mandates.
|
|
|
99
106
|
"suggestion": "How to fix (omit for praise)",
|
|
100
107
|
"confidence": 0.0-1.0
|
|
101
108
|
}],
|
|
102
|
-
"summary": "
|
|
109
|
+
"summary": "Formatted markdown summary following the Summary guidance above."
|
|
103
110
|
}
|
|
104
111
|
|
|
105
112
|
### GitHub Suggestion Syntax
|
|
@@ -212,20 +212,21 @@ Frame all suggestions as guidance for a human reviewer, not automated mandates:
|
|
|
212
212
|
Note: Confidence is about certainty of value, not severity. A minor improvement suggestion can have high confidence if you're sure it's helpful.
|
|
213
213
|
|
|
214
214
|
## Summary Synthesis Guidance
|
|
215
|
-
The summary field
|
|
215
|
+
The summary field should help the reviewer see the forest, not just the trees, but it should not be one big paragraph.
|
|
216
216
|
|
|
217
217
|
**Effective Summary Approach:**
|
|
218
|
-
- **
|
|
219
|
-
- **
|
|
220
|
-
- **Connect the dots**:
|
|
221
|
-
- **Calibrate severity**:
|
|
218
|
+
- **Start with 1-2 sentences of overall assessment**: Identify the overarching narrative of this PR's quality and concerns
|
|
219
|
+
- **Then use a markdown bullet list with "- " bullets**: Capture the key specific points the reviewer should track
|
|
220
|
+
- **Connect the dots**: Make the overview and bullets feel like one coherent review
|
|
221
|
+
- **Calibrate severity**: Make clear whether this PR is fundamentally sound with minor issues or has structural problems
|
|
222
|
+
- **After the bullets, add extra sentences or short paragraphs only when needed**: Use them for requested context, caveats, or follow-up detail
|
|
222
223
|
- **Respect reviewer time**: A good summary lets the reviewer decide where to focus attention
|
|
223
224
|
|
|
224
225
|
**Summary Anti-patterns to Avoid:**
|
|
225
226
|
- Listing findings ("Found 3 bugs, 2 improvements, 1 praise...")
|
|
226
227
|
- Implementation details ("Merged Level 1 and Level 2 suggestions...")
|
|
227
228
|
- Vague platitudes ("This PR has some issues to consider...")
|
|
228
|
-
-
|
|
229
|
+
- A single unbroken paragraph with no bullets
|
|
229
230
|
|
|
230
231
|
## Output Format
|
|
231
232
|
|
|
@@ -256,7 +257,7 @@ Output JSON with this structure:
|
|
|
256
257
|
"confidence": 0.0-1.0,
|
|
257
258
|
"reasoning": ["Step-by-step reasoning explaining why this issue was flagged"]
|
|
258
259
|
}],
|
|
259
|
-
"summary": "
|
|
260
|
+
"summary": "Formatted markdown summary following the Summary Synthesis Guidance above."
|
|
260
261
|
}
|
|
261
262
|
|
|
262
263
|
### GitHub Suggestion Syntax
|
|
@@ -205,9 +205,11 @@ class AnalysisHistoryManager {
|
|
|
205
205
|
/**
|
|
206
206
|
* Load analysis runs from the API (initial load only)
|
|
207
207
|
*
|
|
208
|
-
* This method is intended for initial page load
|
|
209
|
-
*
|
|
210
|
-
*
|
|
208
|
+
* This method is intended for initial page load. On first load it selects the
|
|
209
|
+
* latest run; on subsequent calls it preserves the current selection when that
|
|
210
|
+
* run still exists. For refreshing after a new analysis completes, use
|
|
211
|
+
* refresh(), which has logic to optionally preserve the user's current
|
|
212
|
+
* selection while surfacing a new run indicator.
|
|
211
213
|
*
|
|
212
214
|
* @returns {Promise<Array>} The loaded runs
|
|
213
215
|
*/
|
|
@@ -227,11 +229,13 @@ class AnalysisHistoryManager {
|
|
|
227
229
|
return [];
|
|
228
230
|
}
|
|
229
231
|
|
|
230
|
-
// Always select the latest run (first in the list since they're ordered by date DESC)
|
|
231
|
-
// This ensures that after a new analysis completes, its results are displayed
|
|
232
232
|
const latestRun = this.runs[0];
|
|
233
|
-
const
|
|
234
|
-
|
|
233
|
+
const currentRun = this.selectedRunId
|
|
234
|
+
? this.runs.find(run => String(run.id) === String(this.selectedRunId))
|
|
235
|
+
: null;
|
|
236
|
+
const runToSelect = currentRun || latestRun;
|
|
237
|
+
const shouldTriggerCallback = String(this.selectedRunId) !== String(runToSelect.id);
|
|
238
|
+
await this.selectRun(runToSelect.id, shouldTriggerCallback);
|
|
235
239
|
|
|
236
240
|
// Render the dropdown (after selecting so the selected state is correct)
|
|
237
241
|
this.renderDropdown(this.runs);
|
|
@@ -123,9 +123,11 @@ Assess severity based on the evidence and reasoning across all reviewers. When r
|
|
|
123
123
|
|
|
124
124
|
<section name="summary-synthesis" required="true">
|
|
125
125
|
## Summary Synthesis
|
|
126
|
-
The summary field should synthesize the findings, not
|
|
127
|
-
-
|
|
128
|
-
-
|
|
126
|
+
The summary field should synthesize the findings, but it should not be one big paragraph.
|
|
127
|
+
- Start with 1-2 sentences describing the overall assessment
|
|
128
|
+
- Then include a markdown bullet list using "- " bullets for the key specific points
|
|
129
|
+
- **Draw on reviewer summaries**: Use these as evidence for your own synthesis — integrate their insights into the overview and bullets rather than listing reviewer-by-reviewer conclusions
|
|
130
|
+
- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
|
|
129
131
|
- Write as if a single reviewer produced this analysis — do not mention consolidation, merging, or multiple reviewers
|
|
130
132
|
</section>
|
|
131
133
|
|
|
@@ -160,7 +162,7 @@ Output JSON with this structure:
|
|
|
160
162
|
"confidence": 0.0-1.0,
|
|
161
163
|
"reasoning": ["Step-by-step reasoning explaining why this issue was flagged (optional)"]
|
|
162
164
|
}],
|
|
163
|
-
"summary": "
|
|
165
|
+
"summary": "Formatted markdown summary following the Summary Synthesis guidance above."
|
|
164
166
|
}
|
|
165
167
|
|
|
166
168
|
### GitHub Suggestion Syntax
|
|
@@ -83,7 +83,11 @@ Deduplicate, don't concatenate: merge duplicate findings, preserve distinct ones
|
|
|
83
83
|
</section>
|
|
84
84
|
|
|
85
85
|
<section name="summary-synthesis" required="true" tier="fast">
|
|
86
|
-
Draw on reviewer summaries as evidence for your own synthesis.
|
|
86
|
+
Draw on reviewer summaries as evidence for your own synthesis. The summary field should be markdown, not one big paragraph.
|
|
87
|
+
- Start with 1-2 sentences describing the overall assessment
|
|
88
|
+
- Then include a markdown bullet list using "- " bullets for the key specific points
|
|
89
|
+
- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
|
|
90
|
+
- Write as a single reviewer with no mention of consolidation or merging
|
|
87
91
|
</section>
|
|
88
92
|
|
|
89
93
|
<section name="output-schema" locked="true">
|
|
@@ -109,7 +113,7 @@ Draw on reviewer summaries as evidence for your own synthesis. Write one cohesiv
|
|
|
109
113
|
"suggestion": "How to address the file-level concern (omit for praise items)",
|
|
110
114
|
"confidence": 0.0-1.0
|
|
111
115
|
}],
|
|
112
|
-
"summary": "
|
|
116
|
+
"summary": "Formatted markdown summary following the summary guidance above."
|
|
113
117
|
}
|
|
114
118
|
|
|
115
119
|
### GitHub Suggestion Syntax
|
|
@@ -167,13 +167,14 @@ Note: Confidence is about certainty of value, not severity.
|
|
|
167
167
|
|
|
168
168
|
<section name="summary-synthesis" required="true" tier="thorough">
|
|
169
169
|
## Summary Synthesis Guidance
|
|
170
|
-
The summary field should synthesize the findings, not
|
|
170
|
+
The summary field should synthesize the findings, but it should not be one big paragraph.
|
|
171
171
|
|
|
172
172
|
**Effective Summary Approach:**
|
|
173
|
-
- **Lead with the most important insight
|
|
174
|
-
- **
|
|
175
|
-
- **
|
|
176
|
-
- **Draw on reviewer summaries**: Use these as evidence for your own synthesis — integrate their insights into
|
|
173
|
+
- **Start with 1-2 sentences of overall assessment**: Lead with the most important insight and calibrate the overall severity
|
|
174
|
+
- **Then use a markdown bullet list with "- " bullets**: Capture the key specific points the reviewer should keep in view
|
|
175
|
+
- **Connect the dots**: Make the overview and bullets feel like one coherent review, not disconnected fragments
|
|
176
|
+
- **Draw on reviewer summaries**: Use these as evidence for your own synthesis — integrate their insights into the overview and bullets rather than listing reviewer-by-reviewer conclusions.
|
|
177
|
+
- **After the bullets, add extra sentences or short paragraphs only when needed**: Use them for requested context, caveats, or follow-up detail
|
|
177
178
|
- **Write as a single reviewer**: Do not mention consolidation, merging, or multiple reviewers -- unless specifically requested
|
|
178
179
|
</section>
|
|
179
180
|
|
|
@@ -208,7 +209,7 @@ Output JSON with this structure:
|
|
|
208
209
|
"confidence": 0.0-1.0,
|
|
209
210
|
"reasoning": ["Step-by-step reasoning explaining why this issue was flagged"]
|
|
210
211
|
}],
|
|
211
|
-
"summary": "
|
|
212
|
+
"summary": "Formatted markdown summary following the Summary Synthesis Guidance above."
|
|
212
213
|
}
|
|
213
214
|
|
|
214
215
|
### GitHub Suggestion Syntax
|
|
@@ -121,6 +121,16 @@ Prioritize suggestions in this order:
|
|
|
121
121
|
- **Provide context** for why each suggestion matters to the reviewer
|
|
122
122
|
</section>
|
|
123
123
|
|
|
124
|
+
<section name="summary-synthesis" required="true">
|
|
125
|
+
## Summary Structure
|
|
126
|
+
The summary field should synthesize the findings, but it should not be one big paragraph.
|
|
127
|
+
- Start with 1-2 sentences describing the overall assessment
|
|
128
|
+
- Then include a markdown bullet list using "- " bullets for the key specific points
|
|
129
|
+
- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
|
|
130
|
+
- Focus on WHAT was found, not HOW it was found
|
|
131
|
+
- Write as if a single reviewer produced this analysis
|
|
132
|
+
</section>
|
|
133
|
+
|
|
124
134
|
<section name="output-schema" locked="true">
|
|
125
135
|
## Output Format
|
|
126
136
|
|
|
@@ -151,7 +161,7 @@ Output JSON with this structure:
|
|
|
151
161
|
"confidence": 0.0-1.0,
|
|
152
162
|
"reasoning": ["Step-by-step reasoning explaining why this issue was flagged (optional)"]
|
|
153
163
|
}],
|
|
154
|
-
"summary": "
|
|
164
|
+
"summary": "Formatted markdown summary following the Summary Structure guidance above."
|
|
155
165
|
}
|
|
156
166
|
|
|
157
167
|
### GitHub Suggestion Syntax
|
|
@@ -218,6 +228,7 @@ const sections = [
|
|
|
218
228
|
{ name: 'priority-curation', required: true },
|
|
219
229
|
{ name: 'balanced-output', required: true },
|
|
220
230
|
{ name: 'human-centric-framing', required: true },
|
|
231
|
+
{ name: 'summary-synthesis', required: true },
|
|
221
232
|
{ name: 'output-schema', locked: true },
|
|
222
233
|
{ name: 'diff-instructions', required: true },
|
|
223
234
|
{ name: 'file-level-guidance', optional: true, tier: ['balanced', 'thorough'] },
|
|
@@ -240,6 +251,7 @@ const defaultOrder = [
|
|
|
240
251
|
'priority-curation',
|
|
241
252
|
'balanced-output',
|
|
242
253
|
'human-centric-framing',
|
|
254
|
+
'summary-synthesis',
|
|
243
255
|
'output-schema',
|
|
244
256
|
'diff-instructions',
|
|
245
257
|
'file-level-guidance',
|
|
@@ -103,6 +103,15 @@ Max 2-3 praise items. Prefer line-level over file-level. Include actionable sugg
|
|
|
103
103
|
Use "Consider...", "Worth noting..." - guidance not mandates.
|
|
104
104
|
</section>
|
|
105
105
|
|
|
106
|
+
<section name="summary-synthesis" required="true" tier="fast">
|
|
107
|
+
### Summary
|
|
108
|
+
The summary field should be markdown, not one big paragraph.
|
|
109
|
+
- Start with 1-2 sentences describing the overall assessment
|
|
110
|
+
- Then include a markdown bullet list using "- " bullets for the key specific points
|
|
111
|
+
- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
|
|
112
|
+
- Write as a single reviewer; do not mention levels or orchestration
|
|
113
|
+
</section>
|
|
114
|
+
|
|
106
115
|
<section name="output-schema" locked="true">
|
|
107
116
|
## JSON Schema
|
|
108
117
|
{
|
|
@@ -127,7 +136,7 @@ Use "Consider...", "Worth noting..." - guidance not mandates.
|
|
|
127
136
|
"suggestion": "How to fix (omit for praise)",
|
|
128
137
|
"confidence": 0.0-1.0
|
|
129
138
|
}],
|
|
130
|
-
"summary": "
|
|
139
|
+
"summary": "Formatted markdown summary following the Summary guidance above."
|
|
131
140
|
}
|
|
132
141
|
|
|
133
142
|
### GitHub Suggestion Syntax
|
|
@@ -167,6 +176,7 @@ const sections = [
|
|
|
167
176
|
{ name: 'priority-curation', required: true, tier: ['fast'] },
|
|
168
177
|
{ name: 'balanced-output', required: true, tier: ['fast'] },
|
|
169
178
|
{ name: 'human-centric-framing', required: true, tier: ['fast'] },
|
|
179
|
+
{ name: 'summary-synthesis', required: true, tier: ['fast'] },
|
|
170
180
|
{ name: 'output-schema', locked: true },
|
|
171
181
|
{ name: 'diff-instructions', required: true, tier: ['fast'] },
|
|
172
182
|
{ name: 'guidelines', required: true, tier: ['fast'] }
|
|
@@ -189,6 +199,7 @@ const defaultOrder = [
|
|
|
189
199
|
'priority-curation',
|
|
190
200
|
'balanced-output',
|
|
191
201
|
'human-centric-framing',
|
|
202
|
+
'summary-synthesis',
|
|
192
203
|
'output-schema',
|
|
193
204
|
'diff-instructions',
|
|
194
205
|
'guidelines'
|
|
@@ -248,20 +248,21 @@ Note: Confidence is about certainty of value, not severity. A minor improvement
|
|
|
248
248
|
|
|
249
249
|
<section name="summary-synthesis" required="true" tier="thorough">
|
|
250
250
|
## Summary Synthesis Guidance
|
|
251
|
-
The summary field
|
|
251
|
+
The summary field should help the reviewer see the forest, not just the trees, but it should not be one big paragraph.
|
|
252
252
|
|
|
253
253
|
**Effective Summary Approach:**
|
|
254
|
-
- **
|
|
255
|
-
- **
|
|
256
|
-
- **Connect the dots**:
|
|
257
|
-
- **Calibrate severity**:
|
|
254
|
+
- **Start with 1-2 sentences of overall assessment**: Identify the overarching narrative of this PR's quality and concerns
|
|
255
|
+
- **Then use a markdown bullet list with "- " bullets**: Capture the key specific points the reviewer should track
|
|
256
|
+
- **Connect the dots**: Make the overview and bullets feel like one coherent review
|
|
257
|
+
- **Calibrate severity**: Make clear whether this PR is fundamentally sound with minor issues or has structural problems
|
|
258
|
+
- **After the bullets, add extra sentences or short paragraphs only when needed**: Use them for requested context, caveats, or follow-up detail
|
|
258
259
|
- **Respect reviewer time**: A good summary lets the reviewer decide where to focus attention
|
|
259
260
|
|
|
260
261
|
**Summary Anti-patterns to Avoid:**
|
|
261
262
|
- Listing findings ("Found 3 bugs, 2 improvements, 1 praise...")
|
|
262
263
|
- Implementation details ("Merged Level 1 and Level 2 suggestions...")
|
|
263
264
|
- Vague platitudes ("This PR has some issues to consider...")
|
|
264
|
-
-
|
|
265
|
+
- A single unbroken paragraph with no bullets
|
|
265
266
|
</section>
|
|
266
267
|
|
|
267
268
|
<section name="output-schema" locked="true">
|
|
@@ -294,7 +295,7 @@ Output JSON with this structure:
|
|
|
294
295
|
"confidence": 0.0-1.0,
|
|
295
296
|
"reasoning": ["Step-by-step reasoning explaining why this issue was flagged"]
|
|
296
297
|
}],
|
|
297
|
-
"summary": "
|
|
298
|
+
"summary": "Formatted markdown summary following the Summary Synthesis Guidance above."
|
|
298
299
|
}
|
|
299
300
|
|
|
300
301
|
### GitHub Suggestion Syntax
|