@litmers/cursorflow-orchestrator 0.1.9 β 0.1.13
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/CHANGELOG.md +30 -0
- package/README.md +90 -72
- package/commands/cursorflow-clean.md +24 -135
- package/commands/cursorflow-doctor.md +66 -38
- package/commands/cursorflow-init.md +33 -50
- package/commands/cursorflow-models.md +51 -0
- package/commands/cursorflow-monitor.md +52 -72
- package/commands/cursorflow-prepare.md +426 -147
- package/commands/cursorflow-resume.md +51 -159
- package/commands/cursorflow-review.md +38 -202
- package/commands/cursorflow-run.md +197 -84
- package/commands/cursorflow-signal.md +27 -72
- package/dist/cli/clean.js +23 -0
- package/dist/cli/clean.js.map +1 -1
- package/dist/cli/doctor.js +14 -1
- package/dist/cli/doctor.js.map +1 -1
- package/dist/cli/index.js +14 -3
- package/dist/cli/index.js.map +1 -1
- package/dist/cli/init.js +5 -4
- package/dist/cli/init.js.map +1 -1
- package/dist/cli/models.d.ts +7 -0
- package/dist/cli/models.js +104 -0
- package/dist/cli/models.js.map +1 -0
- package/dist/cli/monitor.js +17 -0
- package/dist/cli/monitor.js.map +1 -1
- package/dist/cli/prepare.d.ts +7 -0
- package/dist/cli/prepare.js +748 -0
- package/dist/cli/prepare.js.map +1 -0
- package/dist/cli/resume.js +56 -0
- package/dist/cli/resume.js.map +1 -1
- package/dist/cli/run.js +30 -1
- package/dist/cli/run.js.map +1 -1
- package/dist/cli/signal.js +18 -0
- package/dist/cli/signal.js.map +1 -1
- package/dist/utils/cursor-agent.d.ts +4 -0
- package/dist/utils/cursor-agent.js +58 -10
- package/dist/utils/cursor-agent.js.map +1 -1
- package/dist/utils/doctor.d.ts +10 -0
- package/dist/utils/doctor.js +588 -1
- package/dist/utils/doctor.js.map +1 -1
- package/dist/utils/types.d.ts +2 -0
- package/examples/README.md +114 -59
- package/examples/demo-project/README.md +61 -79
- package/examples/demo-project/_cursorflow/tasks/demo-test/01-create-utils.json +17 -6
- package/examples/demo-project/_cursorflow/tasks/demo-test/02-add-tests.json +17 -6
- package/examples/demo-project/_cursorflow/tasks/demo-test/README.md +66 -25
- package/package.json +1 -1
- package/src/cli/clean.ts +27 -0
- package/src/cli/doctor.ts +18 -2
- package/src/cli/index.ts +15 -3
- package/src/cli/init.ts +6 -4
- package/src/cli/models.ts +83 -0
- package/src/cli/monitor.ts +20 -0
- package/src/cli/prepare.ts +844 -0
- package/src/cli/resume.ts +66 -0
- package/src/cli/run.ts +36 -2
- package/src/cli/signal.ts +22 -0
- package/src/utils/cursor-agent.ts +62 -10
- package/src/utils/doctor.ts +643 -5
- package/src/utils/types.ts +2 -0
|
@@ -1,192 +1,84 @@
|
|
|
1
1
|
# CursorFlow Resume
|
|
2
2
|
|
|
3
3
|
## Overview
|
|
4
|
-
Resume
|
|
4
|
+
Resume a lane that was interrupted or failed. CursorFlow allows you to continue from where the agent left off or restart the lane from the first task.
|
|
5
5
|
|
|
6
|
-
##
|
|
6
|
+
## Usage
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
```
|
|
12
|
-
|
|
13
|
-
2. **Resume a lane**
|
|
14
|
-
```bash
|
|
15
|
-
cursorflow resume <lane-name>
|
|
16
|
-
```
|
|
17
|
-
|
|
18
|
-
3. **Clean branches before resuming**
|
|
19
|
-
```bash
|
|
20
|
-
cursorflow resume <lane-name> --clean
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
4. **Restart from the beginning**
|
|
24
|
-
```bash
|
|
25
|
-
cursorflow resume <lane-name> --restart
|
|
26
|
-
```
|
|
8
|
+
```bash
|
|
9
|
+
cursorflow resume <lane-name> [options]
|
|
10
|
+
```
|
|
27
11
|
|
|
28
12
|
## Options
|
|
29
13
|
|
|
30
14
|
| Option | Description |
|
|
31
15
|
|------|------|
|
|
32
|
-
|
|
|
33
|
-
| `--
|
|
34
|
-
| `--restart` |
|
|
35
|
-
| `--
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
16
|
+
| `<lane-name>` | The name of the lane to resume (e.g., `lane-1`) |
|
|
17
|
+
| `--run-dir <path>` | Use a specific run directory (default: latest) |
|
|
18
|
+
| `--restart` | Restart the lane from the very first task |
|
|
19
|
+
| `--clean` | Clean up the existing worktree before resuming |
|
|
20
|
+
| `--skip-doctor` | Skip pre-resume checks (not recommended) |
|
|
21
|
+
|
|
22
|
+
## How it works
|
|
23
|
+
1. **Pre-flight Checks**: Runs doctor validation to check for branch conflicts and Git issues.
|
|
24
|
+
2. **State Loading**: Reads the `state.json` for the specified lane to find the last successful task.
|
|
25
|
+
3. **Environment Restore**: Verifies the Git worktree and branch for the lane.
|
|
26
|
+
4. **Execution**: Spawns a new runner that starts either from the current task index or from index 0 if `--restart` is used.
|
|
27
|
+
|
|
28
|
+
## Pre-resume Validation
|
|
29
|
+
|
|
30
|
+
Before resuming, CursorFlow automatically runs validation checks:
|
|
31
|
+
- **Branch conflicts**: Ensures no existing branches conflict with the lane's prefix
|
|
32
|
+
- **Git status**: Verifies repository state and remote connectivity
|
|
33
|
+
- **Task configuration**: Validates the task JSON files are still valid
|
|
34
|
+
|
|
35
|
+
To skip these checks (not recommended):
|
|
40
36
|
```bash
|
|
41
|
-
|
|
42
|
-
cursorflow resume 01-dashboard
|
|
37
|
+
cursorflow resume lane-1 --skip-doctor
|
|
43
38
|
```
|
|
44
39
|
|
|
45
|
-
|
|
46
|
-
```bash
|
|
47
|
-
cursorflow resume --run-dir _cursorflow/logs/runs/my-run/ 01-dashboard
|
|
48
|
-
```
|
|
40
|
+
## Examples
|
|
49
41
|
|
|
50
|
-
###
|
|
42
|
+
### Resume a failed lane
|
|
51
43
|
```bash
|
|
52
|
-
|
|
53
|
-
cursorflow resume 01-dashboard --clean
|
|
44
|
+
cursorflow resume 01-lane-1
|
|
54
45
|
```
|
|
55
46
|
|
|
56
|
-
###
|
|
47
|
+
### Restart a lane from scratch
|
|
57
48
|
```bash
|
|
58
|
-
|
|
59
|
-
cursorflow resume 01-dashboard --restart
|
|
60
|
-
```
|
|
61
|
-
|
|
62
|
-
## Resume process
|
|
63
|
-
|
|
64
|
-
1. **Check state**
|
|
65
|
-
- Load `state.json`
|
|
66
|
-
- Locate the last task index
|
|
67
|
-
- Inspect the worktree state
|
|
68
|
-
|
|
69
|
-
2. **Restore the environment**
|
|
70
|
-
- Verify worktree accessibility
|
|
71
|
-
- Check out the branch
|
|
72
|
-
- Check for uncommitted changes
|
|
73
|
-
|
|
74
|
-
3. **Resume execution**
|
|
75
|
-
- Continue from the interrupted task
|
|
76
|
-
- Or restart from the beginning (`--restart`)
|
|
77
|
-
|
|
78
|
-
4. **Complete**
|
|
79
|
-
- Finish remaining tasks
|
|
80
|
-
- Commit and push changes
|
|
81
|
-
|
|
82
|
-
## Sample state file
|
|
83
|
-
|
|
84
|
-
```json
|
|
85
|
-
{
|
|
86
|
-
"label": "01-dashboard",
|
|
87
|
-
"status": "failed",
|
|
88
|
-
"currentTaskIndex": 1,
|
|
89
|
-
"totalTasks": 3,
|
|
90
|
-
"worktreeDir": ".cursorflow/logs/worktrees/01-dashboard-abc123",
|
|
91
|
-
"pipelineBranch": "feature/dashboard-abc123",
|
|
92
|
-
"error": "Build failed",
|
|
93
|
-
"startTime": 1734567890000,
|
|
94
|
-
"endTime": null
|
|
95
|
-
}
|
|
49
|
+
cursorflow resume 02-lane-2 --restart
|
|
96
50
|
```
|
|
97
51
|
|
|
98
|
-
|
|
99
|
-
- [ ] Was the lane actually interrupted?
|
|
100
|
-
- [ ] Does the state file exist?
|
|
101
|
-
- [ ] Are there any branch conflicts?
|
|
102
|
-
- [ ] Does the worktree still exist?
|
|
103
|
-
- [ ] Are there uncommitted changes?
|
|
104
|
-
|
|
105
|
-
## Troubleshooting
|
|
106
|
-
|
|
107
|
-
### State file missing
|
|
52
|
+
### Resume from an older run
|
|
108
53
|
```bash
|
|
109
|
-
|
|
110
|
-
ls -lt _cursorflow/logs/runs/
|
|
111
|
-
|
|
112
|
-
# Specify a run explicitly
|
|
113
|
-
cursorflow resume --run-dir _cursorflow/logs/runs/latest/ 01-dashboard
|
|
54
|
+
cursorflow resume 01-lane-1 --run-dir _cursorflow/logs/runs/run-123456789/
|
|
114
55
|
```
|
|
115
56
|
|
|
116
|
-
|
|
117
|
-
```bash
|
|
118
|
-
# Inspect existing branches
|
|
119
|
-
git branch | grep dashboard
|
|
57
|
+
## Troubleshooting
|
|
120
58
|
|
|
121
|
-
|
|
122
|
-
cursorflow
|
|
123
|
-
```
|
|
59
|
+
### State not found
|
|
60
|
+
If the command fails because the state is missing, ensure you are providing the correct lane name. Use `cursorflow monitor` to see the names of the lanes in the latest run.
|
|
124
61
|
|
|
125
62
|
### Worktree issues
|
|
126
|
-
|
|
127
|
-
# List worktrees
|
|
128
|
-
git worktree list
|
|
129
|
-
|
|
130
|
-
# Remove problematic worktree
|
|
131
|
-
git worktree remove <path> --force
|
|
132
|
-
|
|
133
|
-
# Resume
|
|
134
|
-
cursorflow resume 01-dashboard --restart
|
|
135
|
-
```
|
|
136
|
-
|
|
137
|
-
### Dependency blocks
|
|
138
|
-
```bash
|
|
139
|
-
# Verify dependencies are resolved
|
|
140
|
-
cursorflow monitor
|
|
141
|
-
|
|
142
|
-
# Resume after resolving
|
|
143
|
-
cursorflow resume 01-dashboard
|
|
144
|
-
```
|
|
63
|
+
If the worktree directory was manually deleted, use the `--clean` or `--restart` flag to allow CursorFlow to recreate the environment.
|
|
145
64
|
|
|
146
|
-
|
|
65
|
+
### Branch conflicts
|
|
66
|
+
If resume fails due to branch conflicts:
|
|
147
67
|
|
|
148
|
-
### Scenario 1: Interrupted by network errors
|
|
149
68
|
```bash
|
|
150
|
-
#
|
|
151
|
-
|
|
152
|
-
```
|
|
69
|
+
# Check what branches exist
|
|
70
|
+
git branch --list "feature/*"
|
|
153
71
|
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
cd .cursorflow/logs/worktrees/01-dashboard-xxx/
|
|
158
|
-
# ... apply fixes ...
|
|
159
|
-
git add -A
|
|
160
|
-
git commit -m "fix: build error"
|
|
161
|
-
|
|
162
|
-
# Continue from the next task
|
|
163
|
-
cursorflow resume 01-dashboard
|
|
164
|
-
```
|
|
72
|
+
# Clean up old CursorFlow branches
|
|
73
|
+
cursorflow clean branches --dry-run
|
|
74
|
+
cursorflow clean branches
|
|
165
75
|
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
1. Increase the timeout in your task JSON:
|
|
169
|
-
```json
|
|
170
|
-
{ "timeout": 600000 }
|
|
171
|
-
```
|
|
172
|
-
2. Resume the lane:
|
|
173
|
-
```bash
|
|
174
|
-
cursorflow resume 01-dashboard
|
|
175
|
-
```
|
|
176
|
-
|
|
177
|
-
### Scenario 3: Branch conflicts
|
|
178
|
-
```bash
|
|
179
|
-
# Clean branches then restart
|
|
180
|
-
cursorflow resume 01-dashboard --clean
|
|
181
|
-
```
|
|
182
|
-
|
|
183
|
-
### Scenario 4: Start over
|
|
184
|
-
```bash
|
|
185
|
-
# Reset all state
|
|
186
|
-
cursorflow resume 01-dashboard --restart
|
|
76
|
+
# Or manually delete specific branches
|
|
77
|
+
git branch -D feature/lane-1-old-branch
|
|
187
78
|
```
|
|
188
79
|
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
80
|
+
### Changed branch prefix
|
|
81
|
+
If the task JSON file's `branchPrefix` was changed after the initial run:
|
|
82
|
+
1. Either restore the original prefix in the JSON
|
|
83
|
+
2. Or use `--restart` to start fresh with the new prefix
|
|
84
|
+
3. Or manually clean up old branches with `cursorflow clean branches`
|
|
@@ -1,220 +1,56 @@
|
|
|
1
|
-
# CursorFlow Review
|
|
1
|
+
# CursorFlow Automatic Review
|
|
2
2
|
|
|
3
3
|
## Overview
|
|
4
|
-
|
|
4
|
+
CursorFlow features an integrated AI-powered code review system. It automatically validates task results against your defined acceptance criteria and can provide feedback to the agent for iterative improvements.
|
|
5
5
|
|
|
6
|
-
##
|
|
6
|
+
## Configuration
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
### Project-wide Settings
|
|
9
|
+
Enable and configure the review process in your `cursorflow.config.js`:
|
|
9
10
|
|
|
10
|
-
Configure `cursorflow.config.js`:
|
|
11
|
-
```javascript
|
|
12
|
-
module.exports = {
|
|
13
|
-
enableReview: true,
|
|
14
|
-
reviewModel: 'sonnet-4.5-thinking',
|
|
15
|
-
maxReviewIterations: 3,
|
|
16
|
-
// ...
|
|
17
|
-
};
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
2. **Define acceptance criteria**
|
|
21
|
-
|
|
22
|
-
Add validation criteria to the task JSON file:
|
|
23
|
-
```json
|
|
24
|
-
{
|
|
25
|
-
"tasks": [
|
|
26
|
-
{
|
|
27
|
-
"name": "implement",
|
|
28
|
-
"model": "sonnet-4.5",
|
|
29
|
-
"acceptanceCriteria": [
|
|
30
|
-
"No build errors",
|
|
31
|
-
"No TypeScript type errors",
|
|
32
|
-
"Key functionality implemented",
|
|
33
|
-
"Tests passing"
|
|
34
|
-
],
|
|
35
|
-
"prompt": "..."
|
|
36
|
-
}
|
|
37
|
-
]
|
|
38
|
-
}
|
|
39
|
-
```
|
|
40
|
-
|
|
41
|
-
3. **Run reviews**
|
|
42
|
-
|
|
43
|
-
Reviews start automatically after each task completes.
|
|
44
|
-
|
|
45
|
-
4. **Check review results**
|
|
46
|
-
```bash
|
|
47
|
-
# Inspect the review output
|
|
48
|
-
cat _cursorflow/logs/runs/<lane>/review-results.json
|
|
49
|
-
```
|
|
50
|
-
|
|
51
|
-
## Review models
|
|
52
|
-
|
|
53
|
-
| Model | Characteristics | Recommended use |
|
|
54
|
-
|------|------|-----------|
|
|
55
|
-
| `sonnet-4.5-thinking` | Strong reasoning, precise analysis | General code reviews (recommended) |
|
|
56
|
-
| `opus-4.5-thinking` | Highest quality, detailed reviews | Critical code or architecture reviews |
|
|
57
|
-
| `sonnet-4.5` | Faster reviews | Simple changes |
|
|
58
|
-
|
|
59
|
-
## Review process
|
|
60
|
-
|
|
61
|
-
1. **Task completion**
|
|
62
|
-
- Finish implementation
|
|
63
|
-
- Create a commit
|
|
64
|
-
|
|
65
|
-
2. **Automatic review**
|
|
66
|
-
- Run the agent with the selected review model
|
|
67
|
-
- Verify acceptance criteria
|
|
68
|
-
- Validate build and types
|
|
69
|
-
|
|
70
|
-
3. **Review outcome**
|
|
71
|
-
- `approved`: proceed to the next task
|
|
72
|
-
- `needs_changes`: send feedback β rework
|
|
73
|
-
|
|
74
|
-
4. **Feedback loop**
|
|
75
|
-
- Apply fixes
|
|
76
|
-
- Re-run the review
|
|
77
|
-
- Repeat until the maximum iteration count
|
|
78
|
-
|
|
79
|
-
## Review result format
|
|
80
|
-
|
|
81
|
-
```json
|
|
82
|
-
{
|
|
83
|
-
"status": "approved",
|
|
84
|
-
"buildSuccess": true,
|
|
85
|
-
"typeCheckSuccess": true,
|
|
86
|
-
"issues": [
|
|
87
|
-
{
|
|
88
|
-
"severity": "warning",
|
|
89
|
-
"description": "Consider adding error handling",
|
|
90
|
-
"file": "src/utils/api.js",
|
|
91
|
-
"line": 42,
|
|
92
|
-
"suggestion": "Add try-catch block"
|
|
93
|
-
}
|
|
94
|
-
],
|
|
95
|
-
"suggestions": [
|
|
96
|
-
"Add unit tests for edge cases",
|
|
97
|
-
"Improve error messages"
|
|
98
|
-
],
|
|
99
|
-
"summary": "Code quality is good, minor improvements suggested",
|
|
100
|
-
"reviewedBy": "sonnet-4.5-thinking",
|
|
101
|
-
"reviewedAt": "2025-12-19T18:30:00Z"
|
|
102
|
-
}
|
|
103
|
-
```
|
|
104
|
-
|
|
105
|
-
## Examples
|
|
106
|
-
|
|
107
|
-
### Standard review settings
|
|
108
11
|
```javascript
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
}
|
|
12
|
+
module.exports = {
|
|
13
|
+
enableReview: true, // Enable automatic reviews
|
|
14
|
+
reviewModel: 'sonnet-4.5-thinking', // Model to use for reviewing
|
|
15
|
+
maxReviewIterations: 3, // Number of fix/re-review cycles
|
|
16
|
+
// ...
|
|
17
|
+
};
|
|
115
18
|
```
|
|
116
19
|
|
|
117
|
-
###
|
|
118
|
-
|
|
119
|
-
{
|
|
120
|
-
enableReview: true,
|
|
121
|
-
reviewModel: 'opus-4.5-thinking',
|
|
122
|
-
maxReviewIterations: 5
|
|
123
|
-
}
|
|
124
|
-
```
|
|
125
|
-
|
|
126
|
-
### Fast reviews
|
|
127
|
-
```javascript
|
|
128
|
-
{
|
|
129
|
-
enableReview: true,
|
|
130
|
-
reviewModel: 'sonnet-4.5',
|
|
131
|
-
maxReviewIterations: 1
|
|
132
|
-
}
|
|
133
|
-
```
|
|
134
|
-
|
|
135
|
-
## Acceptance criteria writing guide
|
|
136
|
-
|
|
137
|
-
### Good examples
|
|
138
|
-
```json
|
|
139
|
-
{
|
|
140
|
-
"acceptanceCriteria": [
|
|
141
|
-
"No build errors (pnpm build succeeds)",
|
|
142
|
-
"No TypeScript type errors (pnpm type-check)",
|
|
143
|
-
"All existing tests pass",
|
|
144
|
-
"Three new API endpoints implemented",
|
|
145
|
-
"Error handling logic included",
|
|
146
|
-
"Logging added"
|
|
147
|
-
]
|
|
148
|
-
}
|
|
149
|
-
```
|
|
20
|
+
### Task-level Criteria
|
|
21
|
+
Add `acceptanceCriteria` to your task JSON to guide the reviewer:
|
|
150
22
|
|
|
151
|
-
### Poor examples
|
|
152
23
|
```json
|
|
153
24
|
{
|
|
154
|
-
"
|
|
155
|
-
|
|
156
|
-
|
|
25
|
+
"tasks": [
|
|
26
|
+
{
|
|
27
|
+
"name": "implement-logic",
|
|
28
|
+
"acceptanceCriteria": [
|
|
29
|
+
"No build errors",
|
|
30
|
+
"Tests in src/tests/ pass",
|
|
31
|
+
"Code follows project style guide"
|
|
32
|
+
],
|
|
33
|
+
"prompt": "..."
|
|
34
|
+
}
|
|
157
35
|
]
|
|
158
36
|
}
|
|
159
37
|
```
|
|
160
38
|
|
|
161
|
-
##
|
|
162
|
-
|
|
163
|
-
### When approved
|
|
164
|
-
```bash
|
|
165
|
-
# The next task proceeds automatically
|
|
166
|
-
# Confirm in the logs
|
|
167
|
-
cursorflow monitor
|
|
168
|
-
```
|
|
169
|
-
|
|
170
|
-
### When changes are needed
|
|
171
|
-
```bash
|
|
172
|
-
# Feedback is passed back to the agent
|
|
173
|
-
# After rework, the review re-runs automatically
|
|
174
|
-
# View feedback in the logs
|
|
175
|
-
cat _cursorflow/logs/runs/<lane>/conversation.jsonl | \
|
|
176
|
-
jq 'select(.role=="reviewer")'
|
|
177
|
-
```
|
|
178
|
-
|
|
179
|
-
### When the max iterations are hit
|
|
180
|
-
```bash
|
|
181
|
-
# Continue with a warning
|
|
182
|
-
# Manual review is required
|
|
183
|
-
```
|
|
184
|
-
|
|
185
|
-
## Checklist
|
|
186
|
-
- [ ] Is review enabled?
|
|
187
|
-
- [ ] Is the review model appropriate?
|
|
188
|
-
- [ ] Are the acceptance criteria clear?
|
|
189
|
-
- [ ] Is the max iteration count reasonable?
|
|
190
|
-
- [ ] Have you inspected the review results?
|
|
191
|
-
|
|
192
|
-
## Troubleshooting
|
|
193
|
-
|
|
194
|
-
### Reviews are not running
|
|
195
|
-
1. Confirm `enableReview: true`.
|
|
196
|
-
2. Verify the review model name is valid.
|
|
197
|
-
3. Check logs for errors.
|
|
198
|
-
|
|
199
|
-
### Infinite review loop
|
|
200
|
-
1. Check the `maxReviewIterations` setting.
|
|
201
|
-
2. Ensure the acceptance criteria are achievable.
|
|
202
|
-
3. Improve the task prompts.
|
|
203
|
-
|
|
204
|
-
### Reviews are too strict
|
|
205
|
-
1. Switch to a more lenient review model.
|
|
206
|
-
2. Adjust the acceptance criteria.
|
|
207
|
-
3. Increase `maxReviewIterations`.
|
|
39
|
+
## The Review Process
|
|
208
40
|
|
|
209
|
-
|
|
41
|
+
1. **Completion**: When an agent finishes a task, CursorFlow spawns a reviewer agent.
|
|
42
|
+
2. **Analysis**: The reviewer checks the worktree against the `acceptanceCriteria` using the `reviewModel`.
|
|
43
|
+
3. **Verdict**:
|
|
44
|
+
- **Approved**: The lane proceeds to the next task.
|
|
45
|
+
- **Needs Changes**: The reviewer's feedback is sent back to the original agent.
|
|
46
|
+
4. **Fix Loop**: The agent attempts to fix the issues based on the feedback. This repeats up to `maxReviewIterations`.
|
|
210
47
|
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
|
|
214
|
-
|
|
48
|
+
## Monitoring Reviews
|
|
49
|
+
You can track the review process in real-time using `cursorflow monitor`.
|
|
50
|
+
- The lane status will change to **`reviewing`** (`π`).
|
|
51
|
+
- Reviewer feedback appears in the conversation history as a **`REVIEWER`** message.
|
|
215
52
|
|
|
216
|
-
##
|
|
217
|
-
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
4. Tune the review model as needed.
|
|
53
|
+
## Best Practices
|
|
54
|
+
- **Specific Criteria**: Use clear, measurable criteria (e.g., "Build succeeds with `npm run build`").
|
|
55
|
+
- **Thinking Models**: Use reasoning-heavy models like `sonnet-4.5-thinking` for reviews to get better results.
|
|
56
|
+
- **Reasonable Iterations**: Set `maxReviewIterations` to 2 or 3 to prevent infinite loops.
|