@staff0rd/assist 0.542.1 → 0.543.0
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 +2 -2
- package/claude/commands/fix-conflict.md +69 -16
- package/dist/commands/sessions/web/bundle.js +104 -104
- package/dist/index.js +19 -9
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -47,7 +47,7 @@ After installation, the `assist` command will be available globally. You can als
|
|
|
47
47
|
- `/commit` - Commit only relevant files from the session
|
|
48
48
|
- `/devlog` - Generate devlog entry for the next unversioned day
|
|
49
49
|
- `/draft` - Draft a new backlog item with LLM-assisted questioning
|
|
50
|
-
- `/fix-conflict` - Resolve the current PR branch's
|
|
50
|
+
- `/fix-conflict [--rebase]` - Resolve the current PR branch's conflicts against the remote default, verify, then push; merges by default, `--rebase` replays the branch and pushes with `--force-with-lease`
|
|
51
51
|
- `/forward-comments` - Split a coarse PR comment into per-line review comments, attributed to the original reviewer
|
|
52
52
|
- `/handover` - Write a session handover note for the next conversation
|
|
53
53
|
- `/pr` - Raise a PR with a concise description, then watch CI in the background
|
|
@@ -344,7 +344,7 @@ The Config tab of the sessions web dashboard never receives secret values: `GET
|
|
|
344
344
|
- `assist bug [description] [--once]` - Launch Claude in `/bug` mode, chain into next on `/next` signal
|
|
345
345
|
- `assist refine [id] [--once] [--harness <claude|codex|pi>]` - Launch a coding harness in `/refine` mode; `--harness` picks the engine, defaulting to the configured `harness.engine` (Claude)
|
|
346
346
|
- `assist review-pr-comments [number] [--announce]` - Launch Claude in `/review-pr-comments` mode; a PR number is checked out first via `gh pr checkout`. `--announce` (requires a number) announces the PR in Slack via `/prs-slack <number> --no-confirm` once every comment thread has been processed
|
|
347
|
-
- `assist fix-conflict [number]` - Launch Claude in `/fix-conflict` mode to resolve the branch's conflicts against the remote default; a PR number is checked out first via `gh pr checkout`
|
|
347
|
+
- `assist fix-conflict [number] [--rebase]` - Launch Claude in `/fix-conflict` mode to resolve the branch's conflicts against the remote default; a PR number is checked out first via `gh pr checkout`. `--rebase` rebases onto the remote default instead of merging it in
|
|
348
348
|
- `assist signal next [id]` - Write a next signal to chain into `assist next`
|
|
349
349
|
- `assist signal done [id]` - Write a done signal marking the session's initial task complete; an optional `id` surfaces the backlog item the session created onto its card
|
|
350
350
|
|
|
@@ -6,26 +6,21 @@ Resolve the conflicts between this branch and the remote default branch, then pu
|
|
|
6
6
|
|
|
7
7
|
The branch is already checked out — `assist fix-conflict <number>` checks the PR out before launching this session. Never switch branches.
|
|
8
8
|
|
|
9
|
-
## Step
|
|
9
|
+
## Step 0: Pick the strategy
|
|
10
10
|
|
|
11
|
-
|
|
12
|
-
git remote show origin | sed -n 's/.*HEAD branch: //p'
|
|
13
|
-
```
|
|
11
|
+
If the arguments contain `--rebase`, follow the **rebase** flow (Steps R1–R4). Otherwise follow the **merge** flow (Steps M1–M4).
|
|
14
12
|
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
## Step 2: Fetch and merge
|
|
13
|
+
Both flows start by finding the remote default branch:
|
|
18
14
|
|
|
19
15
|
```
|
|
20
|
-
git
|
|
21
|
-
git merge origin/<default>
|
|
16
|
+
git remote show origin | sed -n 's/.*HEAD branch: //p'
|
|
22
17
|
```
|
|
23
18
|
|
|
24
|
-
|
|
19
|
+
Call the result `<default>`. If it comes back empty, fall back to `git symbolic-ref --short refs/remotes/origin/HEAD` and strip the `origin/` prefix.
|
|
25
20
|
|
|
26
|
-
##
|
|
21
|
+
## Resolving a conflicted file
|
|
27
22
|
|
|
28
|
-
List the conflicts with `git diff --name-only --diff-filter=U`, then work through them one at a time:
|
|
23
|
+
Both flows resolve conflicts the same way. List the conflicts with `git diff --name-only --diff-filter=U`, then work through them one at a time:
|
|
29
24
|
|
|
30
25
|
1. Read the file and understand both sides. `git log --oneline origin/<default>..HEAD` and `git log --oneline HEAD..origin/<default>` show what each side changed and why.
|
|
31
26
|
2. Write the resolution that keeps **both** intents. A conflict usually means two changes to the same region, not a choice between them — only drop a side when it is genuinely superseded.
|
|
@@ -43,13 +38,30 @@ Repeat until `git diff --name-only --diff-filter=U` is empty. Confirm no markers
|
|
|
43
38
|
git grep -n '^<<<<<<< \|^>>>>>>> ' -- . || true
|
|
44
39
|
```
|
|
45
40
|
|
|
46
|
-
|
|
41
|
+
Note that during a rebase the sides are swapped: `--ours` is the upstream (`origin/<default>`) and `--theirs` is the commit being replayed.
|
|
42
|
+
|
|
43
|
+
# Merge flow
|
|
44
|
+
|
|
45
|
+
## Step M1: Fetch and merge
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
git fetch origin
|
|
49
|
+
git merge origin/<default>
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
If the merge reports "Already up to date" or completes cleanly with no conflicts, there is nothing to resolve — say so and stop. Do not push, do not create an empty commit.
|
|
53
|
+
|
|
54
|
+
## Step M2: Resolve every conflicted file
|
|
55
|
+
|
|
56
|
+
Follow **Resolving a conflicted file** above.
|
|
57
|
+
|
|
58
|
+
## Step M3: Verify
|
|
47
59
|
|
|
48
60
|
Run `/verify`. Fix anything it reports — a merge that compiles on each side can still break where the two changes meet, so treat failures as part of the conflict resolution rather than pre-existing breakage.
|
|
49
61
|
|
|
50
|
-
Do not proceed to Step
|
|
62
|
+
Do not proceed to Step M4 until verify passes.
|
|
51
63
|
|
|
52
|
-
## Step
|
|
64
|
+
## Step M4: Commit and push
|
|
53
65
|
|
|
54
66
|
```
|
|
55
67
|
git commit --no-edit
|
|
@@ -60,8 +72,49 @@ git push
|
|
|
60
72
|
|
|
61
73
|
Report the resolved files and the pushed SHA when done.
|
|
62
74
|
|
|
75
|
+
# Rebase flow
|
|
76
|
+
|
|
77
|
+
## Step R1: Fetch and rebase
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
git fetch origin
|
|
81
|
+
git rebase origin/<default>
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
If the rebase completes with no conflicts, the branch is simply replayed — go straight to Step R3. If it reports the branch is already up to date and nothing was replayed, there is nothing to resolve — say so and stop without pushing.
|
|
85
|
+
|
|
86
|
+
## Step R2: Resolve conflicts one commit at a time
|
|
87
|
+
|
|
88
|
+
A rebase stops at each commit that conflicts. For every stop:
|
|
89
|
+
|
|
90
|
+
1. Read `git status` to see which commit is being replayed (`git log -1 --oneline REBASE_HEAD`).
|
|
91
|
+
2. Resolve the conflicted files following **Resolving a conflicted file** above, keeping that commit's intent intact — do not fold later commits' changes into an earlier one.
|
|
92
|
+
3. `git rebase --continue`.
|
|
93
|
+
|
|
94
|
+
If a replayed commit's changes have already landed upstream and it resolves to nothing, `git rebase --skip` is the right move — say which commit you skipped and why.
|
|
95
|
+
|
|
96
|
+
Repeat until the rebase finishes. `git status` no longer reporting a rebase in progress is the signal.
|
|
97
|
+
|
|
98
|
+
## Step R3: Verify
|
|
99
|
+
|
|
100
|
+
Run `/verify`. Fix anything it reports — a rebase that replays cleanly per commit can still break where the two histories meet, so treat failures as part of the conflict resolution rather than pre-existing breakage.
|
|
101
|
+
|
|
102
|
+
If a fix is needed, commit it on top rather than amending a replayed commit.
|
|
103
|
+
|
|
104
|
+
Do not proceed to Step R4 until verify passes.
|
|
105
|
+
|
|
106
|
+
## Step R4: Push
|
|
107
|
+
|
|
108
|
+
```
|
|
109
|
+
git push --force-with-lease
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
The rebase rewrote the branch's history, so a plain push is rejected. `--force-with-lease` is required and `--force` is not — the lease is what stops the push from clobbering commits someone else pushed while the session was running. If the push is rejected because the lease is stale, do not retry with `--force`: fetch, report what moved, and ask the user.
|
|
113
|
+
|
|
114
|
+
Report the resolved files, any skipped commits, and the pushed SHA when done.
|
|
115
|
+
|
|
63
116
|
## Important
|
|
64
117
|
|
|
65
|
-
- Never `git merge --abort` or reset without being asked — the user launched this session to get the conflicts resolved.
|
|
118
|
+
- Never `git merge --abort`, `git rebase --abort`, or reset without being asked — the user launched this session to get the conflicts resolved.
|
|
66
119
|
- Never force-push on the merge strategy; a plain `git push` is correct because the merge only adds a commit.
|
|
67
120
|
- If a conflict genuinely cannot be resolved without a product decision, stop and ask the user rather than guessing.
|