reviewdeck 0.2.3 → 0.2.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
CHANGED
|
@@ -11,7 +11,7 @@ Split large PR diffs into reviewable sub-patches via LLM-assigned groups.
|
|
|
11
11
|
Run it ad hoc:
|
|
12
12
|
|
|
13
13
|
```bash
|
|
14
|
-
npx reviewdeck
|
|
14
|
+
npx reviewdeck@^0.2.0 index pr.diff
|
|
15
15
|
```
|
|
16
16
|
|
|
17
17
|
Or install it into another repo:
|
|
@@ -42,19 +42,20 @@ npx skills add neutree-ai/reviewdeck --skill reviewdeck --global
|
|
|
42
42
|
|
|
43
43
|
```bash
|
|
44
44
|
gh pr diff 123 > pr.diff
|
|
45
|
-
npx reviewdeck
|
|
45
|
+
npx reviewdeck@^0.2.0 index pr.diff > pr.index.txt
|
|
46
46
|
```
|
|
47
47
|
|
|
48
48
|
Have the agent use the `reviewdeck` skill to turn the indexed changes into split metadata JSON, then:
|
|
49
49
|
|
|
50
50
|
```bash
|
|
51
|
-
cat split.json | npx reviewdeck
|
|
52
|
-
npx reviewdeck
|
|
51
|
+
cat split.json | npx reviewdeck@^0.2.0 split pr.diff - -o output/
|
|
52
|
+
npx reviewdeck@^0.2.0 render output/
|
|
53
53
|
```
|
|
54
54
|
|
|
55
55
|
If the goal is PR review, `render` is the normal next step after `split`; `split` only proves the sub-patches are valid and ordered.
|
|
56
56
|
`render` is meant to produce a human review UI or artifact, not to replace the human review with automatic findings.
|
|
57
|
-
|
|
57
|
+
When generating split metadata, the skill can follow lightweight review patterns such as `deps-first` or `tests/docs-first`; if the user has no clear preference, `deps-first` is the default.
|
|
58
|
+
The split metadata descriptions are most useful when they explain why the changes are grouped together or what the reviewer should verify in that step.
|
|
58
59
|
The split metadata can also include optional group-level `draftComments`, which render shows inline as agent co-review drafts for the human reviewer to accept or reject.
|
|
59
60
|
When `render` submits, it prints a JSON object with final `comments` plus `draftComments` status so an agent can tell which drafts were accepted before deciding whether to post them back to a PR.
|
|
60
61
|
|
package/dist/web/index.html
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
<head>
|
|
4
4
|
<meta charset="UTF-8" />
|
|
5
5
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
|
6
|
-
<title>
|
|
6
|
+
<title>reviewdeck Review</title>
|
|
7
7
|
<script type="module" crossorigin src="/assets/index-BlTwM_Ro.js"></script>
|
|
8
8
|
<link rel="stylesheet" crossorigin href="/assets/index-Dd56xqmK.css">
|
|
9
9
|
</head>
|
package/package.json
CHANGED
|
@@ -1,115 +1,151 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: reviewdeck
|
|
3
|
-
description: Split a large PR diff into
|
|
3
|
+
description: Split a large PR diff into reviewable sub-patches for easier code review.
|
|
4
4
|
compatibility: Requires Node.js 18+ and npx (or the reviewdeck CLI installed globally).
|
|
5
5
|
metadata:
|
|
6
6
|
author: yanzhen
|
|
7
|
-
version: "0.
|
|
7
|
+
version: "0.4"
|
|
8
8
|
---
|
|
9
9
|
|
|
10
10
|
# Reviewdeck
|
|
11
11
|
|
|
12
|
-
You help a code reviewer
|
|
12
|
+
You help a code reviewer turn a large PR diff into an ordered review deck, then hand it off for human review.
|
|
13
13
|
|
|
14
|
-
|
|
15
|
-
But do not substitute your own code review for the human review step unless the user explicitly asks you to review the code yourself.
|
|
14
|
+
Default posture:
|
|
16
15
|
|
|
17
|
-
|
|
16
|
+
- If the user wants PR review help, do not stop after `split`. Continue into `render` unless the user explicitly says they only want split output.
|
|
17
|
+
- Do not substitute your own autonomous review for the human review step unless the user explicitly asks you to review the code yourself.
|
|
18
|
+
- When invoking the CLI via `npx`, use `npx reviewdeck@^0.2.0 ...`.
|
|
18
19
|
|
|
19
|
-
##
|
|
20
|
+
## Main Path
|
|
20
21
|
|
|
21
|
-
###
|
|
22
|
+
### 1. Get the diff
|
|
22
23
|
|
|
23
|
-
|
|
24
|
+
Use the cheapest path that already matches the user's situation:
|
|
24
25
|
|
|
25
|
-
|
|
26
|
+
- If the user already provided a `.diff`, use it directly.
|
|
27
|
+
- If the user is reviewing a GitHub PR, run:
|
|
26
28
|
|
|
27
29
|
```bash
|
|
28
|
-
|
|
30
|
+
gh pr diff 123 > pr.diff
|
|
29
31
|
```
|
|
30
32
|
|
|
31
|
-
|
|
33
|
+
- If the user is in a local git repo and wants the current branch vs `main`, run:
|
|
32
34
|
|
|
33
|
-
|
|
35
|
+
```bash
|
|
36
|
+
git diff main...HEAD > pr.diff
|
|
37
|
+
```
|
|
34
38
|
|
|
35
|
-
|
|
39
|
+
Other common fallbacks:
|
|
36
40
|
|
|
37
|
-
|
|
38
|
-
|
|
41
|
+
```bash
|
|
42
|
+
# Specific PR in another repo
|
|
43
|
+
gh pr diff 123 --repo owner/repo > pr.diff
|
|
39
44
|
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
These are candidate co-review comments for the human reviewer to accept or reject later in `render`, not your final autonomous review output.
|
|
45
|
+
# Between two commits
|
|
46
|
+
git diff <commit-a> <commit-b> > pr.diff
|
|
43
47
|
|
|
44
|
-
|
|
48
|
+
# Staged changes
|
|
49
|
+
git diff --cached > pr.diff
|
|
50
|
+
```
|
|
45
51
|
|
|
46
|
-
|
|
52
|
+
### 2. Index changes
|
|
47
53
|
|
|
48
54
|
```bash
|
|
49
|
-
|
|
55
|
+
npx reviewdeck@^0.2.0 index pr.diff
|
|
50
56
|
```
|
|
51
57
|
|
|
52
|
-
This
|
|
53
|
-
If your metadata included `draftComments`, they are preserved for `render`.
|
|
58
|
+
This prints a numbered list of changed lines. Those indices are the units you group in the split metadata.
|
|
54
59
|
|
|
55
|
-
|
|
60
|
+
### 3. Choose a review pattern
|
|
56
61
|
|
|
57
|
-
|
|
58
|
-
|
|
62
|
+
Before generating split metadata, decide whether the user has already expressed a preferred review flow.
|
|
63
|
+
|
|
64
|
+
- If the user already implies a preferred flow, follow it.
|
|
65
|
+
- If the user does not express a clear preference and interactive guidance would help, briefly offer these patterns:
|
|
66
|
+
- `deps-first` (recommended): order groups so earlier groups introduce context and dependencies needed by later groups.
|
|
67
|
+
- `tests/docs-first`: review tests or docs that define expected behavior before the implementation that satisfies them.
|
|
68
|
+
- If the user does not choose, continue without blocking. Default to `deps-first`.
|
|
69
|
+
|
|
70
|
+
Use `tests/docs-first` only when tests or docs materially explain the expected behavior. If the tests are trivial or only mirror the implementation, stay with `deps-first`.
|
|
71
|
+
|
|
72
|
+
If you need more detail about the patterns or how to choose between them, read [references/split.md](references/split.md).
|
|
73
|
+
|
|
74
|
+
### 4. Generate split metadata
|
|
75
|
+
|
|
76
|
+
Output a single JSON object:
|
|
77
|
+
|
|
78
|
+
```json
|
|
79
|
+
{
|
|
80
|
+
"groups": [
|
|
81
|
+
{
|
|
82
|
+
"description": "Add version selection plumbing so later upgrade flows have a stable input",
|
|
83
|
+
"changes": ["0-2", 5, 6]
|
|
84
|
+
}
|
|
85
|
+
]
|
|
86
|
+
}
|
|
59
87
|
```
|
|
60
88
|
|
|
61
|
-
|
|
89
|
+
Default rules:
|
|
62
90
|
|
|
63
|
-
|
|
91
|
+
- Every change index must appear exactly once.
|
|
92
|
+
- Choose the number of groups based on reviewability. Keep tightly related changes together, and split only when doing so makes the review sequence clearer.
|
|
93
|
+
- Choose an ordering that matches the selected review pattern.
|
|
94
|
+
- Under `deps-first`, put prerequisite changes before changes that rely on them when possible.
|
|
95
|
+
- Under `tests/docs-first`, put behavior-defining tests or docs before the implementation they explain when that improves reviewability.
|
|
96
|
+
- `description` should help a reviewer navigate the sequence, not just restate filenames or labels.
|
|
97
|
+
- When equivalent, prefer compact range syntax such as `"0-23"` over enumerating many individual indices to save tokens.
|
|
98
|
+
- `draftComments` is optional. Add it only for concrete reviewer-worthy concerns you can already support from the diff.
|
|
99
|
+
- Each draft comment must anchor to a `change` that belongs to the same group.
|
|
64
100
|
|
|
65
|
-
|
|
66
|
-
Use it to open a human review UI for the generated sub-patches and collect comments.
|
|
67
|
-
Default to the live render session.
|
|
101
|
+
If you need heavier guidance for grouping, description writing, or draft comment quality, then read [references/split.md](references/split.md).
|
|
68
102
|
|
|
69
|
-
|
|
103
|
+
### 5. Split and verify
|
|
70
104
|
|
|
71
105
|
```bash
|
|
72
|
-
|
|
73
|
-
|
|
106
|
+
echo '<meta JSON>' | npx reviewdeck@^0.2.0 split pr.diff -
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
Or write files:
|
|
74
110
|
|
|
75
|
-
|
|
76
|
-
echo '<meta JSON>' | npx reviewdeck
|
|
111
|
+
```bash
|
|
112
|
+
echo '<meta JSON>' | npx reviewdeck@^0.2.0 split pr.diff - -o output/
|
|
77
113
|
```
|
|
78
114
|
|
|
79
|
-
|
|
80
|
-
|
|
115
|
+
This validates the metadata, generates sub-patches, and verifies that they compose back to the original diff.
|
|
116
|
+
|
|
117
|
+
If `split` fails, read the error, fix the metadata JSON, and retry.
|
|
81
118
|
|
|
82
|
-
|
|
83
|
-
- `draftComments`: the agent draft comments with `accepted` / `rejected` / `pending` status
|
|
119
|
+
### 6. Hand off to human review
|
|
84
120
|
|
|
85
|
-
|
|
86
|
-
Treat `draftComments` as provenance that tells you which of your draft findings survived review.
|
|
121
|
+
After `split` succeeds, the default next step is live review:
|
|
87
122
|
|
|
88
|
-
|
|
89
|
-
|
|
123
|
+
```bash
|
|
124
|
+
npx reviewdeck@^0.2.0 render output/
|
|
125
|
+
```
|
|
90
126
|
|
|
91
|
-
|
|
127
|
+
Or from stdin:
|
|
92
128
|
|
|
93
|
-
|
|
94
|
-
-
|
|
95
|
-
|
|
129
|
+
```bash
|
|
130
|
+
echo '<meta JSON>' | npx reviewdeck@^0.2.0 split pr.diff - | npx reviewdeck@^0.2.0 render -
|
|
131
|
+
```
|
|
96
132
|
|
|
97
|
-
|
|
133
|
+
The server opens a browser, blocks until submission, and prints a review submission JSON object to stdout.
|
|
98
134
|
|
|
99
|
-
|
|
135
|
+
Default behavior:
|
|
100
136
|
|
|
101
|
-
-
|
|
102
|
-
-
|
|
103
|
-
-
|
|
104
|
-
-
|
|
137
|
+
- Prefer to actually launch `render` and wait for submission when the user wants PR review help.
|
|
138
|
+
- Do not stop at “split succeeded” if a live local review session is possible.
|
|
139
|
+
- Treat `comments` as the final human-approved payload.
|
|
140
|
+
- Treat `draftComments` as provenance for which agent drafts were accepted, rejected, or left pending.
|
|
105
141
|
|
|
106
|
-
|
|
142
|
+
### 7. Submit comments back to source
|
|
107
143
|
|
|
108
|
-
|
|
144
|
+
After `render` completes:
|
|
109
145
|
|
|
110
|
-
-
|
|
111
|
-
-
|
|
112
|
-
-
|
|
113
|
-
-
|
|
114
|
-
-
|
|
115
|
-
-
|
|
146
|
+
- Summarize accepted/rejected/pending draft comment outcomes.
|
|
147
|
+
- If there are final `comments`, ask whether the user wants them submitted back to the source review system.
|
|
148
|
+
- If the target is already explicit in context, such as a specific PR or review thread, continue there instead of asking again.
|
|
149
|
+
- When submitting, use `comments`, not raw `draftComments`.
|
|
150
|
+
- If there are no final `comments`, say so clearly and stop.
|
|
151
|
+
- Ask first when the target review system or PR/thread is not explicit.
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
# Split Guidance
|
|
2
|
+
|
|
3
|
+
Use this reference only when the basic rules in `SKILL.md` are not enough.
|
|
4
|
+
|
|
5
|
+
## Goal
|
|
6
|
+
|
|
7
|
+
Split a large PR diff into a sequence of smaller, logically coherent sub-patches that are easier to review.
|
|
8
|
+
|
|
9
|
+
## Principles
|
|
10
|
+
|
|
11
|
+
- Pattern-aware ordering: choose a review flow that matches the user's preference or the diff shape
|
|
12
|
+
- Cohesive grouping: keep tightly related changes together, and separate unrelated concerns when doing so improves reviewability
|
|
13
|
+
- Stable review flow: order groups so a reviewer can build context without jumping back and forth unnecessarily
|
|
14
|
+
- Reviewer-oriented descriptions: describe why this group exists in the review flow, not just the touched area
|
|
15
|
+
- Co-review drafts when warranted: if you notice a concrete review concern while splitting, attach it as a draft comment instead of switching into a full review report
|
|
16
|
+
|
|
17
|
+
## Review patterns
|
|
18
|
+
|
|
19
|
+
Use one of these patterns when ordering groups:
|
|
20
|
+
|
|
21
|
+
- `deps-first`: review prerequisites before dependents so later groups do not rely on unseen context. This is the default when the user does not express a preference.
|
|
22
|
+
- `tests/docs-first`: review tests or docs that define expected behavior before the implementation that satisfies them.
|
|
23
|
+
|
|
24
|
+
## Pattern selection
|
|
25
|
+
|
|
26
|
+
Use these heuristics:
|
|
27
|
+
|
|
28
|
+
- If the user names a preferred flow, follow it.
|
|
29
|
+
- If the prompt has no clear preference and asking would help, briefly offer `deps-first` and `tests/docs-first`.
|
|
30
|
+
- If the user does not choose, continue with `deps-first`.
|
|
31
|
+
- Prefer `tests/docs-first` only when the tests or docs materially clarify expected behavior or review intent.
|
|
32
|
+
- Fall back to `deps-first` when tests are trivial, purely mechanical, or depend on too much unseen implementation detail.
|
|
33
|
+
|
|
34
|
+
## Output format
|
|
35
|
+
|
|
36
|
+
Output a single JSON object with no markdown fences and no extra commentary:
|
|
37
|
+
|
|
38
|
+
```json
|
|
39
|
+
{
|
|
40
|
+
"groups": [
|
|
41
|
+
{
|
|
42
|
+
"description": "Add version selector plumbing so later upgrade flows have a stable input",
|
|
43
|
+
"changes": ["0-2", 5, 6],
|
|
44
|
+
"draftComments": [
|
|
45
|
+
{
|
|
46
|
+
"change": 6,
|
|
47
|
+
"body": "Check whether the new selector can drift out of sync when no compatible versions exist."
|
|
48
|
+
}
|
|
49
|
+
]
|
|
50
|
+
},
|
|
51
|
+
{
|
|
52
|
+
"description": "Cover the upgrade path with e2e checks after the UI flow is in place",
|
|
53
|
+
"changes": ["3-4", "7-9"]
|
|
54
|
+
}
|
|
55
|
+
]
|
|
56
|
+
}
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
## Rules
|
|
60
|
+
|
|
61
|
+
1. Every change index must appear in exactly one group.
|
|
62
|
+
2. No index may appear in more than one group.
|
|
63
|
+
3. No index may be omitted.
|
|
64
|
+
4. Groups are ordered. Group 1 is reviewed first, group N last.
|
|
65
|
+
5. Choose the number of groups based on the PR shape. Use as many groups as needed to keep the review understandable, but avoid splitting tightly coupled changes just to create more groups.
|
|
66
|
+
6. Use range syntax for consecutive indices: `"0-2"` means `[0, 1, 2]`.
|
|
67
|
+
7. `draftComments` is optional.
|
|
68
|
+
8. Each draft comment must anchor to a `change` that belongs to the same group.
|
|
69
|
+
|
|
70
|
+
## Description guidance
|
|
71
|
+
|
|
72
|
+
Good descriptions help a reviewer understand why this group should be reviewed as one unit and how it fits into the sequence.
|
|
73
|
+
|
|
74
|
+
Prefer descriptions that:
|
|
75
|
+
|
|
76
|
+
- explain the intent or review value of the group
|
|
77
|
+
- mention the dependency or sequencing reason when useful
|
|
78
|
+
- tell the reviewer what they can learn or verify in this step
|
|
79
|
+
|
|
80
|
+
Avoid descriptions that are only:
|
|
81
|
+
|
|
82
|
+
- a raw area label like `form version selector`
|
|
83
|
+
- an as-is restatement of filenames, component names, or ticket labels
|
|
84
|
+
- too vague to distinguish this group from adjacent ones
|
|
85
|
+
|
|
86
|
+
Examples that usually work well:
|
|
87
|
+
|
|
88
|
+
- `Add version selection plumbing so the upgrade flow has a stable entry point`
|
|
89
|
+
- `Show current version and status before wiring upgrade actions`
|
|
90
|
+
- `Isolate the upgrade dialog and action handling as the main behavior change`
|
|
91
|
+
- `Add e2e coverage once the upgrade flow is in place`
|
|
92
|
+
|
|
93
|
+
Examples that are often too vague:
|
|
94
|
+
|
|
95
|
+
- `version selector`
|
|
96
|
+
- `status display`
|
|
97
|
+
- `upgrade dialog`
|
|
98
|
+
- `e2e`
|
|
99
|
+
|
|
100
|
+
## Draft comment guidance
|
|
101
|
+
|
|
102
|
+
Use `draftComments` selectively. They are candidate review comments that the human reviewer can accept or reject during `render`.
|
|
103
|
+
|
|
104
|
+
Prefer draft comments that:
|
|
105
|
+
|
|
106
|
+
- point to a specific risk, regression, or questionable assumption
|
|
107
|
+
- are anchored to one concrete indexed change
|
|
108
|
+
- read like something worth sending to the source review if accepted
|
|
109
|
+
|
|
110
|
+
Avoid draft comments that are only:
|
|
111
|
+
|
|
112
|
+
- a summary of what the code does
|
|
113
|
+
- generic praise or noise
|
|
114
|
+
- a vague warning with no concrete concern
|
|
115
|
+
|
|
116
|
+
Examples that usually work well:
|
|
117
|
+
|
|
118
|
+
- `Potential regression: this update path bypasses the sanitizing transform used by the normal edit flow.`
|
|
119
|
+
- `This selector keeps the old version when no compatible options exist, so the form may submit an unavailable version.`
|
|
120
|
+
|
|
121
|
+
Examples that are often too weak:
|
|
122
|
+
|
|
123
|
+
- `Adds selector logic`
|
|
124
|
+
- `Looks risky`
|
|
125
|
+
- `Need review`
|
|
@@ -1,111 +0,0 @@
|
|
|
1
|
-
# Task: Split a PR diff into reviewable sub-patches
|
|
2
|
-
|
|
3
|
-
You are helping a code reviewer. Given a large PR diff, split it into a sequence of smaller, logically coherent sub-patches that are easier to review.
|
|
4
|
-
|
|
5
|
-
## Principles
|
|
6
|
-
|
|
7
|
-
- **Peripheral first, core last**: infrastructure, config, types -> implementation -> tests
|
|
8
|
-
- **Independent first, dependent last**: if B depends on A, A comes first
|
|
9
|
-
- **One concern per group**: don't mix refactoring with new features
|
|
10
|
-
- **Reviewer-oriented descriptions**: describe why this group exists in the review flow, not just the surface area it touches
|
|
11
|
-
- **Co-review drafts when warranted**: if you notice a concrete review concern while splitting, attach it as a draft comment instead of switching into a full review report
|
|
12
|
-
|
|
13
|
-
## Input
|
|
14
|
-
|
|
15
|
-
The indexed change lines are provided separately. Each `[N]` is a **change index**. `-` = deletion, `+` = addition, `LN` = line number.
|
|
16
|
-
|
|
17
|
-
## Output format
|
|
18
|
-
|
|
19
|
-
Output a single JSON object (no markdown fences, no commentary before or after):
|
|
20
|
-
|
|
21
|
-
```json
|
|
22
|
-
{
|
|
23
|
-
"groups": [
|
|
24
|
-
{
|
|
25
|
-
"description": "Add version selector plumbing so later upgrade flows have a stable input",
|
|
26
|
-
"changes": ["0-2", 5, 6],
|
|
27
|
-
"draftComments": [
|
|
28
|
-
{
|
|
29
|
-
"change": 6,
|
|
30
|
-
"body": "Check whether the new selector can drift out of sync when no compatible versions exist."
|
|
31
|
-
}
|
|
32
|
-
]
|
|
33
|
-
},
|
|
34
|
-
{
|
|
35
|
-
"description": "Cover the upgrade path with e2e checks after the UI flow is in place",
|
|
36
|
-
"changes": ["3-4", "7-9"]
|
|
37
|
-
}
|
|
38
|
-
]
|
|
39
|
-
}
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
## Rules
|
|
43
|
-
|
|
44
|
-
1. Every change index must appear in exactly one group
|
|
45
|
-
2. No index may appear in more than one group
|
|
46
|
-
3. No index may be omitted
|
|
47
|
-
4. Groups are ordered — group 1 is applied first, group N last
|
|
48
|
-
5. Aim for 3-6 groups (adjust based on the PR's complexity)
|
|
49
|
-
6. Each group's `description` should read like a review-guiding commit message — a concise summary line, optionally followed by detail
|
|
50
|
-
7. Use range syntax for consecutive indices: `"0-2"` means `[0, 1, 2]`. Single indices can be plain numbers: `5`
|
|
51
|
-
8. `draftComments` is optional, but when you see a concrete reviewer-worthy concern while splitting, include it.
|
|
52
|
-
9. Each draft comment must anchor to a `change` that belongs to the same group.
|
|
53
|
-
|
|
54
|
-
## Description guidance
|
|
55
|
-
|
|
56
|
-
Good descriptions help a reviewer understand why this group should be reviewed as one unit and how it fits into the sequence.
|
|
57
|
-
|
|
58
|
-
Prefer descriptions that:
|
|
59
|
-
|
|
60
|
-
- explain the intent or review value of the group
|
|
61
|
-
- mention the dependency or sequencing reason when useful
|
|
62
|
-
- tell the reviewer what they can learn or verify in this step
|
|
63
|
-
|
|
64
|
-
Avoid descriptions that are only:
|
|
65
|
-
|
|
66
|
-
- a raw area label like `form version selector`
|
|
67
|
-
- an as-is restatement of filenames, component names, or ticket labels
|
|
68
|
-
- too vague to distinguish this group from adjacent ones
|
|
69
|
-
|
|
70
|
-
Better:
|
|
71
|
-
|
|
72
|
-
- `Add version selection plumbing so the upgrade flow has a stable entry point`
|
|
73
|
-
- `Show current version and status before wiring upgrade actions`
|
|
74
|
-
- `Isolate the upgrade dialog and action handling as the main behavior change`
|
|
75
|
-
- `Add e2e coverage once the upgrade flow is in place`
|
|
76
|
-
|
|
77
|
-
Worse:
|
|
78
|
-
|
|
79
|
-
- `version selector`
|
|
80
|
-
- `status display`
|
|
81
|
-
- `upgrade dialog`
|
|
82
|
-
- `e2e`
|
|
83
|
-
|
|
84
|
-
## Draft comment guidance
|
|
85
|
-
|
|
86
|
-
Use `draftComments` selectively but decisively. They are not the final submitted comments. They are candidate review comments that the human reviewer can accept or reject during `render`.
|
|
87
|
-
|
|
88
|
-
Prefer draft comments that:
|
|
89
|
-
|
|
90
|
-
- point to a specific risk, regression, or questionable assumption
|
|
91
|
-
- are anchored to one concrete indexed change
|
|
92
|
-
- read like something worth sending to the source review if accepted
|
|
93
|
-
|
|
94
|
-
If you already have enough evidence from the diff to state a concrete concern, prefer emitting the draft comment now rather than omitting it.
|
|
95
|
-
|
|
96
|
-
Avoid draft comments that are only:
|
|
97
|
-
|
|
98
|
-
- a summary of what the code does
|
|
99
|
-
- generic praise or noise
|
|
100
|
-
- a full review section pasted into one comment
|
|
101
|
-
|
|
102
|
-
Better:
|
|
103
|
-
|
|
104
|
-
- `Potential regression: this update path bypasses the sanitizing transform used by the normal edit flow.`
|
|
105
|
-
- `This selector keeps the old version when no compatible options exist, so the form may submit an unavailable version.`
|
|
106
|
-
|
|
107
|
-
Worse:
|
|
108
|
-
|
|
109
|
-
- `Adds selector logic`
|
|
110
|
-
- `Looks risky`
|
|
111
|
-
- `Need review`
|
|
@@ -1,24 +0,0 @@
|
|
|
1
|
-
# Getting a diff
|
|
2
|
-
|
|
3
|
-
## Local git
|
|
4
|
-
|
|
5
|
-
```bash
|
|
6
|
-
# Current branch vs main
|
|
7
|
-
git diff main...HEAD
|
|
8
|
-
|
|
9
|
-
# Between two commits
|
|
10
|
-
git diff <commit-a> <commit-b>
|
|
11
|
-
|
|
12
|
-
# Staged changes
|
|
13
|
-
git diff --cached
|
|
14
|
-
```
|
|
15
|
-
|
|
16
|
-
## GitHub CLI
|
|
17
|
-
|
|
18
|
-
```bash
|
|
19
|
-
# PR diff by number
|
|
20
|
-
gh pr diff 123
|
|
21
|
-
|
|
22
|
-
# Specific PR in another repo
|
|
23
|
-
gh pr diff 123 --repo owner/repo
|
|
24
|
-
```
|