@simplysm/sd-claude 13.0.0-beta.11

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

@@ -0,0 +1,95 @@
+---
+name: sd-readme
+description: Use when updating a package README.md to reflect recent code changes, or when asked to sync README with current implementation
+argument-hint: "<package-name or path>"
+model: haiku
+---
+
+# sd-readme
+
+Update a package's README.md based on git commits since its last modification.
+
+## Step 1: Resolve Package Path
+
+`$ARGUMENTS` is the package name or path (e.g., `sd-cli`, `packages/sd-cli`, `packages/core-common`).
+
+- If it doesn't start with `packages/`, prepend `packages/`.
+- Verify `<pkg-path>/README.md` exists. If not, stop and report.
+
+## Step 2: Gather Change Context
+
+Run these git commands **in sequence** (second depends on first):
+
+```bash
+# 1. Last commit that modified the README
+git log -1 --format="%H %ai %s" -- <pkg-path>/README.md
+```
+
+If git log returns **no output** (README was never committed), treat all package commits as relevant:
+
+```bash
+git log --oneline -- <pkg-path>/
+```
+
+Otherwise, take the commit hash from above, then:
+
+```bash
+# 2. All commits to the package since that hash
+git log <hash>..HEAD --oneline -- <pkg-path>/
+```
+
+If **no commits** exist since the last README update → report "README is already up to date" and **stop**.
+
+## Step 3: Categorize Changes
+
+For each commit, assess README impact:
+
+| Category | Impact | README Action |
+|----------|--------|---------------|
+| New public export (function, class, type) | **High** | Add documentation |
+| Changed API signature (params, return type) | **High** | Update existing docs |
+| Removed/renamed public API | **High** | Remove or update |
+| New feature (user-visible behavior) | **Medium** | Add description/example |
+| Bug fix | **Low** | Skip unless it changes documented behavior |
+| Refactoring (internal) | **None** | Skip |
+| Build/config/dependency change | **None** | Skip |
+| Version bump | **None** | Skip |
+
+For commits with **unclear impact**, inspect the actual diff:
+
+```bash
+git show <hash> -- <pkg-path>/src/
+```
+
+## Step 4: Cross-Check Exports
+
+Read `<pkg-path>/src/index.ts` to verify:
+
+- All **current public exports** are documented in the README
+- No **removed exports** are still documented
+- Any **new exports** not yet in README are identified
+
+This catches changes that might have been missed in commit analysis.
+
+## Step 5: Present Findings
+
+Before editing, report to the user:
+
+1. **Commits analyzed**: total count and date range
+2. **Changes requiring README updates**: list each with category and what to add/modify
+3. **No-action commits**: briefly note what was skipped and why
+4. **Export mismatches**: any undocumented or stale exports found
+
+Wait for user confirmation before proceeding to edit.
+
+## Step 6: Update README
+
+Read the current README, then edit **only** the affected sections.
+
+**Rules:**
+- README content is written in **English**
+- **Preserve existing structure** — do not reorganize or rewrite unchanged sections
+- **Match style** — follow the same documentation depth, table format, and code example style as existing entries
+- For new APIs: include description, usage example, and parameter/option table if the existing style uses them
+- Remove documentation for APIs that no longer exist
+- Do not add version history, changelog, or "recently updated" sections

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

@@ -0,0 +1,93 @@
+---
+name: sd-review
+description: Use when performing a comprehensive code review of a package or path - uses sd-explore for code analysis in a forked context, then dispatches to specialized reviewer agents
+model: inherit
+---
+
+# sd-review
+
+## Overview
+
+Perform a multi-perspective code review of a package or specified path, producing a comprehensive report. **Analysis only — no code modifications.**
+
+Analyzes code via the `sd-explore` skill, then runs 3 subagents in parallel for specialized review. Collects subagent results, verifies each finding against actual code, and writes the final report.
+
+## Usage
+
+- `/sd-review packages/solid` — review source code at the given path
+- `/sd-review` — if no argument, ask the user for the target path
+
+## Target Selection
+
+1. If `$ARGUMENTS` contains a path, use that path
+2. Otherwise, ask the user for the target path
+
+**Important: the review scope is ALL source files under the target path.** Do not use git status or git diff to limit to changed files. Analyze every source file in the target path.
+
+## Reviewer Agents
+
+Run 3 subagents in parallel via the Task tool:
+
+| Agent Type           | Role |
+|----------------------|------|
+| `sd-code-reviewer`   | Bugs, security, logic errors, convention issues |
+| `sd-code-simplifier` | Complexity, duplication, readability issues |
+| `sd-api-reviewer`    | DX/usability, naming, type hints |
+
+## Workflow
+
+### Step 1: Code Analysis via sd-explore
+
+Invoke the `sd-explore` skill via the Skill tool to analyze the target path:
+
+```
+Skill: sd-explore
+Args: <target-path>
+```
+
+This runs in a **separate context**, so it does not consume the main context window. The analysis covers:
+
+- Feature Discovery: entry points, core files, module boundaries
+- Code Flow Tracing: call chains, data transformations, state changes
+- Architecture Analysis: abstraction layers, design patterns, dependency graph
+- Implementation Details: error handling, public API surface, performance
+
+### Step 2: Dispatch Analysis to Reviewers
+
+Run 3 subagents **in parallel** via the Task tool. Include the sd-explore analysis results in each subagent's prompt:
+
+- **sd-code-reviewer**: Based on the analysis, find bugs, security vulnerabilities, logic errors, and convention issues. Each finding must include **file:line** and **evidence**.
+- **sd-code-simplifier**: Based on the analysis, find unnecessary complexity, code duplication, and readability issues. Each finding must include **file:line** and **evidence**. **No code modifications.**
+- **sd-api-reviewer**: Based on the analysis, review API intuitiveness, naming consistency, type hints, error messages, and configuration complexity. Each finding must include **file:line** and **evidence**.
+
+### Step 3: Verify Issues
+
+After collecting results from all 3 subagents, verify each issue against the actual code:
+
+- **Valid**: the issue is real → include in the report
+- **Invalid — already handled**: handled elsewhere in the codebase (provide evidence)
+- **Invalid — intentional pattern**: by-design architectural decision
+- **Invalid — misread**: the reviewer misinterpreted the code
+
+### Step 4: Final Report
+
+Compile only **verified findings** into a comprehensive report.
+
+### Report Structure
+
+| Section | Priority | Source |
+|---------|----------|--------|
+| **Architecture Summary** | — | sd-explore analysis |
+| **Critical Issues** | P0 | Bugs, security vulnerabilities |
+| **Quality Issues** | P1 | Logic errors, missing error handling, performance |
+| **DX/Usability Issues** | P2 | API intuitiveness, naming, type hints |
+| **Simplification Opportunities** | P3 | Complexity removal, duplicate code, abstractions |
+| **Convention Issues** | P4 | Project convention mismatches |
+
+Each issue includes **file:line**, **description**, and **suggestion**.
+
+Optionally include an **Invalid Findings Summary** appendix showing which findings were filtered out and why.
+
+## Completion Criteria
+
+Present the comprehensive report to the user. No code modifications.