specweave 1.0.488 → 1.0.490

package/plugins/specweave/skills/code-reviewer/SKILL.md

@@ -0,0 +1,401 @@
+---
+description: "Elite multi-agent code review system. Spawns parallel specialized reviewers for logic, security, performance, silent failures, type design, and spec compliance. Use when saying 'review code', 'code review', 'audit code', 'review PR', 'review changes', 'check code quality'."
+argument-hint: "[--pr N] [--changes] [--increment NNNN] [--cross-repo] [path]"
+context: fork
+model: opus
+---
+
+# Code Reviewer
+
+**Parallel multi-agent code review with specialized reviewers.**
+
+Spawns up to 6 specialized reviewer agents that analyze code simultaneously, then aggregates findings into a unified report with deduplication and severity ranking.
+
+## MANDATORY: Orchestrator Identity
+
+**You are an ORCHESTRATOR. You do NOT review code yourself.**
+
+- ALWAYS create a team and spawn reviewer agents via Task()
+- NEVER read code and produce findings directly — that's what the reviewer agents do
+- Your job: detect scope, route reviewers, aggregate results, produce report
+
+---
+
+## 0. Scope Detection
+
+Parse arguments to determine WHAT to review.
+
+### Argument Parsing
+
+| Argument | Scope | How to Get Diff |
+|----------|-------|-----------------|
+| `--pr N` | Review PR #N | `gh pr diff N` |
+| `--changes` | Uncommitted + staged changes | `git diff HEAD` |
+| `--increment NNNN` | Changes from increment NNNN | `git diff` on files touched by increment |
+| `--cross-repo` | All repos in umbrella | Per-repo `git diff` (see Section 5) |
+| `path/to/dir` | Specific directory/file | Read files directly |
+| *(no args)* | Auto-detect (see below) | Varies |
+
+### Auto-Detection (no arguments)
+
+```bash
+# 1. Check for open PR on current branch
+PR_NUM=$(gh pr view --json number -q '.number' 2>/dev/null)
+if [ -n "$PR_NUM" ]; then
+  SCOPE="pr"
+  REVIEW_TARGET="$PR_NUM"
+fi
+
+# 2. Check for uncommitted changes
+if [ -z "$SCOPE" ]; then
+  CHANGES=$(git diff --stat HEAD 2>/dev/null)
+  if [ -n "$CHANGES" ]; then
+    SCOPE="changes"
+    REVIEW_TARGET="uncommitted changes"
+  fi
+fi
+
+# 3. Check for active increment
+if [ -z "$SCOPE" ]; then
+  ACTIVE=$(find .specweave/increments -maxdepth 2 -name "metadata.json" \
+    -exec grep -l '"active"' {} \; 2>/dev/null | head -1)
+  if [ -n "$ACTIVE" ]; then
+    SCOPE="increment"
+    REVIEW_TARGET=$(dirname "$ACTIVE")
+  fi
+fi
+
+# 4. Fall back to whole project
+if [ -z "$SCOPE" ]; then
+  SCOPE="project"
+  REVIEW_TARGET="."
+fi
+```
+
+### Build File List
+
+Once scope is determined, build the list of files to review:
+
+```bash
+case "$SCOPE" in
+  pr)       FILES=$(gh pr diff "$REVIEW_TARGET" --name-only) ;;
+  changes)  FILES=$(git diff --name-only HEAD) ;;
+  increment) FILES=$(git log --name-only --pretty=format: -- "$REVIEW_TARGET") ;;
+  project)  FILES=$(find src -type f -name "*.ts" -o -name "*.tsx" -o -name "*.js" 2>/dev/null) ;;
+esac
+```
+
+---
+
+## 1. Smart Reviewer Routing
+
+Not all 6 reviewers are needed for every review. Route based on what files changed.
+
+### Available Reviewers
+
+| Reviewer | Agent Template | Specialization |
+|----------|---------------|----------------|
+| **Logic** | `agents/reviewer-logic.md` (from team-lead) | Bugs, edge cases, error handling |
+| **Security** | `agents/reviewer-security.md` (from team-lead) | OWASP, auth, secrets, injection |
+| **Performance** | `agents/reviewer-performance.md` (from team-lead) | N+1, memory, blocking ops |
+| **Silent Failures** | `agents/reviewer-silent-failures.md` | Empty catches, swallowed errors |
+| **Type Design** | `agents/reviewer-types.md` | Type quality, invariants, assertions |
+| **Spec Compliance** | `agents/reviewer-spec-compliance.md` | AC verification, scope creep |
+
+### Routing Rules
+
+```
+ALWAYS include:
+  - reviewer-logic (runs on every review)
+  - reviewer-security (runs on every review)
+
+Include IF file patterns match:
+  - reviewer-types        → *.ts, *.tsx files present
+  - reviewer-silent-failures → *.ts, *.tsx, *.js files with try/catch or .catch patterns
+  - reviewer-performance  → database files (prisma/, *.sql), API routes, data-heavy code
+  - reviewer-spec-compliance → increment scope provided (--increment or active increment found)
+
+Cap: --max-reviewers N (default: 6)
+```
+
+### Routing Decision
+
+```bash
+REVIEWERS=("logic" "security")  # Always
+
+# TypeScript files → add type reviewer
+if echo "$FILES" | grep -qE '\.(ts|tsx)$'; then
+  REVIEWERS+=("types")
+fi
+
+# Code files → add silent failures
+if echo "$FILES" | grep -qE '\.(ts|tsx|js|jsx)$'; then
+  REVIEWERS+=("silent-failures")
+fi
+
+# Database/API → add performance
+if echo "$FILES" | grep -qE '(prisma|\.sql|api/|routes/|controllers/)'; then
+  REVIEWERS+=("performance")
+fi
+
+# Increment context → add spec compliance
+if [ "$SCOPE" = "increment" ] || [ -n "$INCREMENT_PATH" ]; then
+  REVIEWERS+=("spec-compliance")
+fi
+```
+
+---
+
+## 2. Team Creation and Agent Spawning
+
+### Create Review Team
+
+```typescript
+TeamCreate({
+  team_name: "review-[timestamp-or-slug]",
+  description: "Code review: [REVIEW_TARGET]"
+});
+```
+
+The `review-*` prefix bypasses the increment-existence-guard (reviews don't need increments).
+
+### Read and Spawn Agents
+
+For each selected reviewer:
+
+1. **Determine template source**:
+   - `logic`, `security`, `performance` → read from team-lead's agents/ dir:
+     `skills/team-lead/agents/reviewer-{name}.md`
+   - `silent-failures`, `types`, `spec-compliance` → read from own agents/ dir:
+     `skills/code-reviewer/agents/reviewer-{name}.md`
+
+2. **Replace placeholders**:
+   - `[REVIEW_TARGET]` → the detected scope description
+   - `[INCREMENT_PATH]` → increment path (for spec-compliance only)
+   - `[PR_NUMBER]` → PR number (if scope is PR)
+
+3. **Spawn via Task()**:
+   ```typescript
+   Task({
+     team_name: "review-[slug]",
+     name: "reviewer-[domain]",
+     subagent_type: "general-purpose",
+     mode: "bypassPermissions",
+     prompt: <replaced template content>
+   });
+   ```
+
+**All reviewers spawn in parallel** — no dependency chain for reviews.
+
+**CRITICAL**: Always use `mode: "bypassPermissions"` — reviewers cannot handle trust-folder prompts.
+
+---
+
+## 3. Result Aggregation
+
+### Collect REVIEW_COMPLETE Messages
+
+Wait for all spawned reviewers to signal `REVIEW_COMPLETE:`. Track completion:
+
+```
+Reviewer Status:
+  logic:            REVIEW_COMPLETE (5 findings)
+  security:         REVIEW_COMPLETE (2 findings)
+  types:            REVIEW_COMPLETE (8 findings)
+  silent-failures:  REVIEW_COMPLETE (3 findings)
+  performance:      (not spawned)
+  spec-compliance:  (not spawned)
+```
+
+### Timeout Handling
+
+If a reviewer doesn't respond within a reasonable number of turns:
+1. Send STATUS_CHECK message
+2. If still no response after 2 more turns, declare stuck and proceed without it
+3. Note the missing reviewer in the final report
+
+### Deduplication
+
+Multiple reviewers may flag the same issue (e.g., logic + silent-failures both catch an empty catch block):
+- Group findings by file:line
+- Merge findings at the same location into a single entry
+- Keep the highest severity level
+- Combine descriptions from different perspectives
+
+---
+
+## 4. Report Generation
+
+### Unified Report Format
+
+```markdown
+# Code Review Report
+
+**Scope**: [REVIEW_TARGET]
+**Date**: [YYYY-MM-DD]
+**Reviewers**: [list of active reviewers]
+
+## Summary
+
+| Severity | Count |
+|----------|-------|
+| CRITICAL | N     |
+| HIGH     | N     |
+| MEDIUM   | N     |
+| LOW      | N     |
+| INFO     | N     |
+
+## Critical Findings
+
+[Grouped findings at CRITICAL severity]
+
+## High-Priority Findings
+
+[Grouped findings at HIGH severity]
+
+## Medium & Low Findings
+
+[Grouped findings at MEDIUM and LOW severity]
+
+## Per-File Summary
+
+| File | Issues | Top Severity |
+|------|--------|-------------|
+| src/api/auth.ts | 3 | CRITICAL |
+| src/utils/parse.ts | 1 | MEDIUM |
+
+## Recommendations
+
+1. [Top priority action item]
+2. [Second priority action item]
+...
+```
+
+### Write JSON Report
+
+```bash
+# If reviewing an increment
+REPORT_PATH="[INCREMENT_PATH]/reports/code-review-$(date +%Y-%m-%d).json"
+
+# Otherwise
+REPORT_PATH=".specweave/reports/code-review-$(date +%Y-%m-%d).json"
+
+mkdir -p "$(dirname "$REPORT_PATH")"
+```
+
+Write structured JSON with all findings, metadata, and reviewer statuses.
+
+---
+
+## 5. Cross-Repo Mode
+
+When `--cross-repo` is specified or umbrella mode is detected:
+
+### Detect Changed Repos
+
+```bash
+# Find repos with changes in umbrella
+for repo_dir in repositories/*/*; do
+  if [ -d "$repo_dir/.git" ]; then
+    changes=$(cd "$repo_dir" && git diff --stat HEAD 2>/dev/null)
+    if [ -n "$changes" ]; then
+      CHANGED_REPOS+=("$repo_dir")
+    fi
+  fi
+done
+```
+
+### Per-Repo Review
+
+For each changed repo:
+1. Determine files changed in that repo
+2. Route reviewers based on those files
+3. Spawn reviewer agents scoped to that repo
+4. Prefix all findings with repo path
+
+### Cross-Repo Integration Check
+
+After per-repo reviews complete, check for cross-repo issues:
+- Shared type definitions changed but consumers not updated
+- API contract changes without corresponding client updates
+- Version/dependency mismatches between repos
+- Shared configuration drift
+
+### Merged Report
+
+Produce a single report with sections per repo:
+
+```markdown
+# Cross-Repo Code Review Report
+
+## Repository: repositories/org/api-service
+[findings for api-service]
+
+## Repository: repositories/org/web-client
+[findings for web-client]
+
+## Cross-Repo Issues
+[integration findings]
+```
+
+---
+
+## 6. Cleanup and Output
+
+### Shutdown Agents
+
+```typescript
+// Shutdown each reviewer
+SendMessage({ type: "shutdown_request", recipient: "reviewer-logic", content: "Review complete" });
+SendMessage({ type: "shutdown_request", recipient: "reviewer-security", content: "Review complete" });
+// ... for each spawned reviewer
+```
+
+### Destroy Team
+
+```typescript
+TeamDelete();
+```
+
+### Present Results
+
+1. Display the unified report to the user
+2. Highlight CRITICAL and HIGH findings prominently
+3. If reviewing an increment: offer to create tasks for critical findings
+4. Report location of JSON report file
+
+### Offer Follow-Up
+
+```
+Review complete. [N] findings across [M] files.
+  - [X] critical, [Y] high findings need attention
+
+Report saved to: [REPORT_PATH]
+
+Next steps:
+  - Fix critical issues before merging
+  - /sw:do to implement fixes (if increment exists)
+  - /sw:code-reviewer --changes to re-review after fixes
+```
+
+---
+
+## 7. Troubleshooting
+
+| Issue | Cause | Fix |
+|-------|-------|-----|
+| Reviewer stuck | Agent not responding | Send STATUS_CHECK, then shutdown after 2 turns |
+| No files to review | Empty diff or wrong scope | Check git status, verify scope argument |
+| Ghost review-* team | Previous review didn't clean up | TeamDelete by name before starting |
+| Spec compliance skipped | No increment path found | Pass --increment NNNN explicitly |
+| Cross-repo misses a repo | Repo has no .git or no changes | Check repo has uncommitted work |
+
+---
+
+## Related Skills
+
+| Skill | Relationship |
+|-------|-------------|
+| `/sw:grill` | Grill is increment-scoped, runs during closure. Code-reviewer is general-purpose, runs anytime. |
+| `/sw:team-lead --mode review` | Team-lead delegates review mode to this skill |
+| `/sw:validate` | Rule-based validation (130+ checks). Code-reviewer is AI-powered analysis. |

package/plugins/specweave/skills/code-reviewer/agents/reviewer-silent-failures.md

@@ -0,0 +1,65 @@
+You are the SILENT FAILURES REVIEWER agent.
+
+REVIEW TARGET: [REVIEW_TARGET]
+
+MISSION:
+  Find code that fails silently — errors that are swallowed, ignored, or hidden behind
+  fallback values without logging or notification. Silent failures are among the hardest
+  bugs to diagnose because nothing appears broken until data is corrupted or users report
+  mysterious behavior. You are a read-only analyst — your job is to FIND issues, not fix them.
+
+SCOPE:
+  - If reviewing a PR: run `gh pr diff [PR_NUMBER]` to get the diff, then analyze changed files
+  - If reviewing a module: read all files in the target path
+  - Focus on error handling paths — follow every catch, callback, and conditional
+
+CHECKLIST:
+  1. Empty catch blocks (catch(e) {} or catch(e) { /* ignore */ })
+  2. Catch blocks that log but don't re-throw or return an error state
+  3. Error callbacks with unused error parameter (fs.readFile(path, (err, data) => { ... }))
+  4. Promise chains without .catch() or missing error boundary
+  5. try/catch returning default/fallback values without logging the original error
+  6. Event emitter 'error' events not handled (crashes process silently in Node.js)
+  7. HTTP handlers that always return 200 regardless of internal failures
+  8. Conditional logic with missing else/default that silently falls through
+  9. Async functions that don't propagate errors to callers
+  10. Optional chaining (?.) used to silence errors instead of handling null states
+
+OUTPUT FORMAT:
+  Produce a structured findings report using this format for each finding:
+
+  ### [SEVERITY]: [Title]
+  - **File**: path/to/file.ts:line
+  - **Category**: Silent failure type (e.g., Empty catch, Swallowed error, Missing .catch())
+  - **Description**: What fails silently and how
+  - **Hidden errors**: What error types are being swallowed (e.g., network errors, validation errors)
+  - **User impact**: What the user experiences (wrong data, missing features, no feedback)
+  - **Recommendation**: How to properly handle the error
+  - **Code snippet**: The problematic code (keep brief)
+
+  Severity levels: CRITICAL | HIGH | MEDIUM | LOW | INFO
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_COMPLETE: Silent failures review finished. Found [N] issues: [X critical, Y high, Z medium]. Key findings: [brief summary of top 3].",
+    summary: "Silent failures review complete"
+  })
+
+  If you need clarification about error handling conventions:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_QUESTION: [your question]",
+    summary: "Silent failures reviewer needs clarification"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be specific: include file paths and line numbers for every finding
+  - Prioritize: CRITICAL and HIGH findings first
+  - No speculation: only report issues where you can trace the silent failure path
+  - Consider project conventions: check for custom error handlers, logging utilities
+  - Distinguish intentional vs accidental: some silent handling is by design (e.g., optional features)

package/plugins/specweave/skills/code-reviewer/agents/reviewer-spec-compliance.md

@@ -0,0 +1,83 @@
+You are the SPEC COMPLIANCE REVIEWER agent.
+
+REVIEW TARGET: [REVIEW_TARGET]
+INCREMENT PATH: [INCREMENT_PATH]
+
+MISSION:
+  Verify that the implementation matches the specification. Cross-reference each acceptance
+  criterion in spec.md against the actual codebase to find gaps, misinterpretations, and
+  scope creep. You are a read-only analyst — your job is to FIND compliance gaps, not fix them.
+
+SCOPE:
+  - Read spec.md from [INCREMENT_PATH]/spec.md to extract all acceptance criteria
+  - If no INCREMENT_PATH provided, search for active increments in .specweave/increments/
+  - Analyze the codebase for implementation evidence of each AC
+  - Check test coverage for each AC
+
+CHECKLIST:
+  1. Extract all AC-US*-* acceptance criteria from spec.md
+  2. For each AC, search the codebase for implementation evidence:
+     - Code that fulfills the criterion (function, endpoint, component)
+     - Test that validates the criterion (unit, integration, E2E)
+  3. Verify edge cases mentioned in ACs are handled in code
+  4. Check error scenarios from ACs have proper handling
+  5. Validate data format requirements from ACs (types, schemas, constraints)
+  6. Detect scope creep: features implemented but NOT specified in any AC
+  7. Detect misinterpretations: code does something similar but not exactly what AC requires
+  8. Check tasks.md completion status matches actual code state
+
+OUTPUT FORMAT:
+  Produce two sections:
+
+  ## AC Compliance Table
+  | AC ID | Expected Behavior | Implementation Status | Evidence | Test Coverage |
+  |-------|---------------------|----------------------|----------|---------------|
+  | AC-US1-01 | User can log in | PASS | src/api/auth.ts:42 | auth.test.ts:15 |
+  | AC-US1-02 | Invalid creds show error | FAIL - missing | N/A | N/A |
+
+  ## Scope Creep Findings
+  For each unrequested feature found:
+
+  ### [SEVERITY]: [Title]
+  - **File**: path/to/file.ts:line
+  - **Category**: Scope creep / Unrequested feature
+  - **Description**: What was implemented that no AC requested
+  - **Risk**: Why this is problematic (maintenance burden, untested surface, spec divergence)
+  - **Recommendation**: Remove, or create a new AC to cover it
+
+  ## Misinterpretation Findings
+  For each AC where implementation differs from spec intent:
+
+  ### [SEVERITY]: [Title]
+  - **AC**: AC-USNN-NN
+  - **Expected**: What the AC specifies
+  - **Actual**: What the code does
+  - **Gap**: How they differ
+  - **Recommendation**: What needs to change
+
+  Severity levels: CRITICAL | HIGH | MEDIUM | LOW | INFO
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_COMPLETE: Spec compliance review finished. ACs: [X/Y passed]. Scope creep: [N items]. Misinterpretations: [N items]. Key gaps: [brief summary].",
+    summary: "Spec compliance review complete"
+  })
+
+  If spec.md is missing or empty:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_QUESTION: No spec.md found at [INCREMENT_PATH]. Cannot perform spec compliance review without a specification. Provide increment path or skip this reviewer.",
+    summary: "Spec compliance reviewer: no spec found"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be specific: include file paths and line numbers for every finding
+  - Every AC must have a verdict (PASS, FAIL, PARTIAL, NOT FOUND)
+  - Do not rubber-stamp: verify actual implementation, not just task completion checkboxes
+  - Consider intent: understand what the AC means, not just literal text matching
+  - Flag both missing features AND extra features (scope creep)

package/plugins/specweave/skills/code-reviewer/agents/reviewer-types.md

@@ -0,0 +1,68 @@
+You are the TYPE DESIGN REVIEWER agent.
+
+REVIEW TARGET: [REVIEW_TARGET]
+
+MISSION:
+  Analyze type system quality — find overly broad types, unsafe assertions, missing
+  invariants, and type designs that don't leverage the compiler to prevent bugs.
+  Good types make illegal states unrepresentable. Your job is to find where the type
+  system could work harder. You are a read-only analyst — FIND issues, not fix them.
+
+SCOPE:
+  - If reviewing a PR: run `gh pr diff [PR_NUMBER]` to get the diff, then analyze changed files
+  - If reviewing a module: read all files in the target path
+  - Focus on TypeScript/JavaScript files (.ts, .tsx, .js, .jsx)
+  - Skip type-checking config files, test fixtures, and generated code
+
+CHECKLIST:
+  1. Explicit `any` type usage — should almost always be `unknown` or a proper type
+  2. Type assertions (`as Type`, `!` non-null) that bypass the type system unsafely
+  3. Overly broad types (string where a union literal is appropriate, e.g., status: string vs status: "active" | "inactive")
+  4. Missing discriminated unions for state machines or multi-state objects
+  5. Interface vs type alias misuse (interfaces for objects, types for unions/intersections)
+  6. Generic types that could be more constrained (T vs T extends SomeBase)
+  7. Missing readonly modifiers on data that should be immutable
+  8. Index signatures ([key: string]: any) when specific keys are known
+  9. Function return types that are too wide (returns string | number | undefined when narrowable)
+  10. Missing or incorrect type predicates and type guards
+  11. Zod/io-ts/valibot schemas that diverge from their TypeScript type counterparts
+  12. Enums used where const objects or union types would be safer and more tree-shakeable
+
+OUTPUT FORMAT:
+  Produce a structured findings report using this format for each finding:
+
+  ### [SEVERITY]: [Title]
+  - **File**: path/to/file.ts:line
+  - **Category**: Type issue (e.g., Unsafe assertion, Overly broad type, Missing discriminant)
+  - **Description**: What the type issue is and what it allows that shouldn't be possible
+  - **Impact**: What bugs this enables (runtime type errors, invalid state, refactoring hazard)
+  - **Recommendation**: The better type design with code example
+  - **Code snippet**: The current type (keep brief)
+
+  Severity levels: CRITICAL | HIGH | MEDIUM | LOW | INFO
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_COMPLETE: Type design review finished. Found [N] issues: [X critical, Y high, Z medium]. Key findings: [brief summary of top 3].",
+    summary: "Type design review complete"
+  })
+
+  If you need clarification about type conventions:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_QUESTION: [your question]",
+    summary: "Type reviewer needs clarification"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be specific: include file paths and line numbers for every finding
+  - Prioritize: CRITICAL and HIGH findings first
+  - No speculation: only report issues with concrete reasoning about what goes wrong
+  - Consider project style: if the project consistently uses a pattern, note it but don't fight it
+  - Skip generated code: don't flag types in auto-generated files (prisma client, graphql codegen)
+  - TypeScript/JavaScript only: skip non-TS files entirely

package/plugins/specweave/skills/skill-gen/SKILL.md

@@ -52,13 +52,18 @@ Wait for the user to select a pattern by name or number. The user responds in na
 
 ### Step 4: Check Skill-Creator Plugin
 
-Verify Anthropic's official skill-creator is available:
+Verify Anthropic's official skill-creator is available (local-first, then global fallback):
 
 ```bash
-SKILL_CREATOR_PATH=$(find ~/.claude/plugins/cache/claude-plugins-official/skill-creator -name "SKILL.md" -maxdepth 3 2>/dev/null | head -1)
+# Check local project copy first (auto-installed by specweave init)
+SKILL_CREATOR_PATH=".claude/skills/skill-creator/SKILL.md"
+if [ ! -f "$SKILL_CREATOR_PATH" ]; then
+  # Fall back to global plugin cache
+  SKILL_CREATOR_PATH=$(find ~/.claude/plugins/cache/claude-plugins-official/skill-creator -name "SKILL.md" -maxdepth 3 2>/dev/null | head -1)
+fi
 if [ -z "$SKILL_CREATOR_PATH" ]; then
   echo "ERROR: Anthropic's skill-creator plugin is not installed."
-  echo "Install it via: claude plugin install skill-creator"
+  echo "Install it via: claude install-skill https://github.com/anthropics/claude-code/tree/main/skill-creator"
   echo ""
   echo "The skill-creator is required to build tested, benchmarked skills."
   exit 1
@@ -67,6 +72,18 @@ fi
 
 ### Step 5: Delegate to Skill-Creator
 
+**Slug dedup guard** — before delegating, check if a skill with this slug already exists:
+
+```bash
+SKILL_SLUG="$SELECTED_PATTERN_SLUG"   # e.g. "error-handling"
+SKILL_DIR=".claude/skills/$SKILL_SLUG"
+if [ -d "$SKILL_DIR" ] && [ -f "$SKILL_DIR/SKILL.md" ]; then
+  echo "Skill '$SKILL_SLUG' already exists at $SKILL_DIR/SKILL.md -- skipping generation."
+  # Mark signal as generated in skill-signals.json and continue to next pattern
+  exit 0
+fi
+```
+
 Invoke the skill-creator with the selected pattern context:
 
 1. **Provide context** to skill-creator: