@kurrent/kcap 0.7.13 → 0.8.1
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.
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-flows
|
|
3
|
+
description: >-
|
|
4
|
+
This skill should be used when the user asks to "review this spec",
|
|
5
|
+
"review this design", "review my PR", "code review", "get this reviewed",
|
|
6
|
+
"re-review", "start a review flow", "review flow", "submit for review",
|
|
7
|
+
or wants structured iterative review with findings and sign-off.
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Review Flows
|
|
11
|
+
|
|
12
|
+
Use `kcap mcp flows` MCP tools to run structured review loops for specs/designs and PR/code work. A review flow submits your work to a reviewer, collects findings, lets you address them, and keeps iterating until the reviewer returns `NO FINDINGS`.
|
|
13
|
+
|
|
14
|
+
## When to use
|
|
15
|
+
|
|
16
|
+
- Reviewing a spec or design document → use `kind: "spec-review"`
|
|
17
|
+
- Reviewing code changes or a pull request → use `kind: "code-review"`
|
|
18
|
+
|
|
19
|
+
## Core rules
|
|
20
|
+
|
|
21
|
+
1. **Start exactly one flow per user task.** Call `start_review_flow` once and hold the returned `flow_run_id`. Do NOT start a new flow for follow-up rounds — reuse the same ID.
|
|
22
|
+
2. **After receiving `FINDINGS:`**, address every finding, then call `submit_review_round` with the updated context and the same `flow_run_id`.
|
|
23
|
+
3. **Do NOT finish the user task while the flow has unresolved findings.** Keep iterating until the reviewer returns `NO FINDINGS`.
|
|
24
|
+
4. **Only call `close_review_flow` after `NO FINDINGS`.** Then report completion to the user.
|
|
25
|
+
5. **If reviewer output is unclear or requires user input**, pause and ask the user before proceeding.
|
|
26
|
+
6. **For code review, do NOT ask the reviewer to run tests.** CI covers test execution; reviewer feedback is on correctness, design, and adherence to conventions.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
start_review_flow(kind, target_kind, target_ref, target_title, context)
|
|
32
|
+
→ reviewer returns FINDINGS: … | NO FINDINGS
|
|
33
|
+
|
|
34
|
+
if NO FINDINGS:
|
|
35
|
+
close_review_flow(flow_run_id)
|
|
36
|
+
report completion to user
|
|
37
|
+
DONE
|
|
38
|
+
|
|
39
|
+
if FINDINGS:
|
|
40
|
+
address each finding
|
|
41
|
+
submit_review_round(flow_run_id, updated_context)
|
|
42
|
+
→ repeat until NO FINDINGS
|
|
43
|
+
close_review_flow(flow_run_id)
|
|
44
|
+
report completion to user
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Tool reference
|
|
48
|
+
|
|
49
|
+
| Tool | Required args | Optional args | When to call |
|
|
50
|
+
|---|---|---|---|
|
|
51
|
+
| `start_review_flow` | `kind` (`spec-review`\|`code-review`), `target_kind` (what is being reviewed: `spec`, `code`, `pr`, `branch`, `file`, etc.), `target_ref` (a path, branch name, or PR URL/number that identifies the target), `target_title` (short human-readable title, e.g. spec name or PR title), `context` (background context: what to focus on, constraints, definition of done) | `instructions`, `mode` (`context-only` — required for code-review unless the reviewer runs in your exact repo checkout) | Once, at the start of a review task. |
|
|
52
|
+
| `submit_review_round` | `flow_run_id`, `context` | `instructions` | After addressing findings. Pass the same `flow_run_id` and the updated context. |
|
|
53
|
+
| `get_review_flow_status` | `flow_run_id` | — | Poll or check the current status of a flow (running, waiting, completed, failed). |
|
|
54
|
+
| `close_review_flow` | `flow_run_id` | — | Only after the reviewer returns `NO FINDINGS`. |
|
|
55
|
+
|
|
56
|
+
## Example (code review)
|
|
57
|
+
|
|
58
|
+
```
|
|
59
|
+
# Step 1 — start (all five required args must be provided; mode=context-only is required for code-review)
|
|
60
|
+
start_review_flow(
|
|
61
|
+
kind="code-review",
|
|
62
|
+
target_kind="branch",
|
|
63
|
+
target_ref="feature/add-null-check",
|
|
64
|
+
target_title="Add null check on user input",
|
|
65
|
+
context="Review the diff on this branch for correctness and adherence to project conventions.",
|
|
66
|
+
mode="context-only"
|
|
67
|
+
)
|
|
68
|
+
# → returns flow_run_id, e.g. "flow_abc123"
|
|
69
|
+
# → reviewer returns FINDINGS: missing null check on line 42
|
|
70
|
+
|
|
71
|
+
# Step 2 — address findings, then re-submit
|
|
72
|
+
submit_review_round(
|
|
73
|
+
flow_run_id="flow_abc123",
|
|
74
|
+
context="Fixed null check on line 42. Updated diff attached."
|
|
75
|
+
)
|
|
76
|
+
|
|
77
|
+
# Step 3 — reviewer returns NO FINDINGS
|
|
78
|
+
close_review_flow(flow_run_id="flow_abc123")
|
|
79
|
+
# Report to user: review complete, all findings resolved
|
|
80
|
+
```
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@kurrent/kcap",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.8.1",
|
|
4
4
|
"description": "CLI companion for Kurrent Capacitor — records and visualizes Claude Code sessions",
|
|
5
5
|
"license": "SEE LICENSE IN LICENSE.md",
|
|
6
6
|
"repository": {
|
|
@@ -14,12 +14,12 @@
|
|
|
14
14
|
"postinstall": "node bin/postinstall.js"
|
|
15
15
|
},
|
|
16
16
|
"optionalDependencies": {
|
|
17
|
-
"@kurrent/kcap-darwin-arm64": "0.
|
|
18
|
-
"@kurrent/kcap-linux-x64": "0.
|
|
19
|
-
"@kurrent/kcap-linux-arm64": "0.
|
|
20
|
-
"@kurrent/kcap-linux-musl-x64": "0.
|
|
21
|
-
"@kurrent/kcap-linux-musl-arm64": "0.
|
|
22
|
-
"@kurrent/kcap-win-x64": "0.
|
|
17
|
+
"@kurrent/kcap-darwin-arm64": "0.8.1",
|
|
18
|
+
"@kurrent/kcap-linux-x64": "0.8.1",
|
|
19
|
+
"@kurrent/kcap-linux-arm64": "0.8.1",
|
|
20
|
+
"@kurrent/kcap-linux-musl-x64": "0.8.1",
|
|
21
|
+
"@kurrent/kcap-linux-musl-arm64": "0.8.1",
|
|
22
|
+
"@kurrent/kcap-win-x64": "0.8.1"
|
|
23
23
|
},
|
|
24
24
|
"files": [
|
|
25
25
|
"bin/",
|