nitm-ai-dev-toolkit 3.0.15

package/src/monorepo/.agents/skills/requesting-code-review/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: requesting-code-review
+description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
+---
+
+# Requesting Code Review
+
+Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.
+
+**Core principle:** Review early, review often.
+
+## 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
+
+**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`
+
+**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 apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-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

package/src/monorepo/.agents/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/src/monorepo/.agents/skills/security-reviewer/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: security-reviewer
+description: Use for security-focused code audits on auth, payments, user data, API endpoints, or file uploads. Performs OWASP Top 10 checklist review. Dispatch as a fresh subagent with no shared context to avoid anchoring bias.
+---
+
+# Security Reviewer
+
+Security-focused code audit using OWASP Top 10 checklist.
+
+**Purpose:** Find security vulnerabilities before they reach production — think like an attacker.
+
+**When to use:**
+- Security-sensitive code changes (auth, payments, user data, API endpoints, file uploads)
+- As part of comprehensive code review
+- Before merging security-critical features
+
+**CRITICAL:** Dispatch as a fresh subagent with NO shared conversation context. Shared context creates anchoring bias and causes reviewers to rubber-stamp work they watched being built.
+
+## Dispatch Template
+
+```
+You are a Staff Security Engineer performing a security-focused code audit.
+Your job is to find vulnerabilities before they reach production. Think like
+an attacker — what can be exploited?
+
+## What Was Changed
+
+[Summary of what was implemented — endpoints, models, auth changes, etc.]
+
+## Files to Review
+
+[List all changed files, especially controllers, models, services, middleware, config]
+
+## Git Context
+
+- Base SHA: [commit before changes]
+- Head SHA: [current commit]
+
+Run `git diff {Base SHA}..{Head SHA}` to view all changes before beginning the audit.
+```
+
+## Security Audit Checklist
+
+### Injection (CRITICAL)
+
+- [ ] **SQL injection**: String concatenation in queries? Unparameterized inputs?
+      Check for `.where("column = '#{value}'")`, `Arel.sql()` with user input,
+      `.whereRaw()`, `.raw()`, template literals in SQL strings.
+- [ ] **Command injection**: `system()`, `exec()`, backticks with user input?
+      Unsanitized arguments to shell commands?
+- [ ] **XSS**: Unescaped user input in HTML/templates? `html_safe` on user content?
+      `innerHTML`, `dangerouslySetInnerHTML` with user data?
+- [ ] **NoSQL injection**: Unvalidated query operators in MongoDB/similar?
+- [ ] **Header injection**: User input in HTTP headers without sanitization?
+
+### Broken Authentication & Authorization (CRITICAL)
+
+- [ ] **Missing authentication**: Are new endpoints protected by auth middleware?
+- [ ] **Missing authorization**: Do actions check that the current user is allowed?
+- [ ] **IDOR**: Can users access other users' resources by changing IDs in URLs/params?
+      Are queries scoped: `current_user.resources.find(params[:id])` vs `Resource.find(params[:id])`?
+- [ ] **Privilege escalation**: Can regular users access admin-only actions?
+      Are role checks enforced server-side (not just UI)?
+- [ ] **Session management**: Secure token generation? Proper expiration? HttpOnly cookies?
+
+### Sensitive Data Exposure (CRITICAL)
+
+- [ ] **Secrets in code**: API keys, passwords, tokens hardcoded? Check for Base64-encoded secrets.
+- [ ] **Secrets in logs**: PII, credentials, tokens logged? Check logger, console.log statements.
+- [ ] **Sensitive API responses**: Password hashes, internal IDs, admin flags, other users' PII
+      in API responses? Check serializers for overexposure.
+- [ ] **Missing encryption**: Sensitive data stored/transmitted without encryption?
+- [ ] **CORS**: Overly permissive `Access-Control-Allow-Origin: *`?
+
+### Input Validation (IMPORTANT)
+
+- [ ] **Missing validation**: Are controller params validated before use? Strong parameters?
+- [ ] **Type coercion**: Could type confusion bypass checks?
+- [ ] **File uploads**: Type validation? Size limits? Content sniffing protection?
+      Filename sanitization?
+- [ ] **ReDoS**: Complex regex patterns on user input that could cause catastrophic backtracking?
+- [ ] **Mass assignment**: `permit!` or overly broad `params.permit(...)` allowing
+      role/admin/internal fields to be set by users?
+
+### Security Misconfiguration (IMPORTANT)
+
+- [ ] **Debug/verbose errors**: Stack traces or internal details exposed in error responses?
+- [ ] **Default credentials**: Default passwords, API keys, or configurations?
+- [ ] **Missing security headers**: CSP, X-Frame-Options, X-Content-Type-Options?
+- [ ] **Dependency vulnerabilities**: Known CVEs in added/updated dependencies?
+
+### SSRF — Server-Side Request Forgery (IMPORTANT)
+
+- [ ] **User-controlled URLs**: Are user-supplied URLs passed to HTTP clients?
+- [ ] **Domain allowlist**: Are outbound HTTP requests restricted to a known-safe list of domains?
+- [ ] **Internal metadata**: Could a user trigger requests to internal metadata endpoints
+      (AWS `169.254.169.254`, GCP metadata server)?
+
+### Cryptographic Failures (IMPORTANT)
+
+- [ ] **Weak hash algorithms**: MD5 or SHA1 used for security-sensitive data?
+      Should use bcrypt/argon2 for passwords, SHA-256+ for tokens.
+- [ ] **Hardcoded secrets**: Encryption keys, salts, IVs, or API tokens hardcoded in source?
+- [ ] **`.env` committed**: Secret ENV files committed to version control?
+- [ ] **JWT payload exposure**: Sensitive data in JWT payload without encryption (signed ≠ encrypted)?
+
+### Logging & Monitoring (MINOR)
+
+- [ ] **Missing security event logs**: Failed auth attempts, permission denials, input validation
+      failures — are they logged for monitoring?
+- [ ] **Missing audit trail**: Sensitive operations (delete, role change, data export) — is there
+      an audit log?
+- [ ] **Error message leakage**: Do error messages reveal internal structure, file paths,
+      database schema, or stack traces?
+
+## Report Format
+
+For each finding, report:
+
+**[CRITICAL/IMPORTANT/MINOR] — [Category] — [Short description]**
+- File: `path/to/file:line_number`
+- Problem: [What's wrong — describe the attack vector clearly]
+- Recommendation: [Specific remediation with code snippet]
+- Impact: [What an attacker could do — data breach, privilege escalation, RCE, etc.]
+- CWE: [CWE ID, e.g., CWE-89 (SQL Injection), CWE-79 (XSS), CWE-862 (Missing Authorization)]
+
+## Assessment
+
+- **CRITICAL findings MUST be fixed before merge.** No exceptions.
+- **IMPORTANT findings MUST be fixed before merge.** No exceptions.
+- **MINOR findings** are noted but do not block merge.
+
+Final verdict:
+- **APPROVED**: No critical or important security findings
+- **CHANGES REQUIRED**: Critical or important security findings that must be fixed before merge
+
+## Review Loop
+
+1. **Critical findings:** Author MUST fix, re-run tests, then re-request security review
+2. **Important findings:** Author MUST fix, re-run tests, then re-request security review
+3. **Minor findings:** Note in review but do not block
+4. **Max 3 review cycles.** If critical or important findings persist after 3 cycles, escalate to user.
+
+After fixes, dispatch another security review to verify critical and important findings are resolved.

package/src/monorepo/.agents/skills/subagent-driven-development/SKILL.md

@@ -0,0 +1,279 @@
+---
+name: subagent-driven-development
+description: Use when executing implementation plans with independent tasks in the current session
+---
+
+# Subagent-Driven Development
+
+Execute plan by dispatching fresh subagent per task, with two-stage review after each: spec compliance review first, then code quality review.
+
+**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration
+
+## When to Use
+
+```dot
+digraph when_to_use {
+    "Have implementation plan?" [shape=diamond];
+    "Tasks mostly independent?" [shape=diamond];
+    "Stay in this session?" [shape=diamond];
+    "subagent-driven-development" [shape=box];
+    "executing-plans" [shape=box];
+    "Manual execution or brainstorm first" [shape=box];
+
+    "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
+    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
+    "Tasks mostly independent?" -> "Stay in this session?" [label="yes"];
+    "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
+    "Stay in this session?" -> "subagent-driven-development" [label="yes"];
+    "Stay in this session?" -> "executing-plans" [label="no - parallel session"];
+}
+```
+
+**vs. Executing Plans (parallel session):**
+
+- Same session (no context switch)
+- Fresh subagent per task (no context pollution)
+- Two-stage review after each task: spec compliance first, then code quality
+- Faster iteration (no human-in-loop between tasks)
+
+## The Process
+
+```dot
+digraph process {
+    rankdir=TB;
+
+    subgraph cluster_per_task {
+        label="Per Task";
+        "Dispatch implementer subagent (./implementer-prompt.md)" [shape=box];
+        "Implementer subagent asks questions?" [shape=diamond];
+        "Answer questions, provide context" [shape=box];
+        "Implementer subagent implements, tests, commits, self-reviews" [shape=box];
+        "Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)" [shape=box];
+        "Spec reviewer subagent confirms code matches spec?" [shape=diamond];
+        "Implementer subagent fixes spec gaps" [shape=box];
+        "Dispatch code quality reviewer subagent (./code-quality-reviewer-prompt.md)" [shape=box];
+        "Code quality reviewer subagent approves?" [shape=diamond];
+        "Implementer subagent fixes quality issues" [shape=box];
+        "Mark task complete in TodoWrite" [shape=box];
+    }
+
+    "Read plan, extract all tasks with full text, note context, create TodoWrite" [shape=box];
+    "More tasks remain?" [shape=diamond];
+    "Dispatch final code reviewer subagent for entire implementation" [shape=box];
+    "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
+
+    "Read plan, extract all tasks with full text, note context, create TodoWrite" -> "Dispatch implementer subagent (./implementer-prompt.md)";
+    "Dispatch implementer subagent (./implementer-prompt.md)" -> "Implementer subagent asks questions?";
+    "Implementer subagent asks questions?" -> "Answer questions, provide context" [label="yes"];
+    "Answer questions, provide context" -> "Dispatch implementer subagent (./implementer-prompt.md)";
+    "Implementer subagent asks questions?" -> "Implementer subagent implements, tests, commits, self-reviews" [label="no"];
+    "Implementer subagent implements, tests, commits, self-reviews" -> "Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)";
+    "Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)" -> "Spec reviewer subagent confirms code matches spec?";
+    "Spec reviewer subagent confirms code matches spec?" -> "Implementer subagent fixes spec gaps" [label="no"];
+    "Implementer subagent fixes spec gaps" -> "Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)" [label="re-review"];
+    "Spec reviewer subagent confirms code matches spec?" -> "Dispatch code quality reviewer subagent (./code-quality-reviewer-prompt.md)" [label="yes"];
+    "Dispatch code quality reviewer subagent (./code-quality-reviewer-prompt.md)" -> "Code quality reviewer subagent approves?";
+    "Code quality reviewer subagent approves?" -> "Implementer subagent fixes quality issues" [label="no"];
+    "Implementer subagent fixes quality issues" -> "Dispatch code quality reviewer subagent (./code-quality-reviewer-prompt.md)" [label="re-review"];
+    "Code quality reviewer subagent approves?" -> "Mark task complete in TodoWrite" [label="yes"];
+    "Mark task complete in TodoWrite" -> "More tasks remain?";
+    "More tasks remain?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="yes"];
+    "More tasks remain?" -> "Dispatch final code reviewer subagent for entire implementation" [label="no"];
+    "Dispatch final code reviewer subagent for entire implementation" -> "Use superpowers:finishing-a-development-branch";
+}
+```
+
+## Prompt Templates
+
+- `./implementer-prompt.md` - Dispatch implementer subagent
+- `./spec-reviewer-prompt.md` - Dispatch spec compliance reviewer subagent
+- `./code-quality-reviewer-prompt.md` - Dispatch code quality reviewer subagent
+
+## Example Workflow
+
+```
+You: I'm using Subagent-Driven Development to execute this plan.
+
+[Read plan file once: apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/plan.md]
+[Extract all 5 tasks with full text and context]
+[Create TodoWrite with all tasks]
+
+Task 1: Hook installation script
+
+[Get Task 1 text and context (already extracted)]
+[Dispatch implementation subagent with full task text + context]
+
+Implementer: "Before I begin - should the hook be installed at user or system level?"
+
+You: "User level (~/.config/superpowers/hooks/)"
+
+Implementer: "Got it. Implementing now..."
+[Later] Implementer:
+  - Implemented install-hook command
+  - Added tests, 5/5 passing
+  - Self-review: Found I missed --force flag, added it
+  - Committed
+
+[Dispatch spec compliance reviewer]
+Spec reviewer: ✅ Spec compliant - all requirements met, nothing extra
+
+[Get git SHAs, dispatch code quality reviewer]
+Code reviewer: Strengths: Good test coverage, clean. Issues: None. Approved.
+
+[Mark Task 1 complete]
+
+Task 2: Recovery modes
+
+[Get Task 2 text and context (already extracted)]
+[Dispatch implementation subagent with full task text + context]
+
+Implementer: [No questions, proceeds]
+Implementer:
+  - Added verify/repair modes
+  - 8/8 tests passing
+  - Self-review: All good
+  - Committed
+
+[Dispatch spec compliance reviewer]
+Spec reviewer: ❌ Issues:
+  - Missing: Progress reporting (spec says "report every 100 items")
+  - Extra: Added --json flag (not requested)
+
+[Implementer fixes issues]
+Implementer: Removed --json flag, added progress reporting
+
+[Spec reviewer reviews again]
+Spec reviewer: ✅ Spec compliant now
+
+[Dispatch code quality reviewer]
+Code reviewer: Strengths: Solid. Issues (Important): Magic number (100)
+
+[Implementer fixes]
+Implementer: Extracted PROGRESS_INTERVAL constant
+
+[Code reviewer reviews again]
+Code reviewer: ✅ Approved
+
+[Mark Task 2 complete]
+
+...
+
+[After all tasks]
+[Dispatch final code-reviewer]
+Final reviewer: All requirements met, ready to merge
+
+Done!
+```
+
+## Advantages
+
+**vs. Manual execution:**
+
+- Subagents follow TDD naturally
+- Fresh context per task (no confusion)
+- Parallel-safe (subagents don't interfere)
+- Subagent can ask questions (before AND during work)
+
+**vs. Executing Plans:**
+
+- Same session (no handoff)
+- Continuous progress (no waiting)
+- Review checkpoints automatic
+
+**Efficiency gains:**
+
+- No file reading overhead (controller provides full text)
+- Controller curates exactly what context is needed
+- Subagent gets complete information upfront
+- Questions surfaced before work begins (not after)
+
+**Quality gates:**
+
+- Self-review catches issues before handoff
+- Two-stage review: spec compliance, then code quality
+- Review loops ensure fixes actually work
+- Spec compliance prevents over/under-building
+- Code quality ensures implementation is well-built
+
+**Cost:**
+
+- More subagent invocations (implementer + 2 reviewers per task)
+- Controller does more prep work (extracting all tasks upfront)
+- Review loops add iterations
+- But catches issues early (cheaper than debugging later)
+
+## Red Flags
+
+**Never:**
+
+- Skip reviews (spec compliance OR code quality)
+- Proceed with unfixed issues
+- Dispatch multiple implementation subagents in parallel (conflicts)
+- Make subagent read plan file (provide full text instead)
+- Skip scene-setting context (subagent needs to understand where task fits)
+- Ignore subagent questions (answer before letting them proceed)
+- Accept "close enough" on spec compliance (spec reviewer found issues = not done)
+- Skip review loops (reviewer found issues = implementer fixes = review again)
+- Let implementer self-review replace actual review (both are needed)
+- **Start code quality review before spec compliance is ✅** (wrong order)
+- Move to next task while either review has open issues
+
+**If subagent asks questions:**
+
+- Answer clearly and completely
+- Provide additional context if needed
+- Don't rush them into implementation
+
+**If reviewer finds issues:**
+
+- Implementer (same subagent) fixes them
+- Reviewer reviews again
+- Repeat until approved
+- Don't skip the re-review
+
+**If subagent fails task:**
+
+- Dispatch fix subagent with specific instructions
+- Don't try to fix manually (context pollution)
+
+## Domain-Aware Dispatch
+
+When dispatching an implementer subagent, choose the agent whose expertise matches the task domain:
+
+| Task Domain                                   | Agent                  | When to Use                                               |
+| --------------------------------------------- | ---------------------- | --------------------------------------------------------- |
+| API design, databases, system architecture    | **Backend Architect**  | Schema changes, service layer, auth, performance          |
+| UI components, state management, styling      | **Frontend Developer** | Components, layouts, responsive design, accessibility     |
+| API contracts, docs, versioning               | **API Specialist**     | OpenAPI specs, client SDKs, API versioning, integration   |
+| Admin dashboards, RBAC, reporting, monitoring | **Admin Portal**       | Admin panels, roles/permissions, analytics, system health |
+| Documentation                                 | **Documenter**         | README updates, ADRs, API docs, AGENTS.md                 |
+| General implementation                        | **Implementer**        | Tasks that don't fit a specialist domain                  |
+
+**Multi-domain tasks:** If a task spans domains (e.g., "add endpoint with UI"), dispatch the primary domain specialist and note the secondary concern. For example, dispatch **Backend Architect** for the endpoint, then **Frontend Developer** for the UI — as separate tasks.
+
+The implementer-prompt.md template works for any of these agents — just specify which agent to dispatch.
+
+## Integration
+
+**Required workflow skills:**
+
+- **superpowers:writing-plans** - Creates the plan this skill executes
+- **superpowers:requesting-code-review** - Code review template for reviewer subagents
+- **superpowers:finishing-a-development-branch** - Complete development after all tasks
+
+**Subagents should use:**
+
+- **superpowers:test-driven-development** - Subagents follow TDD for each task
+
+**Domain specialist agents (see `.github/agents/` or `.cursor/agents/`):**
+
+- **Backend Architect** - Backend and infrastructure tasks
+- **Frontend Developer** - UI and frontend tasks
+- **API Specialist** - API contract and integration tasks
+- **Admin Portal** - Admin dashboards, RBAC, reporting, monitoring tasks
+- **Documenter** - Documentation tasks
+- **Reviewer** - Code review (replaces generic code quality reviewer when invoked directly)
+
+**Alternative workflow:**
+
+- **superpowers:executing-plans** - Use for parallel session instead of same-session execution

package/src/monorepo/.agents/skills/subagent-driven-development/code-quality-reviewer-prompt.md

@@ -0,0 +1,20 @@
+# Code Quality Reviewer Prompt Template
+
+Use this template when dispatching a code quality reviewer subagent.
+
+**Purpose:** Verify implementation is well-built (clean, tested, maintainable)
+
+**Only dispatch after spec compliance review passes.**
+
+```
+Task tool (superpowers:code-reviewer):
+  Use template at requesting-code-review/code-reviewer.md
+
+  WHAT_WAS_IMPLEMENTED: [from implementer's report]
+  PLAN_OR_REQUIREMENTS: Task N from [plan-file]
+  BASE_SHA: [commit before task]
+  HEAD_SHA: [current commit]
+  DESCRIPTION: [task summary]
+```
+
+**Code reviewer returns:** Strengths, Issues (Critical/Important/Minor), Assessment