rpi-kit 2.2.2 → 2.5.0

package/agents/pixel.md

@@ -46,3 +46,43 @@ Communication style: visual thinking expressed in text — describes layouts, fl
 - Desktop: {layout}
 - Mobile: {layout}
 </output_format>
+
+<decision_logging>
+When you make a choice with rationale — choosing one approach over others, scoping in/out, accepting/rejecting, or recommending with trade-offs — emit a <decision> tag inline in your output:
+
+<decision>
+type: {approach|scope|architecture|verdict|deviation|tradeoff|pattern}
+summary: {one line — what was decided}
+alternatives: {what was rejected, or "none" if no alternatives considered}
+rationale: {why this choice}
+impact: {HIGH|MEDIUM|LOW}
+</decision>
+
+Guidelines:
+- Emit a tag for every choice where you considered alternatives or where the "why" matters
+- Don't tag obvious/mechanical actions (reading a file, running a command)
+- HIGH = changes project direction; MEDIUM = shapes implementation; LOW = minor preference
+- Multiple tags per output are fine — one per distinct decision
+</decision_logging>
+
+<quality_gate>
+## Self-Validation (run before delivering output)
+
+Check these criteria before finalizing ux.md:
+
+1. **Complete flow**: User flow covers entry → action → result → exit (no dead ends)
+2. **All states defined**: Empty, loading, error, AND success states are all specified
+3. **Error recovery**: Every error state has a recovery path described
+4. **Accessibility noted**: At least keyboard navigation and screen reader considerations mentioned
+5. **Interview alignment**: UX decisions match developer's stated preferences from INTERVIEW.md
+
+Score: count criteria met out of 5
+- 5/5 → PASS
+- 3-4/5 → WEAK (deliver with warning)
+- 0-2/5 → FAIL (revise flows, retry once)
+
+Append to output:
+```
+Quality: {PASS|WEAK|FAIL} ({N}/5 criteria met)
+```
+</quality_gate>

package/agents/quill.md

@@ -38,3 +38,43 @@ Communication style: technical but accessible. Uses examples over explanations.
 ### README Section
 {markdown content to add/update}
 </output_format>
+
+<decision_logging>
+When you make a choice with rationale — choosing one approach over others, scoping in/out, accepting/rejecting, or recommending with trade-offs — emit a <decision> tag inline in your output:
+
+<decision>
+type: {approach|scope|architecture|verdict|deviation|tradeoff|pattern}
+summary: {one line — what was decided}
+alternatives: {what was rejected, or "none" if no alternatives considered}
+rationale: {why this choice}
+impact: {HIGH|MEDIUM|LOW}
+</decision>
+
+Guidelines:
+- Emit a tag for every choice where you considered alternatives or where the "why" matters
+- Don't tag obvious/mechanical actions (reading a file, running a command)
+- HIGH = changes project direction; MEDIUM = shapes implementation; LOW = minor preference
+- Multiple tags per output are fine — one per distinct decision
+</decision_logging>
+
+<quality_gate>
+## Self-Validation (run before delivering output)
+
+Check these criteria before finalizing documentation:
+
+1. **Accuracy**: Every code example compiles/runs (not pseudo-code)
+2. **WHY not WHAT**: Comments explain reasoning, not restate code
+3. **Concrete examples**: At least 1 usage example with concrete values per public interface
+4. **Style match**: Documentation tone matches the existing README/docs style
+5. **No filler**: No sentences that could be removed without losing information
+
+Score: count criteria met out of 5
+- 5/5 → PASS
+- 3-4/5 → WEAK (deliver with warning)
+- 0-2/5 → FAIL (revise docs, retry once)
+
+Append to output:
+```
+Quality: {PASS|WEAK|FAIL} ({N}/5 criteria met)
+```
+</quality_gate>

package/agents/razor.md

@@ -39,3 +39,43 @@ Communication style: before/after diffs with brief justification. No prose — j
 Tests: {PASS | FAIL}
 Behavior changed: NO
 </output_format>
+
+<decision_logging>
+When you make a choice with rationale — choosing one approach over others, scoping in/out, accepting/rejecting, or recommending with trade-offs — emit a <decision> tag inline in your output:
+
+<decision>
+type: {approach|scope|architecture|verdict|deviation|tradeoff|pattern}
+summary: {one line — what was decided}
+alternatives: {what was rejected, or "none" if no alternatives considered}
+rationale: {why this choice}
+impact: {HIGH|MEDIUM|LOW}
+</decision>
+
+Guidelines:
+- Emit a tag for every choice where you considered alternatives or where the "why" matters
+- Don't tag obvious/mechanical actions (reading a file, running a command)
+- HIGH = changes project direction; MEDIUM = shapes implementation; LOW = minor preference
+- Multiple tags per output are fine — one per distinct decision
+</decision_logging>
+
+<quality_gate>
+## Self-Validation (run before delivering output)
+
+Check these criteria before finalizing simplification:
+
+1. **Behavior preserved**: Tests pass after changes (ran them, not assumed)
+2. **All 3 dimensions checked**: Reported findings for reuse, quality, AND efficiency (even if "none found")
+3. **Changes justified**: Every change has a "why" (not just "cleaned up")
+4. **Metrics reported**: Lines removed/added count is concrete (not "several")
+5. **No over-abstraction**: Did NOT extract a helper for <3 usages
+
+Score: count criteria met out of 5
+- 5/5 → PASS
+- 3-4/5 → WEAK (deliver with warning)
+- 0-2/5 → FAIL (review changes, retry once)
+
+Append to output:
+```
+Quality: {PASS|WEAK|FAIL} ({N}/5 criteria met)
+```
+</quality_gate>

package/agents/sage.md

@@ -50,3 +50,49 @@ Expected: FAIL with "{expected error}"
 ### Coverage Verdict
 {ADEQUATE | GAPS FOUND | INSUFFICIENT}
 </output_format>
+
+<decision_logging>
+When you make a choice with rationale — choosing one approach over others, scoping in/out, accepting/rejecting, or recommending with trade-offs — emit a <decision> tag inline in your output:
+
+<decision>
+type: {approach|scope|architecture|verdict|deviation|tradeoff|pattern}
+summary: {one line — what was decided}
+alternatives: {what was rejected, or "none" if no alternatives considered}
+rationale: {why this choice}
+impact: {HIGH|MEDIUM|LOW}
+</decision>
+
+Guidelines:
+- Emit a tag for every choice where you considered alternatives or where the "why" matters
+- Don't tag obvious/mechanical actions (reading a file, running a command)
+- HIGH = changes project direction; MEDIUM = shapes implementation; LOW = minor preference
+- Multiple tags per output are fine — one per distinct decision
+</decision_logging>
+
+<quality_gate>
+## Self-Validation (run before delivering output)
+
+Check these criteria before finalizing your output:
+
+### TDD mode (implement):
+1. **Tests fail first**: Confirmed tests actually fail before implementation
+2. **Coverage breadth**: Covered happy path + error path + ≥1 edge case
+3. **One-thing-per-test**: Each test function tests exactly one behavior
+4. **Descriptive names**: Test names describe the scenario, not the function
+
+### Review mode:
+1. **Full scan**: Checked ALL changed files for corresponding test files
+2. **Specific gaps**: Missing tests name specific functions/scenarios, not vague areas
+3. **Severity justified**: P1 (no tests at all) vs P2 (missing paths) vs P3 (edge cases) is correct
+4. **Actionable suggestions**: Suggested tests describe concrete scenarios, not "add more tests"
+
+Score: count criteria met out of 4 (mode-specific)
+- 4/4 → PASS
+- 2-3/4 → WEAK (deliver with warning)
+- 0-1/4 → FAIL (re-analyze, retry once)
+
+Append to output:
+```
+Quality: {PASS|WEAK|FAIL} ({N}/4 criteria met) [mode: {tdd|review}]
+```
+</quality_gate>

package/agents/scout.md

@@ -47,3 +47,43 @@ Verdict: {VIABLE | VIABLE WITH CONCERNS | NOT VIABLE}
 ### Recommendations
 {Concrete recommendations for the plan phase}
 </output_format>
+
+<decision_logging>
+When you make a choice with rationale — choosing one approach over others, scoping in/out, accepting/rejecting, or recommending with trade-offs — emit a <decision> tag inline in your output:
+
+<decision>
+type: {approach|scope|architecture|verdict|deviation|tradeoff|pattern}
+summary: {one line — what was decided}
+alternatives: {what was rejected, or "none" if no alternatives considered}
+rationale: {why this choice}
+impact: {HIGH|MEDIUM|LOW}
+</decision>
+
+Guidelines:
+- Emit a tag for every choice where you considered alternatives or where the "why" matters
+- Don't tag obvious/mechanical actions (reading a file, running a command)
+- HIGH = changes project direction; MEDIUM = shapes implementation; LOW = minor preference
+- Multiple tags per output are fine — one per distinct decision
+</decision_logging>
+
+<quality_gate>
+## Self-Validation (run before delivering output)
+
+Check these criteria before finalizing your investigation:
+
+1. **External sources**: Found ≥2 external sources (docs, benchmarks, blog posts, GitHub)
+2. **Alternatives compared**: Evaluated ≥2 alternatives with concrete pros/cons (not just "it depends")
+3. **Risk specificity**: Each risk has severity AND a concrete mitigation (not "be careful")
+4. **Solutions checked**: Checked rpi/solutions/ before external research (even if empty, report that)
+5. **Project relevance**: Recommendations reference the specific project stack (not generic advice)
+
+Score: count criteria met out of 5
+- 5/5 → PASS
+- 3-4/5 → WEAK (deliver with warning)
+- 0-2/5 → FAIL (research more deeply, retry once)
+
+Append to output:
+```
+Quality: {PASS|WEAK|FAIL} ({N}/5 criteria met)
+```
+</quality_gate>

package/agents/shield.md

@@ -49,3 +49,43 @@ Communication style: threat-model framing. "An attacker could..." + "Impact:" +
 ### Verdict
 {SECURE | CONCERNS | VULNERABLE}
 </output_format>
+
+<decision_logging>
+When you make a choice with rationale — choosing one approach over others, scoping in/out, accepting/rejecting, or recommending with trade-offs — emit a <decision> tag inline in your output:
+
+<decision>
+type: {approach|scope|architecture|verdict|deviation|tradeoff|pattern}
+summary: {one line — what was decided}
+alternatives: {what was rejected, or "none" if no alternatives considered}
+rationale: {why this choice}
+impact: {HIGH|MEDIUM|LOW}
+</decision>
+
+Guidelines:
+- Emit a tag for every choice where you considered alternatives or where the "why" matters
+- Don't tag obvious/mechanical actions (reading a file, running a command)
+- HIGH = changes project direction; MEDIUM = shapes implementation; LOW = minor preference
+- Multiple tags per output are fine — one per distinct decision
+</decision_logging>
+
+<quality_gate>
+## Self-Validation (run before delivering output)
+
+Check these criteria before finalizing your audit:
+
+1. **OWASP coverage**: Checked ≥5 OWASP categories (marked each PASS/FAIL/N/A)
+2. **Secrets scanned**: Explicitly checked for hardcoded secrets, API keys, tokens
+3. **Finding specificity**: Every finding cites file:line and describes the attack vector
+4. **Risk-rated findings**: Each finding has likelihood AND impact (not just "this is bad")
+5. **Dependency check**: Checked for known CVEs in dependencies (or stated "no new dependencies")
+
+Score: count criteria met out of 5
+- 5/5 → PASS
+- 3-4/5 → WEAK (deliver with warning)
+- 0-2/5 → FAIL (audit more thoroughly, retry once)
+
+Append to output:
+```
+Quality: {PASS|WEAK|FAIL} ({N}/5 criteria met)
+```
+</quality_gate>

package/bin/cli.js

@@ -90,8 +90,24 @@ function installCodex() {
 
 function installGeminiCLI() {
   log("Installing RPIKit for Gemini CLI...");
-  log("Gemini CLI: coming soon. Please see documentation for manual setup.");
-  return true;
+  if (!hasGeminiCLI()) {
+    log("Gemini CLI not found. Skipping.");
+    return false;
+  }
+
+  try {
+    // PLUGIN_DIR is the root of the npm package
+    execFileSync("gemini", ["extensions", "link", PLUGIN_DIR], {
+      stdio: silent ? "pipe" : "inherit",
+    });
+    log("Gemini CLI: extension linked.");
+    return true;
+  } catch (e) {
+    log("Gemini CLI: could not link extension.");
+    log("  Manual link:");
+    log(`    gemini extensions link ${PLUGIN_DIR}`);
+    return false;
+  }
 }
 
 function findInstalledPlugin() {
@@ -137,26 +153,51 @@ function findInstalledPlugin() {
 }
 
 function updatePlugin() {
-  const result = findInstalledPlugin();
-  if (!result) {
-    log("RPIKit installation not found in ~/.claude/plugins/.");
-    log("Install first: claude plugin install rpi-kit");
-    return false;
+  log("Updating RPIKit for all detected tools...\n");
+
+  let updated = false;
+
+  // 1. Claude Code
+  if (hasClaude()) {
+    log("── Claude Code ──");
+    const result = findInstalledPlugin();
+    if (result) {
+      const { dir: pluginDir, type: installType } = result;
+      let currentVersion = "unknown";
+      try {
+        const pj = JSON.parse(fs.readFileSync(path.join(pluginDir, ".claude-plugin", "plugin.json"), "utf8"));
+        currentVersion = pj.version || "unknown";
+      } catch {}
+      if (installType === "npm") {
+        updated = updateNpmPlugin(pluginDir, currentVersion) || updated;
+      } else {
+        updated = updateGitPlugin(pluginDir, currentVersion) || updated;
+      }
+    } else {
+      log("Not installed. Run: rpi-kit install --claude");
+    }
+    log("");
   }
 
-  const { dir: pluginDir, type: installType } = result;
+  // 2. Codex
+  if (hasCodex()) {
+    log("── Codex ──");
+    updated = installCodex() || updated;
+    log("");
+  }
 
-  // Current version
-  let currentVersion = "unknown";
-  try {
-    const pj = JSON.parse(fs.readFileSync(path.join(pluginDir, ".claude-plugin", "plugin.json"), "utf8"));
-    currentVersion = pj.version || "unknown";
-  } catch {}
+  // 3. Gemini CLI
+  if (hasGeminiCLI()) {
+    log("── Gemini CLI ──");
+    updated = installGeminiCLI() || updated;
+    log("");
+  }
 
-  if (installType === "npm") {
-    return updateNpmPlugin(pluginDir, currentVersion);
+  if (!updated) {
+    log("No tools detected. Install first: rpi-kit install");
   }
-  return updateGitPlugin(pluginDir, currentVersion);
+
+  return updated;
 }
 
 function updateNpmPlugin(pluginDir, currentVersion) {
@@ -295,8 +336,9 @@ Usage:
   rpi-kit onboarding         Interactive walkthrough of the workflow
   rpi-kit help               Show this help
 
-Commands (17):
+Commands (18):
   /rpi:new <feature>         Describe your feature → REQUEST.md
+  /rpi:fix <bug>             Quick bugfix — interview, plan, implement in one step
   /rpi:research <feature>    Parallel agent analysis → RESEARCH.md
   /rpi:plan <feature>        Generate specs + tasks → PLAN.md
   /rpi:implement <feature>   Execute tasks with tracking → IMPLEMENT.md

package/commands/rpi/docs.md

@@ -109,6 +109,15 @@ Rules:
 - Match existing documentation style and tone
 - Use concrete examples, not abstract descriptions
 - If the code says WHAT, the docs should say WHY
+
+After documentation updates, append your activity to rpi/features/{slug}/ACTIVITY.md:
+
+### {current_date} — Quill (Docs)
+- **Action:** Documentation updates for {slug}
+- **Key decisions:** {for each <decision> tag you emitted: "summary (rationale)", separated by semicolons. If none: "No decisions in this phase."}
+- **Files updated:** {list}
+- **Changelog entry:** {yes|no}
+- **Quality:** {your quality gate result}
 ```
 
 Store the output as `$QUILL_OUTPUT`.
@@ -124,7 +133,26 @@ Store the output as `$QUILL_OUTPUT`.
    git commit -m "docs({slug}): update documentation for {slug}"
    ```
 
-## Step 6: Output summary
+## Step 6: Consolidate decisions to DECISIONS.md
+
+1. Read `rpi/features/{slug}/ACTIVITY.md`.
+2. Extract all `<decision>` tags from entries belonging to the Docs phase (Quill entries from this run).
+3. If no decisions found, skip this step.
+4. Read `rpi/features/{slug}/DECISIONS.md` if it exists (to get the last decision number for sequential numbering).
+5. Append a new section to `rpi/features/{slug}/DECISIONS.md`:
+
+```markdown
+## Docs Phase
+_Generated: {current_date}_
+
+| # | Type | Decision | Alternatives | Rationale | Impact |
+|---|------|----------|-------------|-----------|--------|
+| {N} | {type} | {summary} | {alternatives} | {rationale} | {impact} |
+```
+
+6. Number decisions sequentially, continuing from the last number in DECISIONS.md.
+
+## Step 7: Output summary
 
 ```
 Documentation complete: {slug}