cc-reviewer 6.0.0 → 6.1.0

package/commands/multi-consult.md

@@ -34,6 +34,35 @@ If the question references the codebase, populate `relevantFiles` with the minim
 
 If the current working directory is `/etc`, `~`, `~/.ssh`, or any other clearly sensitive system path, **refuse**. Tell the user: "Please invoke `/multi-consult` from a project root — `<cwd>` looks sensitive." Do not call the tool.
 
+### 4. Extract criteria; clarify load-bearing assumptions BEFORE calling
+
+Pin what the question is being judged against. Once criteria are explicit, the panel's recommendation is anchored to them instead of floating — this is the fix for "ask twice, get a different answer." Stochastic re-runs converge much better against fixed criteria than against an under-specified question.
+
+**4a. Append a CRITERIA block to the end of `question`**, priority-ordered, each tagged `[stated]` or `[assumed]`:
+
+```
+CRITERIA (priority order):
+1. [stated] cost-per-request under $X / 1M ops
+2. [stated] team writes Go; minimize ops complexity
+3. [assumed] sustained ~10k QPS write rate
+4. [assumed] eventual consistency acceptable for analytics
+```
+
+- `[stated]` = explicit in the user's message or earlier conversation.
+- `[assumed]` = you needed to fix it to recommend; the user did NOT say.
+- Cap `[assumed]` at 3. If the top 3 don't fit, the question is too vague — bounce back to the user before calling.
+
+**4b. Pre-call clarification gate.** Scan your `[assumed]` criteria. If any is **load-bearing** (the recommendation would flip if the assumption is wrong), STOP and ask the user before invoking the tool:
+
+> "Before I consult the panel, I need to confirm: <restate assumption>. Is that right, or should I adjust to <plausible alternative>?"
+
+A burned panel call on a wrong assumed criterion costs more than the round-trip.
+
+**Skip the gate when:**
+- `[stated]` criteria fully pin the answer space (no assumptions needed).
+- The user told you to proceed without clarification.
+- Remaining assumptions are clearly incidental (would not flip the rec).
+
 ## Tool Invocation
 
 Call `multi_consult` with:

package/commands/multi-review.md

@@ -23,17 +23,27 @@ Use `/multi-review` when you want thorough parallel reviews from all available m
 
 ## Before Calling - PREPARE THE HANDOFF
 
-### 1. Summarize What You Did (Brief!)
+### 1. Summarize What You Did + State the Acceptance Bar
+
+Don't just say what you did — also state the bar the work needs to clear. The bar is what lets reviewers calibrate "material" vs "nice to have." Without it, reviewers default to general code-quality vibes, which produces drift across runs.
+
 ```
-"Implemented caching layer for the product catalog API using Redis.
-Added cache invalidation on product updates."
+"Implemented caching layer for the product catalog API using Redis with cache invalidation on product updates.
+Bar: safe under concurrent updates (no stale reads on the next request) AND p95 read latency under 50ms."
 ```
 
-### 2. List Your Uncertainties
+### 2. List Your Uncertainties — Tag Load-Bearing vs Incidental
+
+Tag each uncertainty:
+- `[load-bearing]` = if your assumption here is wrong, the work is NOT shipping-ready
+- `[incidental]` = nice to verify but won't block ship
+
+Reviewers prioritize accordingly, and your synthesis can elevate `[load-bearing]` items above stylistic findings.
+
 ```
 UNCERTAINTIES:
-- "Is the cache TTL appropriate for this data?"
-- "Does the invalidation handle all update scenarios?"
+- [load-bearing] "Is the cache invalidation race-free under concurrent updates?"
+- [incidental] "Is the TTL value optimal — could it be 60s instead of 30s?"
 ```
 
 ### 3. Ask Specific Questions
@@ -43,6 +53,16 @@ QUESTIONS:
 - "Is there a race condition in the invalidation logic?"
 ```
 
+### 4. Identify Decisions You Made
+
+If you chose between alternatives — caching strategy, retry policy, error-handling shape, schema design, etc. — list them with rationale. The handoff schema's `decisions[]` field gives the adversarial reviewer a concrete hook to attack the design choice rather than just hunt for bugs. Skip if the change is a straightforward bug fix with no design choice involved.
+
+```
+DECISIONS:
+1. Chose write-through cache over write-behind. Rationale: stronger read-after-write consistency at the cost of slightly slower writes; we prioritize correctness for catalog data.
+2. Chose 30s TTL with explicit invalidation on update. Rationale: TTL bounds staleness if invalidation misses; explicit invalidation catches the common path immediately.
+```
+
 ## Tool Invocation
 
 Call `multi_review` with:
@@ -67,14 +87,19 @@ Call `multi_review` with:
 ```
 SUMMARY:
 <what you did, 1-3 sentences>
+Bar: <what counts as shipping-ready — concrete acceptance criteria>
 
 UNCERTAINTIES (verify these):
-1. <uncertainty>
-2. <uncertainty>
+1. [load-bearing|incidental] <uncertainty>
+2. [load-bearing|incidental] <uncertainty>
 
 QUESTIONS:
 1. <question>
 
+DECISIONS:
+1. <choice>. Rationale: <why this over alternatives>
+2. <choice>. Rationale: <why this over alternatives>
+
 PRIORITY FILES:
 - <file>
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-reviewer",
-  "version": "6.0.0",
+  "version": "6.1.0",
   "description": "MCP server for Claude Code - Get second-opinion feedback from Codex/Gemini CLIs",
   "type": "module",
   "main": "dist/index.js",