@simplysm/sd-claude 13.0.74 → 13.0.76

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

@@ -0,0 +1,97 @@
+# Structure Analyzer Prompt
+
+Template for `Agent(general-purpose)`. Fill in `[TARGET_PATH]`.
+
+```
+You are analyzing code for structural organization and responsibility separation.
+Your question: "Is the code organized in a way that makes responsibilities clear and changes localized?"
+
+## Target
+
+Analyze ALL source files at [TARGET_PATH].
+
+## Step 1: List all source files
+
+Use Glob to list all .ts/.tsx files under the target path (exclude node_modules, dist).
+This is your analysis scope — every file in this list must be examined.
+
+## Step 2: Understand the architecture
+
+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 and public exports
+- Identify module boundaries: what each module/file owns
+- Map abstraction levels: which code is high-level vs low-level
+- Identify responsibility groupings: which functions/classes belong together
+
+## Step 3: Find structural improvement opportunities
+
+Look for:
+- Responsibility mixing: a single module handling concerns that should be separate
+- Abstraction level mismatch: high-level orchestration mixed with low-level implementation details in the same function/module
+- Module organization: related functionality scattered across unrelated files, or unrelated functionality grouped together
+- Leaking abstractions: internal implementation details exposed through public API that force consumers to know about internals
+- Coupling hotspots: modules where a change would cascade to many other files
+
+## CRITICAL — Scope boundaries
+
+Do NOT report ANY of the following. These are OUT OF SCOPE:
+- Bugs, security, logic errors, race conditions → that's code review
+- Naming consistency, API design, type quality → that's API review
+- Code complexity, duplication within a single function → that's code simplification
+- Circular dependencies, wrong dependency direction, boundary violations → that's code review (architectural defects)
+- Style preferences, comment style, import ordering
+- Dependencies that are clearly intentional and well-established patterns in the codebase
+- Issues in code OUTSIDE the target path
+
+**Key distinction:** Architectural DEFECTS (circular deps, boundary violations) are for code review. Structural IMPROVEMENTS (better responsibility separation, cleaner abstraction levels) are for this analyzer.
+
+## Step 4: Self-verify before reporting
+
+Before including ANY finding:
+
+1. **Improvement vs defect**: Is this a structural improvement suggestion, or an architectural defect? If defect → not in scope.
+2. **Evidence check**: Can you point to specific code that shows the structural issue?
+3. **Intentional pattern check**: Is this an established pattern used consistently across the codebase? If yes → by-design, drop it.
+4. **Scope check**: Is the issue IN the target code, not in how other packages are structured?
+
+**Quality over quantity: 3 verified structural findings > 10 maybe-findings.**
+
+## Constraints
+
+- Analysis only. Do NOT modify any files.
+- Do NOT provide corrected code blocks. Describe improvements in words only.
+- Only report issues with concrete evidence (specific code references).
+- If the structure is consistent across the codebase, treat it as intentional.
+
+## Output Format
+
+Use this exact format for every finding:
+
+### [HIGH|MEDIUM|LOW] title
+
+- **File**: path/to/file.ts:42
+- **Evidence**: what you observed (include code snippet)
+- **Issue**: what the structural concern is
+- **Suggestion**: how to improve the structure (in words, not code)
+
+Impact levels:
+- HIGH: Major structural issue. Responsibilities are significantly misplaced or abstractions are deeply leaked.
+- MEDIUM: Notable structural concern. Better organization would meaningfully improve maintainability.
+- LOW: Improvement opportunity. Cleaner structure exists but current organization is workable.
+
+Start your report with:
+
+## Structure Analysis Results
+
+### Summary
+- Files reviewed: N
+- Module structure: brief description
+- Findings: X HIGH, Y MEDIUM, Z LOW
+
+### Findings
+[findings here]
+```

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

@@ -176,12 +176,29 @@ Edit skill without testing? Same violation.
 - Don't "adapt" while running tests
 - Delete means delete
 
+**Only exemption — pure mechanical edits:** Typo fixes, tool/variable renames where the behavioral guidance is identical (e.g., `TodoWrite` → `TaskCreate`). If you're changing what the skill *teaches*, it's not mechanical — test it.
+
 **REQUIRED BACKGROUND:** The sd-tdd skill explains why this matters. Same principles apply to documentation.
 
 ## Testing All Skill Types
 
 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)"];
+}
+```
+
 ### Discipline-Enforcing Skills (rules/requirements)
 
 **Examples:** TDD, verification-before-completion, designing-before-coding
@@ -253,6 +270,8 @@ Example: Testing a "condition-based-waiting" skill
 | "Academic review is enough"            | Reading ≠ using. Test application scenarios.                                                                    |
 | "No time to test"                      | Deploying untested skill wastes more time fixing it later.                                                      |
 | "I already know the baseline failures" | You know what YOU think the failures are. Run a subagent to see what ACTUALLY happens. Knowledge ≠ observation. |
+| "This is process theater" | If the process catches even one issue you missed, it paid for itself. "Theater" is what you call process before it saves you. |
+| "It applies the wrong test methodology" | Different skill types need different tests (pressure vs retrieval), but ALL types need testing. No type is exempt. |
 
 **All of these mean: Test before deploying. No exceptions.**
 
@@ -264,6 +283,10 @@ Skills that enforce discipline need to resist rationalization. **See writing-gui
 
 Follow the TDD cycle:
 
+### Subagent Rules
+
+**NEVER use `isolation: "worktree"` when launching subagents.** Worktrees break lint/build tooling. Always run subagents in the default (non-isolated) mode.
+
 ### RED: Write Failing Test (Baseline)
 
 Run pressure scenario with subagent WITHOUT the skill. Document exact behavior: