@simplysm/sd-claude 13.0.78 → 13.0.81

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]
-```

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

@@ -1,417 +0,0 @@
----
-name: sd-skill
-description: "Skill creation and editing (explicit invocation only)"
----
-
-# Writing Skills
-
-## Overview
-
-**Writing skills IS Test-Driven Development applied to process documentation.**
-
-You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests pass (agents comply), and refactor (close loopholes).
-
-**Core principle:** If you didn't watch an agent fail without the skill, you don't know if the skill teaches the right thing.
-
-**REQUIRED BACKGROUND:** You MUST understand sd-tdd before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill adapts TDD to documentation.
-
-**Official guidance:** For Anthropic's official skill authoring best practices, see anthropic-best-practices.md. This document provides additional patterns and guidelines that complement the TDD-focused approach in this skill.
-
-## What is a Skill?
-
-A **skill** is a reference guide for proven techniques, patterns, or tools. Skills help future Claude instances find and apply effective approaches.
-
-**Skills are:** Reusable techniques, patterns, tools, reference guides
-
-**Skills are NOT:** Narratives about how you solved a problem once
-
-## TDD Mapping for Skills
-
-| TDD Concept             | Skill Creation                                   |
-| ----------------------- | ------------------------------------------------ |
-| **Test case**           | Pressure scenario with subagent                  |
-| **Production code**     | Skill document (SKILL.md)                        |
-| **Test fails (RED)**    | Agent violates rule without skill (baseline)     |
-| **Test passes (GREEN)** | Agent complies with skill present                |
-| **Refactor**            | Close loopholes while maintaining compliance     |
-| **Write test first**    | Run baseline scenario BEFORE writing skill       |
-| **Watch it fail**       | Document exact rationalizations agent uses       |
-| **Minimal code**        | Write skill addressing those specific violations |
-| **Watch it pass**       | Verify agent now complies                        |
-| **Refactor cycle**      | Find new rationalizations → plug → re-verify     |
-
-The entire skill creation process follows RED-GREEN-REFACTOR.
-
-## When to Create a Skill
-
-**Create when:**
-
-- Technique wasn't intuitively obvious to you
-- You'd reference this again across projects
-- Pattern applies broadly (not project-specific)
-- Others would benefit
-
-**Don't create for:**
-
-- One-off solutions
-- Standard practices well-documented elsewhere
-- Project-specific conventions (put in CLAUDE.md)
-- Mechanical constraints (if it's enforceable with regex/validation, automate it—save documentation for judgment calls)
-
-## Skill Types
-
-### Technique
-
-Concrete method with steps to follow (condition-based-waiting, root-cause-tracing)
-
-### Pattern
-
-Way of thinking about problems (flatten-with-flags, test-invariants)
-
-### Reference
-
-API docs, syntax guides, tool documentation (office docs)
-
-## Directory Structure
-
-```
-skills/
-  skill-name/
-    SKILL.md              # Main reference (required)
-    supporting-file.*     # Only if needed
-```
-
-**Flat namespace** - all skills in one searchable namespace
-
-**Separate files for:**
-
-1. **Heavy reference** (100+ lines) - API docs, comprehensive syntax
-2. **Reusable tools** - Scripts, utilities, templates
-
-**Keep inline:**
-
-- Principles and concepts
-- Code patterns (< 50 lines)
-- Everything else
-
-## SKILL.md Structure
-
-**Frontmatter (YAML):**
-
-- Only two fields supported: `name` and `description`
-- Max 1024 characters total
-- `name`: Use letters, numbers, and hyphens only (no parentheses, special chars)
-- `description`: Third-person, describes ONLY when to use (NOT what it does)
-  - Start with "Use when..." to focus on triggering conditions
-  - Include specific symptoms, situations, and contexts
-  - **NEVER summarize the skill's process or workflow** (see cso-guide.md for why)
-  - Keep under 500 characters if possible
-
-```markdown
----
-name: Skill-Name-With-Hyphens
-description: Use when [specific triggering conditions and symptoms]
----
-
-# Skill Name
-
-## Overview
-
-What is this? Core principle in 1-2 sentences.
-
-## When to Use
-
-[Small inline flowchart IF decision non-obvious]
-
-Bullet list with SYMPTOMS and use cases
-When NOT to use
-
-## Core Pattern (for techniques/patterns)
-
-Before/after code comparison
-
-## Quick Reference
-
-Table or bullets for scanning common operations
-
-## Implementation
-
-Inline code for simple patterns
-Link to file for heavy reference or reusable tools
-
-## Common Mistakes
-
-What goes wrong + fixes
-
-## Real-World Impact (optional)
-
-Concrete results
-```
-
-## Claude Search Optimization (CSO)
-
-**Critical for discovery.** See **cso-guide.md** for the complete guide covering description fields, keyword coverage, naming, token efficiency, and cross-referencing.
-
-## Writing Guidelines
-
-**See writing-guide.md** for flowchart usage, code examples, file organization, and bulletproofing techniques.
-
-## The Iron Law (Same as TDD)
-
-```
-NO SKILL WITHOUT A FAILING TEST FIRST
-```
-
-This applies to NEW skills AND EDITS to existing skills.
-
-Write skill before testing? Delete it. Start over.
-Edit skill without testing? Same violation.
-
-**No exceptions:**
-
-- Not for "simple additions"
-- Not for "just adding a section"
-- Not for "documentation updates"
-- Don't keep untested changes as "reference"
-- 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:
-
-```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)
-
-**Examples:** TDD, verification-before-completion, designing-before-coding
-
-**Test with:**
-
-- Academic questions: Do they understand the rules?
-- Pressure scenarios: Do they comply under stress?
-- Multiple pressures combined: time + sunk cost + exhaustion
-- Identify rationalizations and add explicit counters
-
-**Success criteria:** Agent follows rule under maximum pressure
-
-### Technique Skills (how-to guides)
-
-**Examples:** condition-based-waiting, root-cause-tracing, defensive-programming
-
-**Test with:**
-
-- Application scenarios: Can they apply the technique correctly?
-- Variation scenarios: Do they handle edge cases?
-- Missing information tests: Do instructions have gaps?
-
-**How to test:** Give a subagent a problem the technique solves, WITHOUT the skill. Observe what approach they use naturally. Then give the SAME problem WITH the skill and verify they apply the technique correctly.
-
-```
-Example: Testing a "condition-based-waiting" skill
-1. Ask subagent: "Fix this flaky test that uses setTimeout(500)"
-2. WITHOUT skill: Agent increases timeout to 2000ms (wrong approach)
-3. WITH skill: Agent replaces with polling/condition check (correct)
-```
-
-**Success criteria:** Agent successfully applies technique to new scenario
-
-### Pattern Skills (mental models)
-
-**Examples:** reducing-complexity, information-hiding concepts
-
-**Test with:**
-
-- Recognition scenarios: Do they recognize when pattern applies?
-- Application scenarios: Can they use the mental model?
-- Counter-examples: Do they know when NOT to apply?
-
-**Success criteria:** Agent correctly identifies when/how to apply pattern
-
-### Reference Skills (documentation/APIs)
-
-**Examples:** API documentation, command references, library guides
-
-**Test with:**
-
-- Retrieval scenarios: Can they find the right information?
-- Application scenarios: Can they use what they found correctly?
-- Gap testing: Are common use cases covered?
-
-**Success criteria:** Agent finds and correctly applies reference information
-
-## Common Rationalizations for Skipping Testing
-
-| Excuse                                 | Reality                                                                                                         |
-| -------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
-| "Skill is obviously clear"             | Clear to you ≠ clear to other agents. Test it.                                                                  |
-| "It's just a reference"                | References can have gaps, unclear sections. Test retrieval.                                                     |
-| "Testing is overkill"                  | Untested skills have issues. Always. 15 min testing saves hours.                                                |
-| "I'll test if problems emerge"         | Problems = agents can't use skill. Test BEFORE deploying.                                                       |
-| "Too tedious to test"                  | Testing is less tedious than debugging bad skill in production.                                                 |
-| "I'm confident it's good"              | Overconfidence guarantees issues. Test anyway.                                                                  |
-| "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.**
-
-## Bulletproofing Skills Against Rationalization
-
-Skills that enforce discipline need to resist rationalization. **See writing-guide.md** for detailed techniques on closing loopholes, spirit-vs-letter arguments, rationalization tables, and red flags lists.
-
-## RED-GREEN-REFACTOR for Skills
-
-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:
-
-- What choices did they make?
-- What rationalizations did they use (verbatim)?
-- Which pressures triggered violations?
-
-This is "watch the test fail" - you must see what agents naturally do before writing the skill.
-
-**You MUST actually run a subagent.** Do not substitute your own knowledge of "what agents would probably do." Your prediction of baseline behavior ≠ observed baseline behavior. Run the subagent, read the output, document what actually happened.
-
-### GREEN: Write Minimal Skill
-
-Write skill that addresses those specific rationalizations. Don't add extra content for hypothetical cases.
-
-Run same scenarios WITH skill. Agent should now comply.
-
-### REFACTOR: Close Loopholes
-
-Agent found new rationalization? Add explicit counter. Re-test until bulletproof.
-
-**Testing methodology:** See testing-skills-with-subagents.md for the complete testing methodology:
-
-- How to write pressure scenarios
-- Pressure types (time, sunk cost, authority, exhaustion)
-- Plugging holes systematically
-- Meta-testing techniques
-
-## Anti-Patterns
-
-### ❌ Narrative Example
-
-"In session 2025-10-03, we found empty projectDir caused..."
-**Why bad:** Too specific, not reusable
-
-### ❌ Multi-Language Dilution
-
-example-js.js, example-py.py, example-go.go
-**Why bad:** Mediocre quality, maintenance burden
-
-### ❌ Code in Flowcharts
-
-```mermaid
-flowchart TD
-    A["import fs"] --> B["read file"]
-```
-
-**Why bad:** Can't copy-paste, hard to read
-
-### ❌ Generic Labels
-
-helper1, helper2, step3, pattern4
-**Why bad:** Labels should have semantic meaning
-
-## STOP: Before Moving to Next Skill
-
-**After writing ANY skill, you MUST STOP and complete the deployment process.**
-
-**Do NOT:**
-
-- Create multiple skills in batch without testing each
-- Move to next skill before current one is verified
-- Skip testing because "batching is more efficient"
-
-**The deployment checklist below is MANDATORY for EACH skill.**
-
-Deploying untested skills = deploying untested code. It's a violation of quality standards.
-
-## Skill Creation Checklist (TDD Adapted)
-
-**IMPORTANT: Use TaskCreate to create todos for EACH checklist item below.**
-
-**RED Phase - Write Failing Test:**
-
-- [ ] Create pressure scenarios (3+ combined pressures for discipline skills)
-- [ ] Run scenarios WITHOUT skill - document baseline behavior verbatim
-- [ ] Identify patterns in rationalizations/failures
-
-**GREEN Phase - Write Minimal Skill:**
-
-- [ ] Name uses only letters, numbers, hyphens (no parentheses/special chars)
-- [ ] YAML frontmatter with only name and description (max 1024 chars)
-- [ ] Description starts with "Use when..." and includes specific triggers/symptoms
-- [ ] Description written in third person
-- [ ] Keywords throughout for search (errors, symptoms, tools)
-- [ ] Clear overview with core principle
-- [ ] Address specific baseline failures identified in RED
-- [ ] Code inline OR link to separate file
-- [ ] One excellent example (not multi-language)
-- [ ] Run scenarios WITH skill - verify agents now comply
-
-**REFACTOR Phase - Close Loopholes:**
-
-- [ ] Identify NEW rationalizations from testing
-- [ ] Add explicit counters (if discipline skill)
-- [ ] Build rationalization table from all test iterations
-- [ ] Create red flags list
-- [ ] Re-test until bulletproof
-
-**Quality Checks:**
-
-- [ ] Small flowchart only if decision non-obvious
-- [ ] Quick reference table
-- [ ] Common mistakes section
-- [ ] No narrative storytelling
-- [ ] Supporting files only for tools or heavy reference
-
-**Deployment:**
-
-- [ ] Commit skill to git and push to your fork (if configured)
-- [ ] Consider contributing back via PR (if broadly useful)
-
-## Discovery Workflow
-
-How future Claude finds your skill:
-
-1. **Encounters problem** ("tests are flaky")
-2. **Finds SKILL** (description matches)
-3. **Scans overview** (is this relevant?)
-4. **Reads patterns** (quick reference table)
-5. **Loads example** (only when implementing)
-
-**Optimize for this flow** - put searchable terms early and often.
-
-## The Bottom Line
-
-**Creating skills IS TDD for process documentation.**
-
-Same Iron Law: No skill without failing test first.
-Same cycle: RED (baseline) → GREEN (write skill) → REFACTOR (close loopholes).
-Same benefits: Better quality, fewer surprises, bulletproof results.
-
-If you follow TDD for code, follow it for skills. It's the same discipline applied to documentation.