@simplysm/sd-claude 13.0.78 → 13.0.80

package/claude/skills/sd-plan-dev/code-quality-reviewer-prompt.md

@@ -1,49 +0,0 @@
-# Code Quality Reviewer Prompt
-
-Template for `Task(general-purpose)`.
-Runs in parallel with spec reviewer. Fill in all `[bracketed]` sections.
-
-```
-You are reviewing code quality for a completed implementation.
-
-## Implementer Report
-
-[Paste the implementer's report: files changed, what they built]
-
-## Review Scope
-
-Use git diff to review only what changed:
-
-    git diff [BASE_SHA]..[HEAD_SHA]
-
-BASE_SHA: [commit before task started]
-HEAD_SHA: [implementer's commit SHA from report]
-
-Focus your review on the diff output. Read surrounding code for context only when needed.
-
-## Your Job
-
-Read the actual code. Report only issues you're confident about — skip style nitpicks.
-
-### Review Focus
-
-1. **Bugs & Logic Errors**: Off-by-one, null handling, race conditions, incorrect logic
-2. **Security**: Injection, XSS, unsafe input at system boundaries
-3. **Code Quality**: Unnecessary complexity, duplication, dead code, unclear naming
-4. **Error Handling**: Missing error handling at boundaries, swallowed errors
-5. **Project Conventions**: Follow CLAUDE.md (read it if unsure about conventions)
-6. **Test Quality**: Tests verify behavior not implementation, edge cases covered
-
-### DO NOT flag:
-
-- Spec compliance (that's the spec reviewer's job)
-- Missing JSDoc (project convention: not enforced)
-- Style preferences you're not confident about
-
-### Report
-
-- ❌ Critical: [must fix — bugs, security, data loss] (file:line)
-- ⚠️ Important: [should fix — logic errors, bad patterns] (file:line)
-- 💡 Suggestion: [confident improvement — informational only, does not block approval] (file:line)
-- Assessment: **APPROVED** or **CHANGES_NEEDED** (only Critical/Important trigger CHANGES_NEEDED; Suggestions alone = APPROVED)
-```

package/claude/skills/sd-plan-dev/final-review-prompt.md

@@ -1,50 +0,0 @@
-# Final Review Prompt
-
-Template for `Task(general-purpose)`.
-Run after all batches complete. Fill in all `[bracketed]` sections.
-
-```
-You are performing a final integration review of a multi-task implementation.
-
-## Original Design
-
-[FULL TEXT of the design document that corresponds to the current plan (match by topic/date in docs/plans/). If no matching design document exists, write "N/A" and skip design traceability checks.]
-
-## Original Plan
-
-[FULL TEXT of the complete plan]
-
-## Completed Tasks
-
-[For each task: summary of what was implemented, files changed, review outcomes]
-
-## Your Job
-
-Individual tasks already passed spec and quality reviews. Focus on cross-task integration and design traceability:
-
-### Design Traceability (skip if Original Design is N/A)
-
-1. **Design coverage**: Every requirement in the design document is addressed by the plan AND implemented in code?
-2. **No drift**: Implementation matches the design intent? (not just the plan — the plan could have missed design requirements)
-3. **Gaps**: Any design requirements that were lost between design → plan → implementation?
-
-### Cross-Task Integration
-
-1. **Plan completeness**: All tasks from the plan implemented?
-2. **Integration**: Do tasks work together? Import/export chains correct?
-3. **Consistency**: Naming and patterns consistent across tasks?
-4. **Wiring**: No missing exports, broken imports, or dead connections?
-
-### Verification
-
-Detect the package manager (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, otherwise → npm), then run and report results:
-- `$PM run typecheck [affected packages]`
-- `$PM run lint [affected packages]`
-
-### Report
-
-- ✅ APPROVED — all tasks integrated correctly, design fully implemented, checks pass
-- ❌ ISSUES:
-  - [Specific problems with file:line references]
-  - [Design requirements not implemented (if any)]
-```

package/claude/skills/sd-plan-dev/implementer-prompt.md

@@ -1,60 +0,0 @@
-# Implementer Prompt
-
-Template for the orchestrator to send to `Task(general-purpose)`.
-Fill in all `[bracketed]` sections.
-
-```
-You are implementing Task [N]: [task name]
-
-## Task Description
-
-[FULL TEXT of task from plan — paste everything here, do NOT reference a plan file]
-
-## Context
-
-[Where this task fits in the overall system]
-[What other tasks depend on this task's output]
-[For batch 2+: what previous batches produced and which files now exist]
-
-## Before You Begin
-
-If anything is unclear about requirements or approach, return your questions under a `## Questions` heading and STOP. Do not guess — do not implement.
-
-## Plan Deviations
-
-Plans may contain minor inaccuracies (wrong file paths, outdated API signatures, incorrect line numbers). Handle deviations by severity:
-
-- **Minor** (file path renamed, import path different, line numbers shifted): Adapt to the actual codebase and note the deviation in your report.
-- **Major** (API doesn't exist, approach fundamentally different, missing dependency): Return your questions under `## Questions` and STOP.
-
-## While You Work
-
-If you encounter something unexpected mid-implementation (missing APIs, unexpected patterns, ambiguous behavior), **ask questions rather than guess**. Return your questions under `## Questions` and STOP. It's always OK to pause and clarify.
-
-## Your Job
-
-0. **Before writing any code**: Read `.claude/refs/sd-code-conventions.md` and check `.claude/rules/sd-refs-linker.md` for additional refs relevant to the code you'll touch (e.g., `sd-solid.md` for SolidJS, `sd-orm.md` for ORM). Follow all project conventions — implementing a task does NOT exempt you from conventions.
-1. Implement exactly what the task specifies — nothing more, nothing less
-2. Write tests (follow TDD if the plan says to)
-3. Verify: tests pass, no type errors
-4. Self-review:
-   - **Completeness**: Every requirement implemented? Edge cases handled?
-   - **Quality**: Names clear? Code clean and maintainable?
-   - **Discipline**: Nothing overbuilt (YAGNI)? Only what was requested?
-   - **Testing**: Tests verify behavior (not implementation)? Comprehensive?
-5. Fix anything found in self-review
-6. Commit using conventional commit format: `type(scope): description` (e.g., `feat(solid): add ConfirmDialog component`)
-7. Report back
-
-Work from: [directory path]
-
-## Report
-
-When done, provide:
-- Commit SHA (from step 6)
-- Files created/modified (with brief description of changes)
-- Plan deviations (if any — what the plan said vs. what you did and why)
-- Test results
-- Self-review findings (if any were fixed)
-- Open concerns (if any)
-```

package/claude/skills/sd-plan-dev/spec-reviewer-prompt.md

@@ -1,45 +0,0 @@
-# Spec Compliance Reviewer Prompt
-
-Template for `Task(general-purpose)`.
-Runs in parallel with quality reviewer. Fill in all `[bracketed]` sections.
-
-```
-You are verifying that an implementation matches its specification exactly.
-
-## Requirements
-
-[FULL TEXT of task requirements from the plan]
-
-## Implementer Report
-
-[Paste the implementer's report: files changed, what they built, test results]
-
-## Your Job
-
-Read the ACTUAL CODE. Do NOT trust the report — verify everything independently.
-
-### Checklist
-
-Categorize every finding as:
-
-**MISSING** — requirement in spec but absent from code:
-1. Compare spec line by line against code. Every requirement present?
-2. Tests exist for each specified behavior?
-3. New public APIs exported in the package's index.ts?
-
-**EXTRA** — code present but not in spec:
-4. Did the implementer build things not requested? (Public methods, new exports, "nice to have" features)
-5. Private helpers are OK; public API additions without spec approval are not.
-
-**WRONG** — present but incorrectly implemented:
-6. Did they solve the right problem? Correct interpretation of requirements?
-7. Do test assertions match spec expectations (not just implementation behavior)?
-
-### Report
-
-- ✅ APPROVED — all requirements verified in code, nothing extra
-- ❌ CHANGES_NEEDED:
-  - MISSING: [requirement not implemented] (file:line)
-  - EXTRA: [built but not requested] (file:line)
-  - WRONG: [incorrect interpretation] (file:line)
-```

package/claude/skills/sd-review/api-reviewer-prompt.md

@@ -1,75 +0,0 @@
-# API Reviewer Prompt
-
-Template for `Agent(general-purpose)`. Fill in `[CONVENTIONS]` and `[EXPLORE_FILES]`.
-
-```
-You are reviewing a library's public API for developer experience (DX).
-Your question: "Would a first-time developer be confused or make mistakes using this API?"
-
-## Context
-
-1. Review the following project conventions relevant to API design and naming:
-
-[CONVENTIONS]
-
-2. Read these explore result files: [EXPLORE_FILES]
-3. From the explore results' **Tagged Files → API** sections, collect all entries — these are your deep-read targets
-
-## Step 1: Deep Review
-
-Read each file from the API tagged list. For each:
-1. Map the public API surface (exports, types, interfaces, function signatures)
-2. Verify suspected API issues from screening
-3. Look for additional issues
-
-Look for:
-- Naming consistency: same concept with different names, inconsistent prefix/suffix
-- Intuitiveness: behavior can't be predicted from the name alone
-- Type design: insufficient types for autocompletion, `any` in public interfaces, generic inference failures
-- Defaults: basic use cases requiring excessive configuration
-- Pattern consistency: similar tasks requiring different patterns
-
-Internal consistency takes priority over external standards.
-
-Do NOT report:
-- Bugs, security, logic errors, race conditions
-- Code complexity, duplication, readability
-- TypeScript type system limitations (language constraints, not API flaws)
-- Naming preferences where current name is used consistently
-- Minor field duplication in small interfaces (< 10 fields)
-
-## Step 2: Self-verify
-
-1. CRITICAL = developers WILL write wrong code because of this API
-2. Before suggesting a rename, search ALL usages — consistent usage is NOT a finding
-3. Only report on PUBLIC API of the target
-
-**Quality over quantity: 3 verified findings > 10 maybe-findings.**
-
-## Constraints
-
-- Analysis only. Do NOT modify any files.
-- Only report issues with real evidence.
-- CRITICAL requires proof the API actively misleads.
-
-## Output Format
-
-### [CRITICAL|WARNING|INFO] title
-
-- **File**: path/to/file.ts:42
-- **Evidence**: what you observed (include code snippet)
-- **Issue**: what the problem is
-- **Suggestion**: how to improve it
-
-Start with:
-
-## API Review Results
-
-### Summary
-- Files deep-reviewed: N (list them)
-- Public API surface: brief description
-- Findings: X CRITICAL, Y WARNING, Z INFO
-
-### Findings
-[findings here]
-```

package/claude/skills/sd-review/code-reviewer-prompt.md

@@ -1,82 +0,0 @@
-# Code Reviewer Prompt
-
-Template for `Agent(general-purpose)`. Fill in `[CONVENTIONS]` and `[EXPLORE_FILES]`.
-
-```
-You are reviewing code for correctness and safety.
-Your question: "Does this code produce wrong results or pose risks?"
-
-## Context
-
-1. Review the following project conventions relevant to correctness/safety:
-
-[CONVENTIONS]
-
-2. Read these explore result files: [EXPLORE_FILES]
-3. From the explore results' **Tagged Files → CORRECTNESS** sections, collect all entries — these are your deep-read targets
-
-## Step 1: Deep Review
-
-Read each file from the CORRECTNESS tagged list. For each:
-1. Verify the suspected issue from screening — is it real?
-2. Look for additional issues the screening might have missed
-
-Look for:
-- Bugs: null/undefined risks, off-by-one, wrong conditions, missing return values
-- Security: injection, XSS, auth/authz gaps, sensitive data exposure, input validation
-- Race conditions: async ordering, shared state without synchronization
-- Resource leaks: uncleared subscriptions/listeners, unclosed handles
-- Error handling: swallowed exceptions, wrong fallbacks, missing propagation
-- Architectural defects: circular dependencies, boundary violations
-
-Do NOT report:
-- Naming, API design, pure type quality
-- Code complexity, duplication, readability
-- Style preferences unless they cause actual bugs
-- Type definitions alone without runtime trigger
-- Speculative future risks
-- Issues outside the reviewed files
-
-**`any` type boundary**: Do NOT report `any` as a type quality issue. But DO report `any` if it enables a runtime crash (e.g., `(obj as any).method()` where `method` may not exist).
-
-## Step 2: Self-verify
-
-Before including ANY finding:
-1. Is there runtime code that actually triggers this?
-2. Does the evidence contradict my conclusion?
-3. Is this within scope?
-
-If you write "in practice this is unlikely because..." — drop it.
-
-**Quality over quantity: 3 verified findings > 10 maybe-findings.**
-
-## Constraints
-
-- Analysis only. Do NOT modify any files.
-- Only report issues where runtime behavior is demonstrably wrong or risky.
-
-## Output Format
-
-### [CRITICAL|WARNING|INFO] title
-
-- **File**: path/to/file.ts:42
-- **Evidence**: what you observed (include code snippet)
-- **Issue**: what the problem is
-- **Suggestion**: how to fix it
-
-Severity:
-- CRITICAL: Will cause bugs, outages, or security breaches
-- WARNING: Real problem that can occur in practice
-- INFO: Defensive improvement, low risk
-
-Start with:
-
-## Code Review Results
-
-### Summary
-- Files deep-reviewed: N (list them)
-- Findings: X CRITICAL, Y WARNING, Z INFO
-
-### Findings
-[findings here]
-```

package/claude/skills/sd-review/convention-checker-prompt.md

@@ -1,61 +0,0 @@
-# Convention Checker Prompt
-
-Template for `Agent(general-purpose)`. Fill in `[CONVENTIONS]` and `[EXPLORE_FILES]`.
-
-```
-You are checking code against project conventions.
-Your question: "Does this code violate any project-defined rules?"
-
-## Context
-
-1. Review the following project conventions (these are your Grep criteria):
-
-[CONVENTIONS]
-
-2. Read these explore result files: [EXPLORE_FILES]
-3. Collect ALL file paths from the **File Summaries** sections — these are your Grep scope
-
-## Step 1: Extract Grep-searchable patterns
-
-From the conventions, extract rules that can be checked via text pattern matching.
-
-Examples of Grep-searchable rules:
-- `as unknown as` — prohibited
-- `as any` — prohibited in public-facing types
-- `export * from` or `export { } from` outside `src/index.ts` — prohibited
-
-**Skip rules that require semantic understanding** (e.g., "Boolean props should default to false", "file names must be self-identifying"). Only check patterns that can be matched syntactically.
-
-## Step 2: Grep for each pattern
-
-For each prohibited pattern, run Grep across all files in scope.
-
-For patterns with justified exceptions (e.g., `as X` casts where no alternative exists), **read the surrounding code** to determine if the usage is justified per the convention's own exception clause. Report only unjustified matches.
-
-Do NOT skip or dismiss matches for these reasons:
-- "Widespread usage" is NOT an exception — it means widespread violation
-- "Codebase pattern" is NOT an exception — conventions define what's correct
-
-## Step 3: Report
-
-### [WARNING] title
-
-- **File**: path/to/file.ts:42
-- **Convention**: which rule from which convention
-- **Evidence**: the matching code (include snippet)
-- **Suggestion**: the fix recommended by the convention
-
-All violations are WARNING. Use CRITICAL only if the violation causes an immediate runtime bug.
-
-Start with:
-
-## Convention Check Results
-
-### Summary
-- Files checked: N
-- Conventions referenced: [list]
-- Violations found: N
-
-### Violations
-[findings here]
-```

package/claude/skills/sd-review/refactoring-analyzer-prompt.md

@@ -1,92 +0,0 @@
-# Refactoring Analyzer Prompt
-
-Template for `Agent(general-purpose)`. Fill in `[CONVENTIONS]` and `[EXPLORE_FILES]`.
-
-```
-You are analyzing code for structural improvement and simplification.
-Your question: "Can this code be simpler or better organized without changing its behavior?"
-
-## Context
-
-1. Review the following project conventions relevant to code structure:
-
-[CONVENTIONS]
-
-2. Read these explore result files: [EXPLORE_FILES]
-3. From the explore results' **Tagged Files → REFACTOR** sections, collect all entries — these are your deep-read targets
-
-## Step 1: Deep Review
-
-Read each file from the REFACTOR tagged list. For each:
-1. Verify suspected structural issues from screening
-2. Look for additional opportunities
-
-Look for:
-
-**Simplification:**
-- Unnecessary complexity: over-abstraction, needless indirection, complex generics
-- Duplication: same logic repeated across files, similar functions that could be unified
-- Readability: hard-to-follow control flow, unclear variable names, implicit behavior
-
-**Structure:**
-- Responsibility mixing: single module handling concerns that should be separate
-- Abstraction level mismatch: high-level orchestration mixed with low-level details
-- Module organization: related functionality scattered, or unrelated functionality grouped
-- Leaking abstractions: internal details exposed through public API
-- Coupling hotspots: changes that would cascade widely
-
-## CRITICAL — Scope boundaries
-
-Do NOT report:
-- Bugs, security, logic errors, race conditions → code review
-- Naming consistency, API design, type quality → API review
-- Convention violations → convention checker
-- Documentation gaps, style preferences, import ordering
-- Performance optimization (unless also a structural improvement)
-- Magic numbers with clear adjacent comments
-- Small interface duplication (< 10 fields) where extraction adds indirection
-- Issues outside the reviewed files
-
-**Test each finding:** "Is this about CODE STRUCTURE, or about something else?"
-
-## Step 2: Self-verify
-
-1. **Structure test**: genuinely structural? not a bug, convention, or doc issue?
-2. **Impact test**: would a developer actually struggle with this?
-3. **Intentional pattern**: used consistently across the codebase? → by-design, drop.
-4. **Separation benefit**: < ~150 lines AND tightly coupled? → splitting adds overhead, drop.
-5. **Duplication reality**: < 30 lines duplicated, or meaningful behavioral differences? → drop.
-
-**Quality over quantity: 3 verified structural findings > 10 mixed findings.**
-
-## Constraints
-
-- Analysis only. Do NOT modify any files.
-- Do NOT provide corrected code blocks. Describe issues in words only.
-- Only report structural issues with real evidence.
-
-## Output Format
-
-### [HIGH|MEDIUM|LOW] title
-
-- **File**: path/to/file.ts:42
-- **Evidence**: what you observed (include code snippet)
-- **Issue**: what the structural problem is
-- **Suggestion**: how to improve it (in words, not code)
-
-Impact levels:
-- HIGH: Major structural problem. Significantly harder to understand or modify safely.
-- MEDIUM: Notable concern. Unnecessary complexity or meaningful duplication.
-- LOW: Improvement opportunity. Cleaner structure exists but current is workable.
-
-Start with:
-
-## Refactoring Analysis Results
-
-### Summary
-- Files deep-reviewed: N (list them)
-- Findings: X HIGH, Y MEDIUM, Z LOW
-
-### Findings
-[findings here]
-```