@simplysm/claude 13.0.0-beta.22

package/claude/skills/sd-plan-dev/spec-reviewer-prompt.md

@@ -0,0 +1,38 @@
+# Spec Compliance Reviewer Prompt
+
+Send the following as prompt to `Task(general-purpose)` (sub-Task launched by task agent).
+
+**Purpose:** Verify the implementation matches the spec exactly (nothing more, nothing less)
+
+```
+You are reviewing whether an implementation matches its specification.
+
+## What Was Requested
+
+[FULL TEXT of task requirements]
+
+## What Implementer Claims They Built
+
+[From implementer's report]
+
+## CRITICAL: Do Not Trust the Report
+
+Verify everything independently by reading the actual code.
+
+**DO NOT:** Take their word, trust their claims, accept their interpretation.
+
+**DO:** Read actual code, compare to requirements line by line, check for missing/extra pieces.
+
+## Verify
+
+**Missing requirements:** Did they implement everything? Did they skip anything?
+
+**Extra/unneeded work:** Did they build things not requested? Over-engineer?
+
+**Misunderstandings:** Did they interpret requirements differently? Solve wrong problem?
+
+## Report
+
+- ✅ Spec compliant (if everything matches after code inspection)
+- ❌ Issues found: [list specifically what's missing or extra, with file:line references]
+```

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

@@ -0,0 +1,131 @@
+---
+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> (optional - omit to update all)"
+model: haiku
+---
+
+# sd-readme
+
+Update README.md files based on git commits since their last modification.
+
+## Step 0: Check for Batch Mode
+
+If `$ARGUMENTS` is **empty or blank**:
+
+1. Use `Glob` with pattern `packages/*/package.json` to discover all packages.
+2. Launch **parallel subagents** via the `Task` tool (`subagent_type: "general-purpose"`, `model: "haiku"`):
+   - One subagent for **project root README.md** with prompt:
+     ```
+     Update the project root README.md at /home/kslhunter/projects/simplysm/README.md based on recent git changes.
+     - Run: git log -1 --format="%H %ai %s" -- README.md
+     - If no output, treat all commits as relevant: git log --oneline -30
+     - Otherwise: git log <hash>..HEAD --oneline
+     - If no commits since last update, report "already up to date" and stop.
+     - Read the current README.md, read CLAUDE.md for project context, then edit only affected sections.
+     - README content must be in English.
+     - Preserve existing structure. Match existing style. Do not add changelog sections.
+     ```
+   - One subagent **per package** with prompt:
+     ```
+     Update the README.md for package <pkg-name> at <pkg-path>/README.md based on recent git changes.
+     Follow these steps:
+     1. Run: git log -1 --format="%H %ai %s" -- <pkg-path>/README.md
+     2. If no output, all commits are relevant: git log --oneline -- <pkg-path>/
+        Otherwise: git log <hash>..HEAD --oneline -- <pkg-path>/
+     3. If no commits since last update, report "already up to date" and stop.
+     4. Read <pkg-path>/src/index.ts to verify all public exports are documented.
+     5. Read the current README.md, then edit only affected sections.
+     6. README content must be in English.
+     7. Preserve existing structure. Match existing style. Do not add changelog sections.
+     8. If README.md does not exist, create it following the style of other package READMEs in this repo.
+     ```
+3. Collect all subagent results and **report a summary** to the user: which READMEs were updated, which were already up to date.
+4. **Stop here** — do not proceed to the single-package steps below.
+
+---
+
+## Step 1: Resolve Package Path (Single Package Mode)
+
+`$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.