@kurrent/kcap 0.11.31 → 0.11.32
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,94 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: suggest-review-flow
|
|
3
|
+
description: >-
|
|
4
|
+
Use this skill when implementation is complete — a feature or bugfix is functionally
|
|
5
|
+
finished, tests pass, or you are about to commit / open a PR / merge — or when a spec is
|
|
6
|
+
finalized. At that moment, proactively OFFER an independent second-harness review even if
|
|
7
|
+
the user did not ask, because a fresh, separate reviewer catches what the author's own model
|
|
8
|
+
misses. It calls list_reviewer_vendors to recommend a reviewer that will actually run for
|
|
9
|
+
this repo, offers a spec-review or code-review flow, and hands off to the review-flows skill
|
|
10
|
+
only after the user accepts — it never starts a flow itself. Do NOT use it when the user
|
|
11
|
+
asks you to review something yourself ("review this", "code review this", "look over my
|
|
12
|
+
spec"), or mid-task before the work is finished.
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
# Suggest a review flow
|
|
16
|
+
|
|
17
|
+
You have reached a milestone where an **independent** review adds real value: a
|
|
18
|
+
separate coding-agent session, with none of this session's context, reviews the
|
|
19
|
+
work — and a different model catches what the author's own model glossed over.
|
|
20
|
+
Most people never think to do this. Your job here is to **offer** it at the
|
|
21
|
+
right moment, recommend a reviewer that will actually run, and — only if the
|
|
22
|
+
user says yes — hand off to the `review-flows` skill. **This skill never starts
|
|
23
|
+
a review flow itself.**
|
|
24
|
+
|
|
25
|
+
## When to offer (and when not to)
|
|
26
|
+
|
|
27
|
+
Offer at exactly two milestones:
|
|
28
|
+
|
|
29
|
+
- **Spec complete** — you just produced AND presented a finalized spec/design
|
|
30
|
+
this session → offer a `spec-review` flow.
|
|
31
|
+
- **Implementation complete** — the change is functionally finished (you say so,
|
|
32
|
+
or you are about to commit / open a PR / merge) → offer a `code-review` flow.
|
|
33
|
+
|
|
34
|
+
Do NOT offer (stay silent) when:
|
|
35
|
+
|
|
36
|
+
- The user asked you to **review something yourself** ("review this", "code
|
|
37
|
+
review this", "look over the spec"). Just perform that review locally — no
|
|
38
|
+
offer, no flow.
|
|
39
|
+
- You are only part-way through: rough mid-stream brainstorming, a partial plan,
|
|
40
|
+
a routine edit, or work whose known checks are still failing.
|
|
41
|
+
- A review flow for this artifact is already engaged, active, or just completed.
|
|
42
|
+
- Another skill (brainstorming, writing-plans, finishing-a-development-branch,
|
|
43
|
+
requesting-code-review) is mid-flow — let it finish; offer at the seam.
|
|
44
|
+
|
|
45
|
+
**Offer at most once per artifact.** Key the offer on (milestone type + the
|
|
46
|
+
target's identity + its revision): the same spec or the same change never gets
|
|
47
|
+
offered twice, but a materially revised artifact may be offered again, and a
|
|
48
|
+
second, different artifact of the same kind may be offered on its own. If the
|
|
49
|
+
user declines or moves on, stay silent for that artifact. A failed availability
|
|
50
|
+
lookup counts as the one prompt for that artifact — do not re-prompt.
|
|
51
|
+
|
|
52
|
+
## How to recommend a reviewer
|
|
53
|
+
|
|
54
|
+
1. Call **`list_reviewer_vendors`** (read-only; safe to call before offering).
|
|
55
|
+
It returns `reviewers[]` (vendors that can actually run for this repo now),
|
|
56
|
+
`driver_vendor` (the harness you are running in, or absent if unknown), and
|
|
57
|
+
`diagnostics`.
|
|
58
|
+
2. **Prefer a reviewer different from the driver.** A different model is the
|
|
59
|
+
highest-value review. If one non-driver reviewer is available, recommend it;
|
|
60
|
+
if several, offer a short choice — never assert one vendor is "better".
|
|
61
|
+
3. **If the only available reviewer is your own vendor, still offer it** —
|
|
62
|
+
framed as an independent, context-free reviewer session. The value is the
|
|
63
|
+
clean second look, not necessarily a different model.
|
|
64
|
+
4. **If `driver_vendor` is absent (unknown)**, do NOT claim "a different model";
|
|
65
|
+
frame the offer as "a separate, independent reviewer session" and offer a
|
|
66
|
+
choice from `reviewers[]`.
|
|
67
|
+
5. **If `reviewers[]` is empty**, read `diagnostics.reason` and give one line of
|
|
68
|
+
guidance instead of a dead end:
|
|
69
|
+
- `no_daemons_connected` → start a daemon (`kcap daemon start -d`).
|
|
70
|
+
- `no_repo_hosting_daemon` → run a daemon on a machine that has this repo.
|
|
71
|
+
- `no_unattended_reviewer` → install/certify a second harness as a reviewer.
|
|
72
|
+
- `repo_unresolved` → the current directory isn't a recognized repo.
|
|
73
|
+
- `lookup_failed` → couldn't reach the server; suggest checking `kcap status`.
|
|
74
|
+
- `schema_skew` → the kcap client/server is out of date; suggest updating.
|
|
75
|
+
|
|
76
|
+
## Handing off (only after the user accepts)
|
|
77
|
+
|
|
78
|
+
- You MAY run the read-only `list_reviewer_vendors` lookup automatically, but you
|
|
79
|
+
**MUST NOT start a review flow until the user affirmatively accepts THIS
|
|
80
|
+
offer.**
|
|
81
|
+
- On acceptance, invoke the **`review-flows`** skill to run it, preserving the
|
|
82
|
+
chosen `kind` (spec-review / code-review), the target, and the chosen reviewer
|
|
83
|
+
vendor.
|
|
84
|
+
- If the reviewer vendor turns out to be unavailable at start (a snapshot race),
|
|
85
|
+
`review-flows` surfaces the reason — do not silently substitute another vendor;
|
|
86
|
+
re-recommend and get fresh consent.
|
|
87
|
+
|
|
88
|
+
## If `list_reviewer_vendors` is not available
|
|
89
|
+
|
|
90
|
+
Your harness caches the kcap MCP tool list when it connects. If kcap was
|
|
91
|
+
upgraded mid-session, `list_reviewer_vendors` may be missing from this session.
|
|
92
|
+
Do NOT guess availability and do NOT shell out as a workaround — tell the user
|
|
93
|
+
to restart the harness (or reconnect the `kcap-flows` MCP server) so the tool
|
|
94
|
+
appears, then offer again.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@kurrent/kcap",
|
|
3
|
-
"version": "0.11.
|
|
3
|
+
"version": "0.11.32",
|
|
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,17 +14,17 @@
|
|
|
14
14
|
"postinstall": "node bin/postinstall.js"
|
|
15
15
|
},
|
|
16
16
|
"optionalDependencies": {
|
|
17
|
-
"@kurrent/kcap-darwin-arm64": "0.11.
|
|
18
|
-
"@kurrent/kcap-linux-arm64": "0.11.
|
|
19
|
-
"@kurrent/kcap-linux-musl-arm64": "0.11.
|
|
20
|
-
"@kurrent/kcap-linux-musl-x64": "0.11.
|
|
21
|
-
"@kurrent/kcap-linux-x64": "0.11.
|
|
22
|
-
"@kurrent/kcap-win-x64": "0.11.
|
|
17
|
+
"@kurrent/kcap-darwin-arm64": "0.11.32",
|
|
18
|
+
"@kurrent/kcap-linux-arm64": "0.11.32",
|
|
19
|
+
"@kurrent/kcap-linux-musl-arm64": "0.11.32",
|
|
20
|
+
"@kurrent/kcap-linux-musl-x64": "0.11.32",
|
|
21
|
+
"@kurrent/kcap-linux-x64": "0.11.32",
|
|
22
|
+
"@kurrent/kcap-win-x64": "0.11.32"
|
|
23
23
|
},
|
|
24
24
|
"files": [
|
|
25
25
|
"bin/",
|
|
26
26
|
"kcap/"
|
|
27
27
|
],
|
|
28
|
-
"kcapReleaseCommit": "
|
|
29
|
-
"kcapReleaseTag": "v0.11.
|
|
28
|
+
"kcapReleaseCommit": "e5b1eae185076df2ed3d6fc5914ad5648ea91ab2",
|
|
29
|
+
"kcapReleaseTag": "v0.11.32"
|
|
30
30
|
}
|