@simplysm/sd-claude 13.0.85 → 13.0.86

package/claude/skills/sd-api-review/SKILL.md

@@ -1,85 +0,0 @@
----
-name: sd-api-review
-description: Used when requesting "API review", "api-review", "sd-api-review", "API improvement", "public API review", "API intuitiveness", etc.
----
-
-# SD API Review — Public API Intuitiveness Review and Improvement
-
-Extracts the public API from the specified path (package/folder/file), compares it against relevant standards and similar libraries to derive intuitiveness improvements, then establishes an implementation plan via the `/sd-plan` process. Breaking changes are permitted, and user intuitiveness is the top priority.
-
-ARGUMENTS: Target path (required). Example: `/sd-api-review packages/my-pkg`
-
----
-
-## Step 1: Validate Arguments
-
-1. Extract the **target path** from ARGUMENTS. If no path is provided, display "Please specify a target path. Example: `/sd-api-review packages/my-pkg`" and terminate.
-
-## Step 2: Extract Public API
-
-Collect the public API of the target.
-- **Folder/file target**: Directly analyze exports from the given path
-- **Depth**: Exported symbols (classes, functions, interfaces, types, constants) + public methods/properties of exported classes
-
-If there are no exports, display "The target has no exported API." and terminate.
-
-## Step 3: Comparative Analysis and Improvement Derivation
-
-### 3-1. Determine Comparison Targets
-
-- Analyze package metadata and code contents to infer the domain, then automatically select multiple widely-used libraries in that domain.
-- Automatically include relevant standards (HTML, WAI-ARIA, Web API, TC39, JavaScript, CSS, etc.) based on the domain.
-
-### 3-2. External API Research
-
-Use WebSearch and WebFetch to research the following two axes with **equal weight**.
-Compare at the **category/pattern level** (do not search for each individual symbol).
-
-1. **Standards**: Research naming, attributes, and patterns from official specifications of domain-related standards.
-2. **Libraries**: Research APIs from official documentation of the selected libraries.
-
-### 3-3. Derive Improvements
-
-Compare the API catalog from Step 2 against external APIs to derive improvements. Review from the perspectives of naming, structure, consistency, patterns, usability, and type quality.
-
-Precautions:
-- Breaking changes are not a concern. They are fully permitted.
-- When input/output/purpose differs or behavior differs, proposals may be incorrect — this must always be recognized. (A common mistake)
-
-Each improvement must include the following:
-- **Current**: Current API state (code example)
-- **Proposed**: Improved API (code example)
-- **Reasons to change**: Rationale for the change (including standard/library comparisons)
-- **Reasons not to change**: Rationale for maintaining the current state
-
-## Step 4: Establish Implementation Plan via sd-plan
-
-Using the improvements derived in Step 3 as the task description, invoke `sd-plan` via the Skill tool. Pass the following in args:
-
-```
-The following are API improvements **proposed by LLM analysis**.
-Since the improvements are not explicitly requested modifications by the user, treat them as unclear.
-
-## Target
-<target path>
-
-## LLM-Proposed Improvements — Comparative Analysis Table
-When asking the user about unclear improvements, **always present** the following content first so the user can understand the context.
-
-```
-Improvement:
-- Current:
-- Proposed:
-- Reasons to change:
-- Reasons not to change:
-```
-
-## Required Considerations for Implementation
-1. Breaking changes are not a concern. They are fully permitted.
-2. Use Grep to search for usages of the changed API across the entire monorepo and update them together.
-3. Do not leave deprecated wrappers (clean break).
-```
-
-## Step 5: Execute the Plan
-
-Once sd-plan is complete and a finalized plan is produced, modify the code according to that plan.

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

@@ -1,72 +0,0 @@
----
-name: sd-review
-description: Used when requesting "bug review", "sd-review", "code review", "find bugs", etc. Analyzes code at the specified path for potential bugs, then creates a plan and applies fixes.
----
-
-# SD Review — Potential Bug Detection
-
-Reads the code at the specified path, analyzes it for potential bugs, then creates and executes a plan via the `/sd-plan` process.
-
-ARGUMENTS: Target path (required). Specify any path within the repo.
-
----
-
-## Step 1: Validate Arguments
-
-1. Extract the target path from ARGUMENTS.
-2. If no path is provided, display "Please specify a target path. Example: `/sd-review packages/my-pkg`" and stop.
-
-## Step 2: Bug Analysis (Do Not Modify Code)
-
-Read the code at the target path and search for potential bugs from the following 5 perspectives.
-Do not modify the code under any circumstances. Only compile and output a list of findings.
-
-**Analysis Perspectives:**
-1. **Logic/Correctness** — Incorrect conditions, off-by-one errors, wrong operators, unintended branching
-2. **Null/Undefined Safety** — Missing null checks, unused optional chaining, misuse of type assertions
-3. **Error Handling** — Swallowed errors, missing catch blocks, improper error propagation
-4. **Edge Cases** — Empty arrays/strings, boundary values, concurrency/race conditions, missing await
-5. **Resource Management** — Unclosed connections, event listener leaks, memory leak patterns
-
-Write each finding in the following format:
-```
-- **filepath:line**
-  - Current code: (excerpt of the relevant code)
-  - Problem description:
-  - Suggested fix:
-  - Reasons to fix: Rationale for applying the fix
-  - Reasons not to fix: Rationale for keeping the current code
-```
-
-If no findings are discovered, display "No potential bugs were found." and stop.
-
-## Step 3: Create Plan via sd-plan
-
-Using the list of findings from Step 2 as the task description, invoke `sd-plan` via the Skill tool. Pass the following as args:
-
-```
-The following are potential bug fixes **analyzed and suggested by the LLM**.
-Since these fixes were not explicitly requested by the user, treat them as uncertain.
-
-## Target
-<target path>
-
-## LLM-Suggested Fixes
-When asking the user about uncertain fixes, **always present** the following information first so the user can understand the context.
-
-```
-Fix:
-- Filepath:line:
-- Current code: (excerpt of the relevant code)
-- Problem description:
-- Suggested fix:
-- Reasons to fix:
-- Reasons not to fix:
-```
-
-<Full list of findings from Step 2>
-```
-
-## Step 4: Execute Plan
-
-Once sd-plan completes and produces a finalized plan, apply the code modifications according to that plan.

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

@@ -1,66 +0,0 @@
----
-name: sd-simplify
-description: Used when requesting "code simplification", "simplify", "sd-simplify", "code refinement", etc. Analyzes code at a specified path, creates a plan, and applies modifications.
----
-
-# SD Simplify — Path-Specific Code Simplification
-
-Analyzes code at a specified path using the built-in `/simplify`, then creates and executes a plan via the `/sd-plan` process.
-
-ARGUMENTS: Target path (required). Specify any path within the repository.
-
----
-
-## Step 1: Validate Arguments
-
-1. Extract the target path from ARGUMENTS.
-2. If no path is provided, display the message "Please specify a target path. Example: `/sd-simplify packages/my-pkg`" and stop.
-
-## Step 2: simplify Analysis (Do Not Modify)
-
-Invoke `simplify` using the Skill tool. Pass the following instructions as args:
-
-```
-Review the current codebase at the <target path> path. (Not recently changed code)
-Do NOT modify any code. Only compile and output a list of items to fix.
-Write each item in the following format:
-- **file-path:line**
-  - Current code: (excerpt of the relevant code)
-  - Problem description:
-  - Suggested improvement:
-  - Reasons to change: Rationale for applying the improvement
-  - Reasons not to change: Rationale for keeping the current code
-```
-
-Replace the `<target path>` placeholder with the actual path extracted in Step 1.
-
-## Step 3: Create a Plan with sd-plan
-
-Using the list of items to fix from Step 2 as the task description, invoke `sd-plan` using the Skill tool. Pass the following as args:
-
-```
-The following are code improvement suggestions **proposed by an LLM analysis**.
-Since these suggestions were not explicitly requested by the user, treat them as unclear.
-
-## Target
-<target path>
-
-## LLM-Suggested Improvements
-When asking the user about unclear suggestions, **always present** the following details first so the user can understand the context.
-
-```
-Suggestion:
-- File path:line:
-- Current code: (excerpt of the relevant code)
-- Problem description:
-- Suggested improvement:
-- Reasons to change:
-- Reasons not to change:
-```
-
-<Full list of items to fix from Step 2>
-```
-
-## Step 4: Execute the Plan
-
-Once sd-plan completes and a finalized plan is produced, modify the code according to that plan.