@nst173/superpowers-ccg 1.3.0

package/skills/receiving-code-review/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: receiving-code-review
+description: "Evaluates code review feedback with technical rigor before implementing suggestions. Use when: receiving review feedback, especially if unclear or technically questionable. Keywords: review feedback, code review response, technical evaluation"
+---
+
+# Code Review Reception
+
+## Contents
+- [Overview](#overview)
+- [The Response Pattern](#the-response-pattern)
+- [Forbidden Responses](#forbidden-responses)
+- [Handling Unclear Feedback](#handling-unclear-feedback)
+- [Technical Evaluation](#technical-evaluation)
+- [Implementation Process](#implementation-process)
+
+## Overview
+
+Code review requires technical evaluation, not emotional performance.
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## The Response Pattern
+
+```
+WHEN receiving code review feedback:
+
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement in own words (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One item at a time, test each
+```
+
+## Forbidden Responses
+
+**NEVER:**
+- "You're absolutely right!" (explicit CLAUDE.md violation)
+- "Great point!" / "Excellent feedback!" (performative)
+- "Let me implement that now" (before verification)
+
+**INSTEAD:**
+- Restate the technical requirement
+- Ask clarifying questions
+- Push back with technical reasoning if wrong
+- Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item is unclear:
+  STOP - do not implement anything yet
+  ASK for clarification on unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+**Example:**
+```
+your human partner: "Fix 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+
+❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
+✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
+```
+
+## Source-Specific Handling
+
+### From your human partner
+- **Trusted** - implement after understanding
+- **Still ask** if scope unclear
+- **No performative agreement**
+- **Skip to action** or technical acknowledgment
+
+### From External Reviewers
+```
+BEFORE implementing:
+  1. Check: Technically correct for THIS codebase?
+  2. Check: Breaks existing functionality?
+  3. Check: Reason for current implementation?
+  4. Check: Works on all platforms/versions?
+  5. Check: Does reviewer understand full context?
+
+IF suggestion seems wrong:
+  Push back with technical reasoning
+
+IF can't easily verify:
+  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+
+IF conflicts with your human partner's prior decisions:
+  Stop and discuss with your human partner first
+```
+
+**your human partner's rule:** "External feedback - be skeptical, but check carefully"
+
+## YAGNI Check for "Professional" Features
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+
+  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
+  IF used: Then implement properly
+```
+
+**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
+
+## Implementation Order
+
+```
+FOR multi-item feedback:
+  1. Clarify anything unclear FIRST
+  2. Then implement in this order:
+     - Blocking issues (breaks, security)
+     - Simple fixes (typos, imports)
+     - Complex fixes (refactoring, logic)
+  3. Test each fix individually
+  4. Verify no regressions
+```
+
+## When To Push Back
+
+Push back when:
+- Suggestion breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for this stack
+- Legacy/compatibility reasons exist
+- Conflicts with your human partner's architectural decisions
+
+**How to push back:**
+- Use technical reasoning, not defensiveness
+- Ask specific questions
+- Reference working tests/code
+- Involve your human partner if architectural
+
+**Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K"
+
+## Acknowledging Correct Feedback
+
+When feedback IS correct:
+```
+✅ "Fixed. [Brief description of what changed]"
+✅ "Good catch - [specific issue]. Fixed in [location]."
+✅ [Just fix it and show in the code]
+
+❌ "You're absolutely right!"
+❌ "Great point!"
+❌ "Thanks for catching that!"
+❌ "Thanks for [anything]"
+❌ ANY gratitude expression
+```
+
+**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
+
+**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
+
+## Gracefully Correcting Your Pushback
+
+If you pushed back and were wrong:
+```
+✅ "You were right - I checked [X] and it does [Y]. Implementing now."
+✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
+
+❌ Long apology
+❌ Defending why you pushed back
+❌ Over-explaining
+```
+
+State the correction factually and move on.
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Performative agreement | State requirement or just act |
+| Blind implementation | Verify against codebase first |
+| Batch without testing | One at a time, test each |
+| Assuming reviewer is right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+| Partial implementation | Clarify all items first |
+| Can't verify, proceed anyway | State limitation, ask for direction |
+
+## Real Examples
+
+**Performative Agreement (Bad):**
+```
+Reviewer: "Remove legacy code"
+❌ "You're absolutely right! Let me remove that..."
+```
+
+**Technical Verification (Good):**
+```
+Reviewer: "Remove legacy code"
+✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
+```
+
+**YAGNI (Good):**
+```
+Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
+✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
+```
+
+**Unclear Item (Good):**
+```
+your human partner: "Fix items 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
+```
+
+## GitHub Thread Replies
+
+When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.
+
+## The Bottom Line
+
+**External feedback = suggestions to evaluate, not orders to follow.**
+
+Verify. Question. Then implement.
+
+No performative agreement. Technical rigor always.

package/skills/requesting-code-review/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: requesting-code-review
+description: "Dispatches code-reviewer subagent to catch issues before they cascade. Use when: completing tasks, implementing major features, before merging, or verifying work meets requirements. Keywords: code review, review request, quality check, PR review"
+---
+
+# Requesting Code Review
+
+Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.
+
+**Core principle:** Review early, review often.
+
+## Protocol Threshold (Required)
+
+Follow `skills/shared/protocol-threshold.md`. The hook injects CP reminders automatically.
+
+## When to Request Review
+
+**Mandatory:**
+
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**► CP3 (Quality Gate):** Before requesting review, apply `coordinating-multi-model-work/checkpoints.md`.
+
+**1. Get git SHAs:**
+
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Dispatch code-reviewer subagent:**
+
+Use Task tool with superpowers:code-reviewer type, fill template at `code-reviewer.md`
+
+**Note:** Code review is handled by the Opus reviewer agent directly. Opus reviews all code-changing paths.
+
+**Placeholders:**
+
+- `{WHAT_WAS_IMPLEMENTED}` - What you just built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+- `{DESCRIPTION}` - Brief summary
+
+**3. Act on feedback:**
+
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch superpowers:code-reviewer subagent]
+  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Workflows
+
+**Subagent-Driven Development:**
+
+- Review after EACH task
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Executing Plans:**
+
+- Review after each batch (3 tasks)
+- Get feedback, apply, continue
+
+**Ad-Hoc Development:**
+
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: requesting-code-review/code-reviewer.md
+
+## Multi-Model Code Review
+
+See `skills/shared/multi-model-integration-section.md` for routing, invocation, and fallback rules.

package/skills/requesting-code-review/code-reviewer.md

@@ -0,0 +1,146 @@
+# Code Review Agent
+
+You are reviewing code changes for production readiness.
+
+**Your task:**
+1. Review {WHAT_WAS_IMPLEMENTED}
+2. Compare against {PLAN_OR_REQUIREMENTS}
+3. Check code quality, architecture, testing
+4. Categorize issues by severity
+5. Assess production readiness
+
+## What Was Implemented
+
+{DESCRIPTION}
+
+## Requirements/Plan
+
+{PLAN_REFERENCE}
+
+## Git Range to Review
+
+**Base:** {BASE_SHA}
+**Head:** {HEAD_SHA}
+
+```bash
+git diff --stat {BASE_SHA}..{HEAD_SHA}
+git diff {BASE_SHA}..{HEAD_SHA}
+```
+
+## Review Checklist
+
+**Code Quality:**
+- Clean separation of concerns?
+- Proper error handling?
+- Type safety (if applicable)?
+- DRY principle followed?
+- Edge cases handled?
+
+**Architecture:**
+- Sound design decisions?
+- Scalability considerations?
+- Performance implications?
+- Security concerns?
+
+**Testing:**
+- Tests actually test logic (not mocks)?
+- Edge cases covered?
+- Integration tests where needed?
+- All tests passing?
+
+**Requirements:**
+- All plan requirements met?
+- Implementation matches spec?
+- No scope creep?
+- Breaking changes documented?
+
+**Production Readiness:**
+- Migration strategy (if schema changes)?
+- Backward compatibility considered?
+- Documentation complete?
+- No obvious bugs?
+
+## Output Format
+
+### Strengths
+[What's well done? Be specific.]
+
+### Issues
+
+#### Critical (Must Fix)
+[Bugs, security issues, data loss risks, broken functionality]
+
+#### Important (Should Fix)
+[Architecture problems, missing features, poor error handling, test gaps]
+
+#### Minor (Nice to Have)
+[Code style, optimization opportunities, documentation improvements]
+
+**For each issue:**
+- File:line reference
+- What's wrong
+- Why it matters
+- How to fix (if not obvious)
+
+### Recommendations
+[Improvements for code quality, architecture, or process]
+
+### Assessment
+
+**Ready to merge?** [Yes/No/With fixes]
+
+**Reasoning:** [Technical assessment in 1-2 sentences]
+
+## Critical Rules
+
+**DO:**
+- Categorize by actual severity (not everything is Critical)
+- Be specific (file:line, not vague)
+- Explain WHY issues matter
+- Acknowledge strengths
+- Give clear verdict
+
+**DON'T:**
+- Say "looks good" without checking
+- Mark nitpicks as Critical
+- Give feedback on code you didn't review
+- Be vague ("improve error handling")
+- Avoid giving a clear verdict
+
+## Example Output
+
+```
+### Strengths
+- Clean database schema with proper migrations (db.ts:15-42)
+- Comprehensive test coverage (18 tests, all edge cases)
+- Good error handling with fallbacks (summarizer.ts:85-92)
+
+### Issues
+
+#### Important
+1. **Missing help text in CLI wrapper**
+   - File: index-conversations:1-31
+   - Issue: No --help flag, users won't discover --concurrency
+   - Fix: Add --help case with usage examples
+
+2. **Date validation missing**
+   - File: search.ts:25-27
+   - Issue: Invalid dates silently return no results
+   - Fix: Validate ISO format, throw error with example
+
+#### Minor
+1. **Progress indicators**
+   - File: indexer.ts:130
+   - Issue: No "X of Y" counter for long operations
+   - Impact: Users don't know how long to wait
+
+### Recommendations
+- Add progress reporting for user experience
+- Consider config file for excluded projects (portability)
+
+### Assessment
+
+**Ready to merge: With fixes**
+
+**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
+```

package/skills/shared/multi-model-integration-section.md

@@ -0,0 +1,32 @@
+# Multi-Model Integration (Shared Reference)
+
+All skills that invoke external models must follow this pattern.
+
+**Related skill:** `superpowers-ccg:coordinating-multi-model-work`
+
+## Integration Steps
+
+1. Analyze the task domain using `coordinating-multi-model-work/routing-decision.md`.
+2. Reduce scope to one bounded task with a clear file set and verification command.
+3. Invoke exactly one worker for implementation:
+   - Backend and systems → `mcp__codex__codex`
+   - Frontend → `mcp__gemini__gemini`
+4. Reuse the same worker `SESSION_ID` for follow-up fixes on that task only.
+5. Use `CROSS_VALIDATION` only for architectural uncertainty or true multi-domain conflicts.
+6. Run the Opus review chain on the resulting artifact.
+
+## Invocation
+
+- Use English prompts.
+- Ask for `diff-or-questions`, not prose design output.
+- Do not ask the worker for draft code that the orchestrator will re-implement.
+
+## Checkpoint Integration
+
+- CP1: route the current bounded task
+- CP2: narrow scope before escalating to cross-validation
+- CP3: review the artifact, not the whole narrative
+
+## Fallback
+
+If `Routing != CLAUDE` and the MCP call fails or times out, stop and follow `coordinating-multi-model-work/GATE.md`.

package/skills/shared/protocol-threshold.md

@@ -0,0 +1,46 @@
+# Protocol Threshold (Shared Reference)
+
+All skills that use checkpoints must follow the CP protocol injected by hooks.
+
+## Required Behavior
+
+- Before the first Task call, output a standalone `[CP1 Assessment]` block.
+- Before claiming completion or verification, output a standalone `[CP3 Assessment]` block.
+- Keep both blocks minimal. The checkpoint is a gate, not a summary.
+
+## CP1 Assessment Format
+
+```text
+[CP1 Assessment]
+- Task type: [Frontend/Backend/Full-stack/Other]
+- Complexity: [Trivial/Standard/Critical]
+- Routing decision: [CLAUDE/CODEX/GEMINI/CROSS_VALIDATION]
+- Rationale: [one sentence]
+```
+
+Compact trivial form:
+
+```text
+[CP1] Routing: CLAUDE | Trivial: <reason>
+```
+
+## CP3 Assessment Format
+
+```text
+[CP3 Assessment]
+- Task type: [Frontend/Backend/Full-stack/Other]
+- Routing decision: [CLAUDE/CODEX/GEMINI/CROSS_VALIDATION]
+- Rationale: [one sentence]
+```
+
+Compact trivial form:
+
+```text
+[CP3] Verified: <evidence>
+```
+
+## Checkpoint Logic
+
+- **CP1:** decide routing and invoke the worker if needed
+- **CP2:** trigger only on real uncertainty, stalled progress, or repeated failures
+- **CP3:** verify the artifact and run the review chain

package/skills/shared/supplementary-tools.md

@@ -0,0 +1,132 @@
+# Supplementary MCP Tools (Optional Enhancements)
+
+Supplementary tools enhance Claude's orchestration capabilities. They are **optional** — all workflows work without them via native tool fallbacks. They do NOT replace the primary routing to Codex/Gemini.
+
+**Design principle:** MCPs enhance performance, never block functionality. If unavailable, proceed with native tools.
+
+## Tool Reference
+
+### Grok Search / Tavily (`mcp__grok-search__web_search`, `mcp__grok-search__web_fetch`, `mcp__grok-search__web_map`)
+
+**Purpose:** Web search and real-time information retrieval (Grok Search wraps Tavily).
+
+**Tools:**
+- `mcp__grok-search__web_search` — deep web search with Tavily-powered results
+- `mcp__grok-search__web_fetch` — fetch and extract full page content as Markdown
+- `mcp__grok-search__web_map` — map website structure by graph traversal
+- `mcp__grok-search__get_sources` — retrieve source list for a search session
+
+**Use when:**
+- Research phase in brainstorming (current events, competitive analysis)
+- Debugging: searching for known issues, error messages, library bugs
+- Plan writing: gathering context about unfamiliar libraries/APIs
+- Any task needing information beyond model knowledge cutoff
+
+**Auto-triggers:** "search", "latest", "current trends", "find error solution", unknown error messages
+
+**Fallback:** Built-in WebSearch / WebFetch (less structured)
+
+---
+
+### Sequential-Thinking (`mcp__mcp-sequentialthinking-tools__sequentialthinking_tools`)
+
+**Purpose:** Multi-step structured reasoning for complex analysis.
+
+**Use when:**
+- Debugging spans 3+ components or layers
+- Architectural analysis or system design decisions
+- Cross-validation arbitration (divergent model outputs)
+- Complex plan decomposition with interdependencies
+- Hypothesis testing with multiple variables
+
+**Auto-triggers:** "design", "architecture", "analyze tradeoffs", "complex problem", 3+ interacting parts
+
+**Fallback:** Native reasoning (same quality, ~2x more tokens)
+
+---
+
+### Serena (`mcp__serena__*`)
+
+**Purpose:** Semantic code understanding with project memory.
+
+**Use when:**
+- Symbol-aware navigation (find references, trace dependencies)
+- Large codebase exploration (>10 files involved)
+- Cross-session project memory and persistence
+- Refactoring with dependency tracking
+
+**Auto-triggers:** "refactor", "find all usages", "symbol tracking", file count >10
+
+**Fallback:** Grep + Read + Glob (3x slower, same quality)
+
+---
+
+### Magic (`mcp__magic__*`)
+
+**Purpose:** Modern UI component generation from 21st.dev patterns.
+
+**Use when:**
+- Generating frontend UI components (forms, navbars, modals, tables, cards)
+- Design system integration with accessibility and responsiveness
+- Complements Gemini MCP for frontend routing — use Magic for component patterns, Gemini for full-page layouts and styling
+
+**Auto-triggers:** UI component requests, "button", "form", "modal", "card", "table"
+
+**Fallback:** Gemini MCP handles all frontend work (Magic adds design-system patterns)
+
+---
+
+### Morphllm Fast-Apply (`mcp__morph-mcp__*`)
+
+**Purpose:** Pattern-based bulk code editing with token efficiency.
+
+**Use when:**
+- Repeated edits across multiple files (style migration, framework updates)
+- Pattern-driven transformations (rename patterns, enforce conventions)
+- Bulk refactoring where semantic context is less important than pattern matching
+- Token-efficient editing during plan execution
+
+**Auto-triggers:** Multi-file pattern edits, framework migrations, style enforcement
+
+**Fallback:** Edit tool (more manual, same result)
+
+## Composition Patterns
+
+### Research Phase (Brainstorming)
+```
+Grok Search (gather info) → Sequential (analyze & decompose) → Design output
+```
+
+### Complex Debugging
+```
+Sequential (decompose problem) → Grok Search (search known issues) → Serena (trace symbols) → Fix
+```
+
+### Plan Writing
+```
+Sequential (architectural decomposition) → Grok Search (library docs) → Plan output
+```
+
+### Frontend Implementation
+```
+Magic (component patterns) + Gemini MCP (full implementation) → Opus review
+```
+
+### Bulk Refactoring
+```
+Serena (scope & analyze) → Morphllm (execute bulk edits) → Opus review
+```
+
+## Integration with Primary Routing
+
+Supplementary tools operate at the **orchestrator level** — Claude uses them to enhance its own analysis before/alongside routing to Codex/Gemini.
+
+```
+1. Claude receives task
+2. [Optional] Use supplementary tools for research/analysis/planning
+3. Route implementation to Codex/Gemini (primary routing)
+4. [Optional] Use supplementary tools during review/integration
+5. Opus reviews
+```
+
+**No fail-closed gate** for supplementary tools. If unavailable, proceed without them.