@simplysm/sd-claude 13.0.75 → 13.0.77

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

@@ -1,7 +1,6 @@
 ---
 name: sd-check
 description: "Typecheck, lint, test verification (explicit invocation only)"
-allowed-tools: Bash(npm run check:*), Bash(pnpm run check:*), Bash(yarn run check:*), Bash(npm run typecheck:*), Bash(pnpm run typecheck:*), Bash(yarn run typecheck:*), Bash(npm run lint:*), Bash(pnpm run lint:*), Bash(yarn run lint:*), Bash(npm run vitest:*), Bash(pnpm run vitest:*), Bash(yarn run vitest:*)
 ---
 
 # sd-check
@@ -34,19 +33,34 @@ Multiple types: `--type typecheck,lint`. No path = full project. No type = all c
 
 ## Workflow
 
-1. **Run** `$PM run check [path] [--type type]` (timeout: 600000)
-2. **All passed?** Report with actual output numbers → done
-3. **Errors?** Fix in priority order: typecheck → lint → test (fixes cascade)
-   - Test failures: **MUST** run `git log` to decide — update test or fix source
-   - **E2E test failures**: use Playwright MCP to investigate before fixing
-     1. `browser_navigate` to the target URL
-     2. `browser_snapshot` / `browser_take_screenshot` (save to `.tmp/playwright/`) to see page state
-     3. `browser_console_messages` for JS errors
-     4. `browser_network_requests` for failed API calls
-     5. Interact with the page following the test steps to reproduce the failure
-     6. Fix based on observed evidence, not guesswork
-   - Stuck after 2-3 attempts → recommend `/sd-debug`
-4. **Go to 1** — always re-run ALL checks after any fix
+```mermaid
+flowchart TD
+    A[Run check] --> B{All passed?}
+    B -->|yes| C[Report results → done]
+    B -->|no| D["Fix errors (typecheck → lint → test)"]
+    D --> E{Stuck after 2-3 tries?}
+    E -->|no| A
+    E -->|yes| F[Recommend /sd-debug]
+```
+
+**Run command:** `$PM run check [path] [--type type]` (timeout: 600000)
+
+- **Output capture:** Bash truncates long output. Always redirect to a file and read it:
+  ```bash
+  mkdir -p .tmp && $PM run check [path] [--type type] > .tmp/check-output.txt 2>&1; echo "EXIT:$?"
+  ```
+  Then use the **Read** tool on `.tmp/check-output.txt` to see the full result. Check `EXIT:0` for success or non-zero for failure.
+
+**Fixing errors:**
+- **Before fixing any code**: Read `.claude/refs/sd-code-conventions.md` and check `.claude/rules/sd-refs-linker.md` for additional refs relevant to the affected code area (e.g., `sd-solid.md` for SolidJS, `sd-orm.md` for ORM). Fixing errors does NOT exempt you from following project conventions.
+- Test failures: **MUST** run `git log` to decide — update test or fix source
+- **E2E test failures**: use Playwright MCP to investigate before fixing
+  1. `browser_navigate` to the target URL
+  2. `browser_snapshot` / `browser_take_screenshot` (save to `.tmp/playwright/`) to see page state
+  3. `browser_console_messages` for JS errors
+  4. `browser_network_requests` for failed API calls
+  5. Interact with the page following the test steps to reproduce the failure
+  6. Fix based on observed evidence, not guesswork
 
 ## Rules
 

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

@@ -2,7 +2,6 @@
 name: sd-commit
 description: "Git commit with conventional messages (explicit invocation only)"
 argument-hint: "[all]"
-allowed-tools: Bash(git status:*), Bash(git add:*), Bash(git commit:*)
 model: haiku
 ---
 
@@ -50,7 +49,7 @@ type(scope): short description
 | ------------- | ---------------------------------------------------------------------------- |
 | `type`        | `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `build`, `style`, `perf` |
 | `scope`       | package name or area (e.g., `solid`, `core-common`, `orm-node`)              |
-| `description` | written in the system's configured language, imperative, lowercase, no period at end |
+| `description` | English, imperative, lowercase, no period at end |
 
 Examples:
 
@@ -58,8 +57,6 @@ Examples:
 - `fix(orm-node): handle null values in bulk insert`
 - `docs: update README with new API examples`
 
-> **Note:** The examples above are in English for reference only. The actual description MUST be written in the system's configured language.
-
 Use a HEREDOC for multi-line messages when needed.
 
 ## Execution

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

@@ -196,25 +196,20 @@ You MUST complete each phase before proceeding to the next.
    - Issue actually resolved?
 
 4. **If Fix Doesn't Work**
-   - STOP
-   - Count: How many fixes have you tried?
-   - If < 3: Return to Phase 1, re-analyze with new information
-   - **If ≥ 3: STOP and question the architecture (step 5 below)**
-   - DON'T attempt Fix #4 without architectural discussion
 
-5. **If 3+ Fixes Failed: Question Architecture**
+   ```mermaid
+   flowchart TD
+       A{"Fix failed?"} --> B{"Attempts < 3?"}
+       B -->|yes| C["Phase 1: Re-analyze<br>with new information"]
+       B -->|"no (≥3)"| D["STOP: Question Architecture<br>→ Discuss with user first"]
+   ```
 
-   **Pattern indicating architectural problem:**
+   **Signs of architectural problem (≥3 failures):**
    - Each fix reveals new shared state/coupling/problem in different place
    - Fixes require "massive refactoring" to implement
    - Each fix creates new symptoms elsewhere
 
-   **STOP and question fundamentals:**
-   - Is this pattern fundamentally sound?
-   - Are we "sticking with it through sheer inertia"?
-   - Should we refactor architecture vs. continue fixing symptoms?
-
-   **Discuss with the user before attempting more fixes**
+   **Question fundamentals:** Is this pattern sound? Are we sticking with it through inertia? Should we refactor architecture vs. continue fixing symptoms?
 
    This is NOT a failed hypothesis - this is a wrong architecture.
 

package/claude/skills/sd-debug/condition-based-waiting.md

@@ -8,17 +8,11 @@ Flaky tests often guess at timing with arbitrary delays. This creates race condi
 
 ## When to Use
 
-```dot
-digraph when_to_use {
-    "Test uses setTimeout/sleep?" [shape=diamond];
-    "Testing timing behavior?" [shape=diamond];
-    "Document WHY timeout needed" [shape=box];
-    "Use condition-based waiting" [shape=box];
-
-    "Test uses setTimeout/sleep?" -> "Testing timing behavior?" [label="yes"];
-    "Testing timing behavior?" -> "Document WHY timeout needed" [label="yes"];
-    "Testing timing behavior?" -> "Use condition-based waiting" [label="no"];
-}
+```mermaid
+flowchart TD
+    A{"Test uses setTimeout/sleep?"} -->|yes| B{"Testing timing behavior?"}
+    B -->|yes| C[Document WHY timeout needed]
+    B -->|no| D[Use condition-based waiting]
 ```
 
 **Use when:**

package/claude/skills/sd-debug/root-cause-tracing.md

@@ -8,19 +8,12 @@ Bugs often manifest deep in the call stack (git init in wrong directory, file cr
 
 ## When to Use
 
-```dot
-digraph when_to_use {
-    "Bug appears deep in stack?" [shape=diamond];
-    "Can trace backwards?" [shape=diamond];
-    "Fix at symptom point" [shape=box];
-    "Trace to original trigger" [shape=box];
-    "BETTER: Also add defense-in-depth" [shape=box];
-
-    "Bug appears deep in stack?" -> "Can trace backwards?" [label="yes"];
-    "Can trace backwards?" -> "Trace to original trigger" [label="yes"];
-    "Can trace backwards?" -> "Fix at symptom point" [label="no - dead end"];
-    "Trace to original trigger" -> "BETTER: Also add defense-in-depth";
-}
+```mermaid
+flowchart TD
+    A{"Bug appears deep in stack?"} -->|yes| B{"Can trace backwards?"}
+    B -->|yes| C[Trace to original trigger]
+    B -->|"no - dead end"| D[Fix at symptom point]
+    C --> E["BETTER: Also add defense-in-depth"]
 ```
 
 **Use when:**
@@ -142,26 +135,18 @@ Runs tests one-by-one, stops at first polluter. See script for usage.
 
 ## Key Principle
 
-```dot
-digraph principle {
-    "Found immediate cause" [shape=ellipse];
-    "Can trace one level up?" [shape=diamond];
-    "Trace backwards" [shape=box];
-    "Is this the source?" [shape=diamond];
-    "Fix at source" [shape=box];
-    "Add validation at each layer" [shape=box];
-    "Bug impossible" [shape=doublecircle];
-    "NEVER fix just the symptom" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
-
-    "Found immediate cause" -> "Can trace one level up?";
-    "Can trace one level up?" -> "Trace backwards" [label="yes"];
-    "Can trace one level up?" -> "NEVER fix just the symptom" [label="no"];
-    "Trace backwards" -> "Is this the source?";
-    "Is this the source?" -> "Trace backwards" [label="no - keeps going"];
-    "Is this the source?" -> "Fix at source" [label="yes"];
-    "Fix at source" -> "Add validation at each layer";
-    "Add validation at each layer" -> "Bug impossible";
-}
+```mermaid
+flowchart TD
+    A(["Found immediate cause"]) --> B{"Can trace one level up?"}
+    B -->|yes| C["Trace backwards"]
+    B -->|no| D["NEVER fix just the symptom"]:::danger
+    C --> E{"Is this the source?"}
+    E -->|"no - keeps going"| C
+    E -->|yes| F["Fix at source"]
+    F --> G["Add validation at each layer"]
+    G --> H(("Bug impossible"))
+
+    classDef danger fill:#f00,color:#fff
 ```
 
 **NEVER fix just where the error appears.** Trace back to find the original trigger.

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

@@ -0,0 +1,118 @@
+---
+name: sd-explore
+description: "Use when analyzing a large codebase (30+ files) that must be read comprehensively. Splits files into groups and dispatches parallel sub-agents to avoid context compaction and information loss."
+---
+
+# sd-explore
+
+## Overview
+
+Split a large codebase into manageable groups and dispatch parallel sub-agents, each reading its assigned files and writing results to disk. The calling skill then reads result files instead of raw source — no context compaction, no information loss.
+
+**Core principle:** Never read 30+ files in a single agent context. Split, parallelize, write to files.
+
+**Important:** This is a workflow the **orchestrator (main agent)** follows directly. Do NOT delegate the entire sd-explore workflow to a sub-agent — only the orchestrator has `Agent` tool access to dispatch parallel sub-agents. The orchestrator globs files, splits groups, and dispatches `Agent(Explore)` calls itself.
+
+## When to Use
+
+- Codebase analysis covering 30+ source files
+- Called by other skills (sd-review, sd-brainstorm, sd-debug, sd-plan) that need comprehensive file reading
+- Any task where reading all files sequentially would risk context compaction
+
+**When NOT to use:**
+- < 30 files — a single agent can handle it directly
+- Targeted search for a specific function/class — use Grep/Glob instead
+
+## Input
+
+The calling skill provides:
+
+1. **Target path** — directory to explore (e.g., `packages/solid/src`)
+2. **Name** — caller identifier for output filenames (e.g., `review`, `debug`, `brainstorm`)
+3. **File patterns** — glob patterns to match (default: `**/*.ts`, `**/*.tsx`; exclude `node_modules`, `dist`)
+4. **Analysis instructions** — free-form text describing what each sub-agent should do
+
+The analysis instructions are passed verbatim to each sub-agent. They can request anything: tags, summaries, pattern searches, specific questions, etc.
+
+## Workflow
+
+### Step 1: Discover Files
+
+Glob all matching files under the target path.
+
+- **< 30 files**: Run a single `Agent(subagent_type=Explore)` with the analysis instructions. No splitting needed. Write result to `.tmp/explore/{dt}_{name}.md` (where `{dt}` is current datetime as `yyyyMMddHHmmss`).
+- **>= 30 files**: Proceed to Step 2.
+
+### Step 2: Split Into Groups
+
+Split files into groups of **~30 files each**.
+
+**Splitting strategy:**
+
+1. List all subdirectories under target
+2. Group files by subdirectory, keeping each group around 30 files
+3. If the target is mostly flat (few subdirectories), group by file proximity (alphabetical chunks)
+4. Adjacent small directories can be merged into one group
+5. A single large directory (40+ files) should be split into multiple groups
+
+**Goal:** Balanced groups where related files stay together.
+
+### Step 3: Dispatch Parallel Agents
+
+Launch one `Agent(subagent_type=Explore)` per group, **all in a single message** for true parallelism.
+
+Each agent receives:
+
+```
+You are exploring a section of a codebase. Read ALL assigned files and write your analysis to the output file.
+
+**Assigned files:**
+[list of file paths for this group]
+
+**Analysis instructions:**
+[caller's free-form instructions, passed verbatim]
+
+**Output file:** .tmp/explore/{dt}_{name}-{group_index}.md
+
+Read every assigned file. Write your complete analysis to the output file. Do NOT skip files.
+```
+
+### Step 4: Return Result Paths
+
+After all agents complete, return the list of output file paths to the calling skill.
+
+The calling skill reads these files to get the analysis results — the main context stays clean.
+
+## Output Format
+
+Each sub-agent writes to its assigned output file. The format is determined by the caller's analysis instructions. If no specific format is requested, use:
+
+```markdown
+# Explore: [directory names]
+
+## File Summaries
+- `path/to/file.ts` — Brief description
+
+## Analysis
+[Results per the caller's instructions]
+```
+
+## Why Sub-Agents Matter
+
+The value is **context isolation**, not just speed:
+
+- **Without sub-agents**: Reading 100+ files in the main context causes compaction. Earlier file analyses get dropped, degrading quality of later analysis steps (review, planning, etc.)
+- **With sub-agents**: Each sub-agent reads ~30 files in its own context, writes results to disk, and exits. The main context only reads the summary files — staying clean for subsequent work.
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Delegating the entire workflow to a sub-agent | The orchestrator follows sd-explore directly — only it can dispatch parallel `Agent` calls |
+| Reading all files in one agent | Split into groups of ~30, dispatch parallel agents |
+| Not writing results to files | Each agent MUST write to its output file — this is what prevents context bloat |
+| Groups too large (50+) | Keep groups around 30 files for reliable coverage |
+| Groups too small (5-10) | Wastes agent overhead — merge small directories |
+| Not passing analysis instructions verbatim | The caller's instructions go to each agent as-is |
+| Running agents sequentially | Launch all agents in a single message for parallelism |
+| Skipping Step 1 threshold check | < 30 files don't need splitting — avoid unnecessary overhead |

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

@@ -18,6 +18,8 @@ Write comprehensive implementation plans assuming the engineer has zero context
 
 Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
 
+When a task uses a codebase-specific utility (hook, helper, style token) or test pattern, add a one-line explanation of what it does and the source file path. Example: "`createMountTransition(open)` — manages mount/unmount with CSS transitions (`packages/solid/src/hooks/createMountTransition.ts`)". This applies to test utilities and patterns too — if a test uses a framework-specific pattern (e.g., SolidJS `createRoot` for reactive context), explain why that pattern is needed.
+
 **Announce at start:** "I'm using the sd-plan skill to create the implementation plan."
 
 **Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
@@ -31,6 +33,18 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
 - "Run the tests and make sure they pass" - step
 - "Commit" - step
 
+**Step size limit:** If a single step produces more than ~30 lines of code, it is too large. Split it into multiple steps (e.g., "Define types and interfaces" → "Create context and hook" → "Implement provider component").
+
+**TDD means YAGNI per step:** Step 3 ("Write minimal implementation") must implement ONLY what's needed to pass Step 1's test — nothing more. If the component needs additional behavior (e.g., FIFO eviction, remove), that behavior goes in a SUBSEQUENT task with its own failing test first. Do NOT implement the full component in one task and then test it after the fact.
+
+## Task Ordering
+
+**Shared resources BEFORE consumers.** Tasks must be ordered so that every file a task imports already exists from a prior task.
+
+- Types, config, i18n entries → before components that use them
+- Provider → before components that call useX() hooks
+- If Task B imports from Task A's file → Task A must come first
+
 ## Plan Document Header
 
 **Every plan MUST start with this header:**
@@ -103,12 +117,29 @@ git commit -m "feat: add specific feature"
 ```
 ```
 
+## Test Requirement
+
+**Every task that creates or modifies logic MUST include a test.** No exceptions.
+
+- If the logic is testable with unit tests → write a vitest test file. This includes: pure functions, state management, timers/lifecycle logic (use `vi.useFakeTimers()`), event handlers, and state transitions.
+- If the logic is UI-only (visual rendering, Portal placement, CSS animation) → include a manual verification step with exact instructions ("Open the browser, click X, expect Y")
+- The **Files:** section must list the test file: `Test: exact/path/to/tests/file.spec.ts`
+- If you find yourself writing a task with no test step → **STOP and add one**
+
 ## Remember
 - Exact file paths always
+- Cross-check the design document's file structure — every file listed in the design MUST appear in the plan (create or modify)
 - Complete code in plan (not "add validation")
+- When modifying an existing file, show ALL necessary import additions/changes — not just the appended code
+- Code must compile cleanly — no unused imports or variables
 - Exact commands with expected output
 - DRY, YAGNI, TDD, frequent commits
 
+## Related Skills
+
+- **sd-brainstorm** — prerequisite: creates the design this skill plans from
+- **sd-plan-dev** — executes the plan this skill creates
+
 ## Execution Handoff
 
 After saving the plan, **commit the plan document to git** before proceeding.

package/claude/skills/sd-plan-dev/SKILL.md

@@ -11,15 +11,11 @@ Execute plan tasks via parallel implementers with dependency-aware scheduling.
 
 ## When to Use
 
-```dot
-digraph when_to_use {
-    "Have implementation plan?" [shape=diamond];
-    "sd-plan-dev" [shape=box];
-    "Manual execution or brainstorm first" [shape=box];
-
-    "Have implementation plan?" -> "sd-plan-dev" [label="yes"];
-    "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
-}
+```mermaid
+flowchart TD
+    A{Have implementation plan?}
+    A -->|yes| B[sd-plan-dev]
+    A -->|no| C[Manual execution or brainstorm first]
 ```
 
 ## Execution Method
@@ -37,75 +33,53 @@ All execution uses `Task(general-purpose)` for parallel execution.
 
 Independent tasks run as **parallel Task calls in a single message**. After implementers complete, spec and quality reviews run as **parallel Task calls**.
 
-**CRITICAL: Do NOT use `run_in_background: true`** — achieve parallelism by making multiple Task calls in a single message (foreground parallel). This ensures the orchestrator waits for all tasks to complete before proceeding to the next batch, and prevents Stop hooks from firing prematurely.
+**CRITICAL: Always launch parallel tasks as multiple Task calls in a single message (foreground parallel).** Never set `run_in_background: true` — it causes Stop hooks to fire prematurely. This rule applies regardless of permission mode (yolo, plan, etc.).
 
 ## The Process
 
-```dot
-digraph process {
-    rankdir=TB;
-
-    "Read plan, extract tasks, create TaskCreate" [shape=box];
-    "Dependency analysis: identify files per task, build graph, group into batches" [shape=box];
-
-    subgraph cluster_batch {
-        label="Per Batch (independent tasks)";
-
-        subgraph cluster_parallel_implementers {
-            label="Parallel implementer Task calls (single message)";
-            style=dashed;
-
-            subgraph cluster_implementer {
-                label="Each Implementer";
-                "Implement the task" [shape=box];
-                "Questions?" [shape=diamond];
-                "Return questions to orchestrator" [shape=box];
-                "Re-launch with answers" [shape=box];
-                "Commit and report" [shape=box];
-            }
-        }
-
-        subgraph cluster_review {
-            label="Orchestrator review loop (per implementer)";
-
-            subgraph cluster_parallel_reviewers {
-                label="Parallel reviewer Task calls (single message)";
-                style=dashed;
-                "Task: spec reviewer" [shape=box];
-                "Task: quality reviewer" [shape=box];
-            }
-
-            "Any issues?" [shape=diamond];
-            "Task: implementer fix" [shape=box];
-            "Re-review (parallel Task calls)" [shape=box];
-        }
-    }
-
-    "More batches?" [shape=diamond];
-    "Batch integration check (typecheck + lint)" [shape=box];
-    "Task: final review for entire implementation" [shape=box];
-    "Done" [shape=ellipse];
-
-    "Read plan, extract tasks, create TaskCreate" -> "Dependency analysis: identify files per task, build graph, group into batches";
-    "Dependency analysis: identify files per task, build graph, group into batches" -> "Implement the task";
-    "Implement the task" -> "Questions?";
-    "Questions?" -> "Return questions to orchestrator" [label="yes"];
-    "Return questions to orchestrator" -> "Re-launch with answers";
-    "Re-launch with answers" -> "Implement the task";
-    "Questions?" -> "Commit and report" [label="no"];
-    "Commit and report" -> "Task: spec reviewer";
-    "Commit and report" -> "Task: quality reviewer";
-    "Task: spec reviewer" -> "Any issues?";
-    "Task: quality reviewer" -> "Any issues?";
-    "Any issues?" -> "Task: implementer fix" [label="yes"];
-    "Task: implementer fix" -> "Re-review (parallel Task calls)";
-    "Re-review (parallel Task calls)" -> "Any issues?";
-    "Any issues?" -> "Batch integration check (typecheck + lint)" [label="no"];
-    "Batch integration check (typecheck + lint)" -> "More batches?";
-    "More batches?" -> "Implement the task" [label="yes, next batch"];
-    "More batches?" -> "Task: final review for entire implementation" [label="no"];
-    "Task: final review for entire implementation" -> "Done";
-}
+```mermaid
+flowchart TD
+    A["Read plan, extract tasks, create TaskCreate"] --> B["Dependency analysis: identify files per task, build graph, group into batches"]
+
+    subgraph BATCH["Per Batch (independent tasks)"]
+        subgraph PAR_IMPL["Parallel implementer Task calls (single message)"]
+            subgraph IMPL["Each Implementer"]
+                C["Implement the task"] --> D{"Questions?"}
+                D -->|yes| E["Return questions to orchestrator"]
+                E --> F["Re-launch with answers"]
+                F --> C
+                D -->|no| G["Commit and report"]
+            end
+        end
+
+        subgraph REVIEW["Orchestrator review loop (per implementer)"]
+            subgraph PAR_REV["Parallel reviewer Task calls (single message)"]
+                H["Task: spec reviewer"]
+                I["Task: quality reviewer"]
+            end
+            J{"Any issues?"}
+            K["Task: implementer fix"]
+            L["Re-review (parallel Task calls)"]
+        end
+    end
+
+    B --> C
+    G --> H
+    G --> I
+    H --> J
+    I --> J
+    J -->|yes| K
+    K --> L
+    L --> J
+    J -->|no| M["Batch integration check (typecheck + lint)"]
+    M --> N{"More batches?"}
+    N -->|"yes, next batch"| C
+    N -->|no| O["Task: final review for entire implementation"]
+    O --> P["Run /simplify on all changed code"]
+    P --> Q{"Changes made?"}
+    Q -->|yes| R["Typecheck + lint affected packages"]
+    R --> S(["Done"])
+    Q -->|no| S
 ```
 
 ## Dependency Analysis
@@ -216,9 +190,18 @@ You: Using sd-plan-dev to execute this plan.
 [Task: final review for entire implementation]
 Final reviewer: All requirements met, ready to merge
 
+[Run /simplify on all changed code]
+Simplify: extracted shared validation helper, removed 2 duplicate imports
+[typecheck + lint → pass]
+[Commit: refactor: simplify changed code]
+
 Done!
 ```
 
+## Verification-Only Tasks
+
+If a task is purely verification (no code changes — just running tests, typecheck, or manual checks), merge its checks into the batch integration check or final review rather than dispatching an implementer. These tasks exist in the plan for documentation purposes but don't need the full implementer → reviewer cycle.
+
 ## Batch Integration Check
 
 Between batches, run targeted verification on affected packages before starting the next batch.
@@ -232,6 +215,39 @@ $PM run lint [affected packages]
 
 This catches cross-task integration issues early — especially when the next batch depends on the current batch's output. Do NOT skip this even if individual task reviews passed.
 
+If typecheck or lint fails, treat the errors as review issues: re-dispatch the implementer(s) whose changes caused the failure with the error output. After fix, re-run the integration check. Do NOT start the next batch until integration passes.
+
+## Final Review Dispatch
+
+After all batches complete and pass integration checks, dispatch the final reviewer:
+
+1. Locate the original design document from `docs/plans/` — it shares the same date and topic as the plan file (e.g., plan `2026-03-04-dialog-confirm.md` → design `2026-03-04-dialog-confirm-design.md`)
+2. Fill `./final-review-prompt.md` with:
+   - The full text of the original design document
+   - The full text of the implementation plan
+   - Summaries of all completed tasks (commit SHAs, files changed, test results)
+3. Dispatch as `Task(general-purpose)`
+4. If the final reviewer returns **APPROVED** → done
+5. If the final reviewer returns **ISSUES**:
+   - For cross-task integration issues: create a fix task targeting specific files, run through implementer → review cycle
+   - For missing design requirements: create new implementation tasks and run through the full batch cycle
+   - Re-run final review after all fixes
+
+## Simplify
+
+After the final review passes, run `/simplify` to review all changed code for reuse, quality, and efficiency. This catches cross-task cleanup opportunities that individual reviewers miss.
+
+1. Orchestrator runs `/simplify` via the Skill tool
+2. If simplify made changes:
+   - Run typecheck/lint on affected packages
+   - If typecheck/lint fails → fix the issues and re-run typecheck/lint until it passes
+   - Commit simplify changes as a separate commit (`refactor: simplify changed code`)
+3. If simplify made no changes → skip to completion
+
+## Completion
+
+After simplify completes (or is skipped), report to the user: number of tasks completed, total files changed, and final review outcome.
+
 ## Red Flags
 
 **Never:**
@@ -246,6 +262,7 @@ This catches cross-task integration issues early — especially when the next ba
 - Accept "close enough" on spec compliance
 - Skip review loops (issue found → fix → re-review)
 - Skip batch integration checks between batches
+- Skip `/simplify` after final review
 - Use `run_in_background: true` on Task calls (use foreground parallel instead)
 
 **If implementer returns questions:**

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

@@ -13,11 +13,9 @@ You are reviewing code quality for a completed implementation.
 ## Review Scope
 
 Use git diff to review only what changed:
-```
 
-git diff [BASE_SHA]..[HEAD_SHA]
+    git diff [BASE_SHA]..[HEAD_SHA]
 
-```
 BASE_SHA: [commit before task started]
 HEAD_SHA: [implementer's commit SHA from report]
 

package/claude/skills/sd-plan-dev/implementer-prompt.md

@@ -20,12 +20,20 @@ You are implementing Task [N]: [task name]
 
 If anything is unclear about requirements or approach, return your questions under a `## Questions` heading and STOP. Do not guess — do not implement.
 
+## Plan Deviations
+
+Plans may contain minor inaccuracies (wrong file paths, outdated API signatures, incorrect line numbers). Handle deviations by severity:
+
+- **Minor** (file path renamed, import path different, line numbers shifted): Adapt to the actual codebase and note the deviation in your report.
+- **Major** (API doesn't exist, approach fundamentally different, missing dependency): Return your questions under `## Questions` and STOP.
+
 ## While You Work
 
 If you encounter something unexpected mid-implementation (missing APIs, unexpected patterns, ambiguous behavior), **ask questions rather than guess**. Return your questions under `## Questions` and STOP. It's always OK to pause and clarify.
 
 ## Your Job
 
+0. **Before writing any code**: Read `.claude/refs/sd-code-conventions.md` and check `.claude/rules/sd-refs-linker.md` for additional refs relevant to the code you'll touch (e.g., `sd-solid.md` for SolidJS, `sd-orm.md` for ORM). Follow all project conventions — implementing a task does NOT exempt you from conventions.
 1. Implement exactly what the task specifies — nothing more, nothing less
 2. Write tests (follow TDD if the plan says to)
 3. Verify: tests pass, no type errors
@@ -35,7 +43,7 @@ If you encounter something unexpected mid-implementation (missing APIs, unexpect
    - **Discipline**: Nothing overbuilt (YAGNI)? Only what was requested?
    - **Testing**: Tests verify behavior (not implementation)? Comprehensive?
 5. Fix anything found in self-review
-6. Commit your work with a descriptive message (this is required for review)
+6. Commit using conventional commit format: `type(scope): description` (e.g., `feat(solid): add ConfirmDialog component`)
 7. Report back
 
 Work from: [directory path]
@@ -45,6 +53,7 @@ Work from: [directory path]
 When done, provide:
 - Commit SHA (from step 6)
 - Files created/modified (with brief description of changes)
+- Plan deviations (if any — what the plan said vs. what you did and why)
 - Test results
 - Self-review findings (if any were fixed)
 - Open concerns (if any)