@simplysm/sd-claude 13.0.76 → 13.0.77

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

@@ -1,31 +1,26 @@
 # API Reviewer Prompt
 
-Template for `Agent(general-purpose)`. Fill in `[TARGET_PATH]`.
+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?"
 
-## Target
+## Context
 
-Review ALL source files at [TARGET_PATH].
+1. Review the following project conventions relevant to API design and naming:
 
-## Step 1: List all source files
+[CONVENTIONS]
 
-Use Glob to list all .ts/.tsx files under the target path (exclude node_modules, dist).
+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 2: Map the public API surface
+## Step 1: Deep Review
 
-Read the following reference files for project conventions:
-- `CLAUDE.md` — project overview and conventions
-- `.claude/rules/sd-refs-linker.md` — reference guide linking to detailed docs per topic (read relevant refs based on the target code)
-
-Then:
-- Read index.ts to list all exports (types, functions, constants)
-- Read each exported type/interface/function definition
-- Read test files and consumer code to see actual usage patterns
-
-## Step 3: Find issues
+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
@@ -34,38 +29,31 @@ Look for:
 - Defaults: basic use cases requiring excessive configuration
 - Pattern consistency: similar tasks requiring different patterns
 
-Important: Internal consistency takes priority over external standards.
-Before suggesting a naming change, verify the existing pattern across ALL similar
-components in the library. Do NOT suggest external conventions that break internal consistency.
+Internal consistency takes priority over external standards.
 
 Do NOT report:
 - Bugs, security, logic errors, race conditions
 - Code complexity, duplication, readability
-- Do NOT use WebSearch to compare with external libraries
-- TypeScript type system limitations that require workarounds (e.g., discriminated unions not narrowing due to template literals) — these are language constraints, not API design flaws
-- Naming preferences where the current name is used consistently across the codebase — consistency > personal preference
-- Minor field duplication in small interfaces (< 10 fields) where extraction adds indirection without real benefit
-
-## Step 4: Self-verify before reporting
+- 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)
 
-Before including ANY finding, verify:
+## Step 2: Self-verify
 
-1. **Severity check**: CRITICAL = developers WILL write wrong code because of this API. Not "could theoretically be confusing."
-2. **Consistency check**: Before suggesting a rename, search ALL usages. If the name is used consistently everywhere, it's NOT a finding.
-3. **Scope check**: Only report on the PUBLIC API of the target package. Do not report on how consumers should use it differently.
+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 from the code.
-- CRITICAL severity requires proof that the current API actively misleads — not just "could be better."
+- Only report issues with real evidence.
+- CRITICAL requires proof the API actively misleads.
 
 ## Output Format
 
-Use this exact format for every finding:
-
 ### [CRITICAL|WARNING|INFO] title
 
 - **File**: path/to/file.ts:42
@@ -73,23 +61,15 @@ Use this exact format for every finding:
 - **Issue**: what the problem is
 - **Suggestion**: how to improve it
 
-Severity:
-- CRITICAL: API misleads developers or types are insufficient for correct usage
-- WARNING: Significant DX friction — unnecessary complexity or inconsistency
-- INFO: Minor improvement — better naming or defaults exist
-
-Start your report with:
+Start with:
 
 ## API Review Results
 
 ### Summary
-- Files reviewed: N
+- Files deep-reviewed: N (list them)
 - Public API surface: brief description
 - Findings: X CRITICAL, Y WARNING, Z INFO
 
 ### Findings
 [findings here]
-
-### Positive Observations
-[what's already well-designed — keep these]
 ```

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

@@ -1,31 +1,25 @@
 # Code Reviewer Prompt
 
-Template for `Agent(general-purpose)`. Fill in `[TARGET_PATH]`.
+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?"
 
-## Target
+## Context
 
-Review ALL source files at [TARGET_PATH].
+1. Review the following project conventions relevant to correctness/safety:
 
-## Step 1: List all source files
+[CONVENTIONS]
 
-Use Glob to list all .ts/.tsx files under the target path (exclude node_modules, dist).
-This is your review scope — every file in this list must be examined.
+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 2: Understand the codebase
+## Step 1: Deep Review
 
-Read the following reference files for project conventions:
-- `CLAUDE.md` — project overview and conventions
-- `.claude/rules/sd-refs-linker.md` — reference guide linking to detailed docs per topic (read relevant refs based on the target code)
-
-Then:
-- Read index.ts to map the module structure
-- Read each source file to understand logic flows, data transformations, error paths
-
-## Step 3: Find issues
+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
@@ -33,39 +27,36 @@ Look for:
 - 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 (reaching into another package's internals), wrong dependency direction (higher-level packages imported by lower-level ones)
+- Architectural defects: circular dependencies, boundary violations
 
 Do NOT report:
-- Naming consistency, API design, type quality (including `any` types)
-- Code complexity, duplication, readability improvements (handled by Code Simplifier)
-- Structural improvement suggestions (handled by Structure Analyzer)
+- Naming, API design, pure type quality
+- Code complexity, duplication, readability
 - Style preferences unless they cause actual bugs
-- Type definitions alone — a type allowing `stack?: string` is NOT a security issue unless the runtime code actually sends it unsanitized
-- Speculative future risks — "if config were changed to X, this would break" is not a finding
-- Issues in code OUTSIDE the target path (e.g., how other packages consume these types)
+- Type definitions alone without runtime trigger
+- Speculative future risks
+- Issues outside the reviewed files
 
-## Step 4: Self-verify before reporting
+**`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).
 
-Before including ANY finding, ask yourself:
+## Step 2: Self-verify
 
-1. **Is there runtime code here that actually triggers this?** (Not just a type definition)
-2. **Does the evidence contradict my conclusion?** (If you find a bound/limit that prevents the issue, drop it)
-3. **Is this within the target scope?** (Not about how other packages use this code)
+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..." or "exploitability is limited because..." — that means it's NOT a real finding. Drop it.
+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 the runtime behavior is demonstrably wrong or risky.
-- If your own analysis shows the issue is mitigated, do NOT report it.
+- Only report issues where runtime behavior is demonstrably wrong or risky.
 
 ## Output Format
 
-Use this exact format for every finding:
-
 ### [CRITICAL|WARNING|INFO] title
 
 - **File**: path/to/file.ts:42
@@ -78,12 +69,12 @@ Severity:
 - WARNING: Real problem that can occur in practice
 - INFO: Defensive improvement, low risk
 
-Start your report with:
+Start with:
 
 ## Code Review Results
 
 ### Summary
-- Files reviewed: N
+- Files deep-reviewed: N (list them)
 - Findings: X CRITICAL, Y WARNING, Z INFO
 
 ### Findings

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

@@ -1,62 +1,59 @@
 # Convention Checker Prompt
 
-Template for `Agent(general-purpose)`. Fill in `[TARGET_PATH]`.
+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?"
 
-## Target
+## Context
 
-Check ALL source files at [TARGET_PATH].
+1. Review the following project conventions (these are your Grep criteria):
 
-## Step 1: Read convention files
+[CONVENTIONS]
 
-Read `.claude/rules/sd-refs-linker.md` to find ALL convention files that apply to the target code. Then read each referenced convention file.
+2. Read these explore result files: [EXPLORE_FILES]
+3. Collect ALL file paths from the **File Summaries** sections — these are your Grep scope
 
-At minimum, always read:
-- `.claude/refs/sd-code-conventions.md` — applies to all code
+## Step 1: Extract Grep-searchable patterns
 
-Also read topic-specific refs based on the target code (e.g., `sd-solid.md` for SolidJS, `sd-orm.md` for ORM).
+From the conventions, extract rules that can be checked via text pattern matching.
 
-## Step 2: Extract prohibited patterns
-
-From each convention file, extract rules that define prohibited or required patterns. Build a checklist of Grep-searchable patterns.
-
-Example from `sd-code-conventions.md`:
+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
 
-## Step 3: Grep for each pattern
+**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.
 
-For each prohibited pattern, run a Grep search across all target files. Report every match.
+## Step 2: Grep for each pattern
 
-Do NOT skip, downgrade, or dismiss matches for any reason:
-- "Widespread usage" is NOT an exception — it means widespread violation
-- "No alternative" is NOT an exception — the convention file lists alternatives
-- "Codebase pattern" is NOT an exception — the convention defines what's correct, not current usage
+For each prohibited pattern, run Grep across all files in scope.
 
-## Step 4: Report
+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
 
-Use this exact format for every finding:
+## Step 3: Report
 
 ### [WARNING] title
 
 - **File**: path/to/file.ts:42
-- **Convention**: which rule from which convention file
+- **Convention**: which rule from which convention
 - **Evidence**: the matching code (include snippet)
-- **Suggestion**: the fix recommended by the convention file
+- **Suggestion**: the fix recommended by the convention
 
-All convention violations are WARNING severity. Use CRITICAL only if the violation causes an immediate runtime bug.
+All violations are WARNING. Use CRITICAL only if the violation causes an immediate runtime bug.
 
-Start your report with:
+Start with:
 
 ## Convention Check Results
 
 ### Summary
 - Files checked: N
-- Convention files referenced: [list]
+- Conventions referenced: [list]
 - Violations found: N
 
 ### Violations

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

@@ -0,0 +1,92 @@
+# 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]
+```

package/claude/skills/sd-skill/SKILL.md

@@ -184,19 +184,13 @@ Edit skill without testing? Same violation.
 
 Different skill types need different test approaches:
 
-```dot
-digraph test_methodology {
-    "What type of skill?" [shape=diamond];
-    "Pressure test\n(compliance under stress)" [shape=box];
-    "Application test\n(correct technique usage)" [shape=box];
-    "Recognition test\n(when/how to apply)" [shape=box];
-    "Retrieval test\n(find & use reference)" [shape=box];
-
-    "What type of skill?" -> "Pressure test\n(compliance under stress)" [label="Discipline\n(rules/requirements)"];
-    "What type of skill?" -> "Application test\n(correct technique usage)" [label="Technique\n(how-to guides)"];
-    "What type of skill?" -> "Recognition test\n(when/how to apply)" [label="Pattern\n(mental models)"];
-    "What type of skill?" -> "Retrieval test\n(find & use reference)" [label="Reference\n(docs/APIs)"];
-}
+```mermaid
+flowchart TD
+    A{"What type of skill?"}
+    A -->|"Discipline (rules/requirements)"| B["Pressure test<br>(compliance under stress)"]
+    A -->|"Technique (how-to guides)"| C["Application test<br>(correct technique usage)"]
+    A -->|"Pattern (mental models)"| D["Recognition test<br>(when/how to apply)"]
+    A -->|"Reference (docs/APIs)"| E["Retrieval test<br>(find & use reference)"]
 ```
 
 ### Discipline-Enforcing Skills (rules/requirements)
@@ -330,9 +324,9 @@ example-js.js, example-py.py, example-go.go
 
 ### ❌ Code in Flowcharts
 
-```dot
-step1 [label="import fs"];
-step2 [label="read file"];
+```mermaid
+flowchart TD
+    A["import fs"] --> B["read file"]
 ```
 
 **Why bad:** Can't copy-paste, hard to read

package/claude/skills/sd-skill/writing-guide.md

@@ -4,17 +4,13 @@
 
 ## Flowchart Usage
 
-```dot
-digraph when_flowchart {
-    "Need to show information?" [shape=diamond];
-    "Decision where I might go wrong?" [shape=diamond];
-    "Use markdown" [shape=box];
-    "Small inline flowchart" [shape=box];
-
-    "Need to show information?" -> "Decision where I might go wrong?" [label="yes"];
-    "Decision where I might go wrong?" -> "Small inline flowchart" [label="yes"];
-    "Decision where I might go wrong?" -> "Use markdown" [label="no"];
-}
+Use Mermaid (`flowchart`) when there are decision branches or non-obvious process flows.
+
+```mermaid
+flowchart TD
+    A{"Need to show information?"} -->|yes| B{"Decision where I might go wrong?"}
+    B -->|yes| C[Small inline flowchart]
+    B -->|no| D[Use markdown]
 ```
 
 **Use flowcharts ONLY for:**

package/claude/skills/sd-tdd/SKILL.md

@@ -50,26 +50,21 @@ Implement fresh from tests. Period.
 
 ## Red-Green-Refactor
 
-```dot
-digraph tdd_cycle {
-    rankdir=LR;
-    red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
-    verify_red [label="Verify fails\ncorrectly", shape=diamond];
-    green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
-    verify_green [label="Verify passes\nAll green", shape=diamond];
-    refactor [label="REFACTOR\nClean up", shape=box, style=filled, fillcolor="#ccccff"];
-    next [label="Next", shape=ellipse];
-
-    red -> verify_red;
-    verify_red -> green [label="yes"];
-    verify_red -> red [label="wrong\nfailure"];
-    green -> verify_green;
-    verify_green -> refactor [label="yes"];
-    verify_green -> green [label="no"];
-    refactor -> verify_green [label="stay\ngreen"];
-    verify_green -> next;
-    next -> red;
-}
+```mermaid
+flowchart LR
+    A["RED<br>Write failing test"]:::red --> B{"Verify fails<br>correctly"}
+    B -->|yes| C["GREEN<br>Minimal code"]:::green
+    B -->|"wrong failure"| A
+    C --> D{"Verify passes<br>All green"}
+    D -->|yes| E["REFACTOR<br>Clean up"]:::blue
+    D -->|no| C
+    E -->|"stay green"| D
+    D --> F(["Next"])
+    F --> A
+
+    classDef red fill:#ffcccc
+    classDef green fill:#ccffcc
+    classDef blue fill:#ccccff
 ```
 
 ### RED - Write Failing Test

package/claude/skills/sd-use/SKILL.md

@@ -11,7 +11,7 @@ Analyze user request from ARGUMENTS, select the best matching skill, explain why
 ## Execution Flow
 
 1. Read ARGUMENTS
-2. If user names a specific skill (e.g., "sd-explore로..."), route to that skill directly
+2. If user names a specific skill, route to that skill directly
 3. Otherwise, match against catalog below
 4. Report selection with reason
 5. Execute immediately
@@ -35,14 +35,13 @@ Analyze user request from ARGUMENTS, select the best matching skill, explain why
 | `sd-skill`           | Create or edit skills                                                                                                                           |
 | `sd-email-analyze`   | Analyze, read, or summarize email files (`.eml` or `.msg`) — parsing and attachment extraction                                                  |
 | `sd-document`        | Read or write document files (`.docx`, `.xlsx`, `.pptx`, `.pdf`) — content extraction, creation, data export                                    |
-| `sd-explore`         | Explore, analyze, trace, or understand code structure, architecture, or implementation flow                                                     |
 
 ## Selection Rules
 
-1. **Explicit skill name** — If user mentions a specific skill name (e.g., "sd-explore로...", "sd-plan 만들어줘"), route to that skill directly
+1. **Explicit skill name** — If user mentions a specific skill name, route to that skill directly
 2. Select **exactly one** skill — the most specific match wins
 3. **Review & Refactor**: "find bugs", "review", "refactor", "improve structure", "remove duplication" → `sd-review`
-4. **Sequential requests** (e.g., "brainstorm하고 plan 만들어줘"): Route to the **first** skill only. After completion, user can invoke the next
+4. **Sequential requests**: Route to the **first** skill only. After completion, user can invoke the next
 5. If nothing matches, use **default LLM behavior** and handle the request directly
 6. Pass ARGUMENTS through as the skill's input