@simplysm/sd-claude 13.0.37 → 13.0.39

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

@@ -1,6 +1,7 @@
 ---
 name: sd-check
 description: Use when verifying code quality via typecheck, lint, and tests - before deployment, PR creation, after code changes, or when type errors, lint violations, or test failures are suspected. Applies to whole project or specific paths.
+allowed-tools: Bash(node .claude/skills/sd-check/env-check.mjs), Bash(pnpm typecheck), Bash(pnpm lint --fix), Bash(pnpm vitest), Bash(pnpm lint:fix)
 ---
 
 # sd-check
@@ -16,7 +17,7 @@ Verify code quality through parallel execution of typecheck, lint, and test chec
 When the user asks to verify code, YOU will manually execute **EXACTLY THESE 4 STEPS** (no more, no less):
 
 **Step 1:** Environment Pre-check (4 checks in parallel)
-**Step 2:** Launch 3 haiku agents in parallel (typecheck, lint, test ONLY)
+**Step 2:** Launch 3 background Bash commands in parallel (typecheck, lint, test ONLY)
 **Step 3:** Collect results, fix errors in priority order
 **Step 4:** Re-verify (go back to Step 2) until all pass
 
@@ -36,13 +37,13 @@ When the user asks to verify code, YOU will manually execute **EXACTLY THESE 4 S
 
 ## Quick Reference
 
-| Check | Command | Agent Model | Purpose |
-|-------|---------|-------------|---------|
-| Typecheck | `pnpm typecheck [path]` | haiku | Type errors |
-| Lint | `pnpm lint --fix [path]` | haiku | Code quality |
-| Test | `pnpm vitest [path] --run` | haiku | Functionality |
+| Check | Command | Purpose |
+|-------|---------|---------|
+| Typecheck | `pnpm typecheck [path]` | Type errors |
+| Lint | `pnpm lint --fix [path]` | Code quality |
+| Test | `pnpm vitest [path] --run` | Functionality |
 
-**All 3 run in PARALLEL** (separate haiku agents, single message)
+**All 3 run in PARALLEL** (background Bash commands, single message)
 
 ## Workflow
 
@@ -59,42 +60,44 @@ node .claude/skills/sd-check/env-check.mjs
 
 The script checks: package.json version (v13), pnpm workspace files, typecheck/lint scripts, vitest config.
 
-### Step 2: Launch 3 Haiku Agents in Parallel
+### Step 2: Launch 3 Background Bash Commands in Parallel
 
-Launch ALL 3 agents in a **single message** using Task tool.
+Launch ALL 3 commands in a **single message** using Bash tool with `run_in_background: true`.
 
 **Replace `[path]` with user's argument, or OMIT if no argument (defaults to full project).**
 
-**Agent 1 - Typecheck:**
+**Command 1 - Typecheck:**
 ```
-Task tool:
-  subagent_type: Bash
-  model: haiku
+Bash tool:
+  command: "pnpm typecheck [path]"
   description: "Run typecheck"
-  prompt: "Run `pnpm typecheck [path]` and return full output. Do NOT analyze or fix - just report raw output."
+  run_in_background: true
+  timeout: 300000
 ```
 
-**Agent 2 - Lint:**
+**Command 2 - Lint:**
 ```
-Task tool:
-  subagent_type: Bash
-  model: haiku
+Bash tool:
+  command: "pnpm lint --fix [path]"
   description: "Run lint with auto-fix"
-  prompt: "Run `pnpm lint --fix [path]` and return full output. Do NOT analyze or fix - just report raw output."
+  run_in_background: true
+  timeout: 300000
 ```
 
-**Agent 3 - Test:**
+**Command 3 - Test:**
 ```
-Task tool:
-  subagent_type: Bash
-  model: haiku
+Bash tool:
+  command: "pnpm vitest [path] --run"
   description: "Run tests"
-  prompt: "Run `pnpm vitest [path] --run` and return full output. Do NOT analyze or fix - just report raw output."
+  run_in_background: true
+  timeout: 300000
 ```
 
+Each command returns a `task_id`. Use `TaskOutput` tool to collect results (with `block: true`).
+
 ### Step 3: Collect Results and Fix Errors
 
-Wait for ALL 3 agents. Collect outputs.
+Collect ALL 3 outputs using `TaskOutput` tool (with `block: true, timeout: 300000`) in a **single message** (parallel calls).
 
 **If all checks passed:** Complete (see Completion Criteria).
 
@@ -120,7 +123,7 @@ Wait for ALL 3 agents. Collect outputs.
 
 **CRITICAL:** After ANY fix, re-run ALL 3 checks.
 
-Go back to Step 2 and launch 3 haiku agents again.
+Go back to Step 2 and launch 3 background Bash commands again.
 
 **Do NOT assume:** "I only fixed typecheck → skip lint/test". Fixes cascade.
 
@@ -129,20 +132,20 @@ Repeat Steps 2-4 until all 3 checks pass.
 ## Common Mistakes
 
 ### ❌ Running checks sequentially
-**Wrong:** Launch agent 1, wait → agent 2, wait → agent 3
-**Right:** Launch ALL 3 in single message (parallel Task calls)
+**Wrong:** Launch command 1, wait → command 2, wait → command 3
+**Right:** Launch ALL 3 in single message (parallel background Bash calls)
 
 ### ❌ Fixing before collecting all results
-**Wrong:** Agent 1 returns error → fix immediately → re-verify
+**Wrong:** Command 1 returns error → fix immediately → re-verify
 **Right:** Wait for all 3 → collect all errors → fix in priority order → re-verify
 
 ### ❌ Skipping re-verification after fixes
 **Wrong:** Fix typecheck → assume lint/test still pass
 **Right:** ALWAYS re-run all 3 checks after any fix
 
-### ❌ Using wrong model
-**Wrong:** `model: opus` or `model: sonnet` for verification agents
-**Right:** `model: haiku` (cheaper, faster for command execution)
+### ❌ Using agents instead of background Bash
+**Wrong:** Launch haiku/sonnet/opus agents via Task tool to run commands
+**Right:** Use `Bash` with `run_in_background: true` (no model overhead)
 
 ### ❌ Including build/dev steps
 **Wrong:** Run `pnpm build` or `pnpm dev` as part of verification
@@ -162,11 +165,12 @@ If you find yourself doing ANY of these, you're violating the skill:
 
 - Treating sd-check as a command to invoke (`Skill: sd-check Args: ...`)
 - Including build or dev server in verification
-- Running agents sequentially instead of parallel
+- Running commands sequentially instead of parallel
+- Using Task/agent instead of background Bash
 - Not re-verifying after every fix
 - Asking user for path when none provided
 - Continuing past 2-3 failed fix attempts without recommending `/sd-debug`
-- Spawning 4+ agents (only 3: typecheck, lint, test)
+- Spawning 4+ commands (only 3: typecheck, lint, test)
 
 **All of these violate the skill's core principles. Go back to Step 1 and follow the workflow exactly.**
 
@@ -187,12 +191,12 @@ If you find yourself doing ANY of these, you're violating the skill:
 |--------|---------|
 | "I'm following the spirit, not the letter" | Violating the letter IS violating the spirit - follow EXACTLY |
 | "I'll create a better workflow with teams/tasks" | Follow the 4 steps EXACTLY - no teams, no task lists |
-| "I'll split tests into multiple agents" | Only 3 agents total: typecheck, lint, test |
-| "Stratified parallel is faster" | Run ALL 3 in parallel via separate agents - truly parallel |
+| "I'll split tests into multiple commands" | Only 3 commands total: typecheck, lint, test |
+| "Agents can analyze output better" | Background Bash is sufficient - analysis happens in main context |
 | "I only fixed lint, typecheck still passes" | Always re-verify ALL - fixes can cascade |
 | "Build is part of verification" | Build is deployment, not verification - NEVER include it |
 | "Let me ask which path to check" | Default to full project - explicit behavior |
 | "I'll try one more fix approach" | After 2-3 attempts → recommend /sd-debug |
 | "Tests are independent of types" | Type fixes affect tests - always re-run ALL |
 | "I'll invoke sd-check skill with args" | sd-check is EXACT STEPS, not a command |
-| "4 agents: typecheck, lint, test, build" | Only 3 agents - build is FORBIDDEN |
+| "4 commands: typecheck, lint, test, build" | Only 3 commands - build is FORBIDDEN |

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

@@ -0,0 +1,88 @@
+---
+name: sd-discuss
+description: "Use when evaluating code design decisions against industry standards and project conventions - class vs functional, pattern choices, architecture trade-offs, technology selection"
+model: opus
+---
+
+# Standards-Based Technical Discussion
+
+## Overview
+
+Facilitate balanced, evidence-based technical discussions by researching industry standards and project conventions BEFORE forming opinions.
+
+## The Process
+
+### 1. Understand the Question
+
+Ask ONE question to understand the user's motivation:
+- What problem triggered this question?
+- What constraints matter most?
+
+### 2. Research Before Opinions
+
+**MANDATORY before forming any opinion:**
+
+**Project research** (Read/Grep tools):
+- Read the actual source code related to the question
+- Check CLAUDE.md for project conventions
+- Find similar patterns in the codebase
+
+**Industry research** (WebSearch tool):
+- Search for current community consensus and trends
+- Check relevant specifications (TC39, W3C, RFCs)
+- Find recent benchmarks, migration case studies, or survey data
+- Check how popular libraries/frameworks approach this
+
+### 3. Present Balanced Arguments
+
+Present each option as if you were **advocating FOR it**. Equal depth, equal effort.
+
+For each option:
+- **Industry support**: Libraries, standards, and projects that use this approach (with sources)
+- **Technical advantages**: Concrete benefits with evidence
+- **When this wins**: Specific scenarios where this is clearly better
+
+### 4. Project Context Analysis
+
+- How does the current codebase align with each option?
+- What would migration cost look like?
+- What existing patterns favor one approach?
+
+### 5. Decision Criteria
+
+Provide a decision matrix — NOT a single recommendation:
+
+| Criteria | Option A | Option B |
+|----------|----------|----------|
+| Industry alignment | ... | ... |
+| Project consistency | ... | ... |
+| Migration cost | ... | ... |
+| Long-term trend | ... | ... |
+
+Then ask: "Which criteria matter most to you?"
+
+## Key Rules
+
+1. **Research FIRST, opinion LAST** — No opinions before WebSearch + project code reading
+2. **Equal advocacy** — Each option gets the same depth of analysis
+3. **Evidence over intuition** — Cite sources, show data
+4. **No "obvious" answers** — If it were obvious, there'd be no discussion
+5. **Interactive** — Ask questions, don't monologue
+6. **Project-aware** — Ground the discussion in the actual codebase
+
+## Red Flags - STOP and Research More
+
+- Presenting one side with more depth than the other
+- Claiming "industry standard" without citing sources
+- Recommending without checking the project's current patterns
+- Giving a conclusion without asking user's priorities
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Jump to recommendation | Research first, present balanced options |
+| "Industry standard is X" without sources | WebSearch for actual data and citations |
+| Ignoring project context | Read codebase patterns before discussing |
+| Monologue instead of discussion | Ask about user's priorities and constraints |
+| Treating "modern" as "better" | Evaluate on actual trade-offs, not trends |

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

@@ -4,216 +4,263 @@ description: Use when executing implementation plans with independent tasks in t
 model: opus
 ---
 
-# Plan Execution
+# Parallel Plan Execution
 
-Execute plan tasks with the right-sized process: direct for small plans, parallel agents for large plans.
+Execute plan tasks via parallel Task agents with dependency-aware scheduling.
 
-**Core principle:** Right-size the process to the plan. Small plans get direct execution; large plans get parallel agents with formal reviews.
+**Core principle:** Dependency analysis + parallel Task agents + nested parallel reviews = maximum throughput
 
 ## When to Use
 
-Have an implementation plan (from sd-plan or similar)? Use this skill.
-No plan? Use sd-plan or sd-brainstorm first.
+```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"];
+}
+```
+
+## Execution Method
 
-## Mode Selection
+All execution uses `Task(general-purpose)` for parallel execution.
 
-**Default is Agent Mode.** Only use Direct Mode when ALL "Small" criteria are met.
+- **task agent**: `Task(general-purpose)` — implements one task, launches sub-Tasks for review, fixes issues
+- **spec reviewer**: `Task(general-purpose, model: "opus")` — sub-Task launched by task agent (read-only)
+- **quality reviewer**: `Task(general-purpose, model: "opus")` — sub-Task launched by task agent (read-only)
+
+Independent tasks run as **parallel Task calls in a single message**. Within each task agent, spec and quality reviews also run as **parallel sub-Task calls**.
+
+## The Process
 
 ```dot
-digraph mode {
-    "Small?" [shape=diamond];
-    "Direct Mode\n(no agents)" [shape=box];
-    "Agent Mode\n(parallel agents)" [shape=box, style=bold];
+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];
 
-    "Small?" -> "Direct Mode\n(no agents)" [label="yes (all 3 criteria)"];
-    "Small?" -> "Agent Mode\n(parallel agents)" [label="no (default)"];
+    subgraph cluster_batch {
+        label="Per Batch (independent tasks)";
+
+        subgraph cluster_parallel_tasks {
+            label="Parallel Task calls (single message)";
+            style=dashed;
+
+            subgraph cluster_task_agent {
+                label="Each Task Agent";
+                "Implement the task" [shape=box];
+                "Questions?" [shape=diamond];
+                "Return questions to orchestrator" [shape=box];
+                "Re-launch with answers" [shape=box];
+
+                subgraph cluster_nested_review {
+                    label="Parallel sub-Task calls";
+                    style=dashed;
+                    "sub-Task: spec reviewer" [shape=box];
+                    "sub-Task: quality reviewer" [shape=box];
+                }
+
+                "Any issues?" [shape=diamond];
+                "Fix all issues" [shape=box];
+                "Re-review failed aspects (parallel sub-Task)" [shape=box];
+                "Report results" [shape=box];
+            }
+        }
+    }
+
+    "More batches?" [shape=diamond];
+    "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?" -> "sub-Task: spec reviewer" [label="no"];
+    "Questions?" -> "sub-Task: quality reviewer" [label="no"];
+    "sub-Task: spec reviewer" -> "Any issues?";
+    "sub-Task: quality reviewer" -> "Any issues?";
+    "Any issues?" -> "Fix all issues" [label="yes"];
+    "Fix all issues" -> "Re-review failed aspects (parallel sub-Task)";
+    "Re-review failed aspects (parallel sub-Task)" -> "Any issues?";
+    "Any issues?" -> "Report results" [label="no"];
+    "Report results" -> "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";
 }
 ```
 
-**"Small" criteria (ALL must be true):**
-1. Tasks ≤ 2
-2. Source files ≤ 3 (test files excluded, count across all tasks)
-3. Every task is a simple addition or modification — NOT refactoring, structural changes, or cross-cutting concerns
+## Dependency Analysis
 
-**When in doubt, choose Agent Mode.**
+Before launching tasks, analyze the plan to build a dependency graph:
 
----
+1. **For each task**: identify which files/modules it will create or modify
+2. **Find overlaps**: tasks touching the same files depend on each other
+3. **Respect logical dependencies**: if task B uses what task A creates, B depends on A
+4. **Group into batches**: tasks with no dependencies between them form one batch
 
-## Direct Mode
+```
+Example: 5 tasks
+  Task 1: creates utils/validator.ts
+  Task 2: creates hooks/useAuth.ts
+  Task 3: creates components/Login.tsx (uses hooks/useAuth.ts)
+  Task 4: modifies utils/validator.ts
+  Task 5: creates api/endpoints.ts
+
+  Batch 1: [Task 1, Task 2, Task 5] — independent, parallel
+  Batch 2: [Task 3] — depends on Task 2
+  Batch 3: [Task 4] — depends on Task 1
+```
 
-No agents, no batching -- implement directly in main context.
+## Task Agent Prompt
 
-1. Read plan, understand all tasks
-2. Implement in dependency order. For each task:
-   - Implement exactly what the spec says
-   - Write tests and run them
-   - Ensure new public APIs are exported in the package's `index.ts`
-   - Self-review: spec complete? overbuilt? clean?
-   - Fix issues found
-3. After all tasks: `pnpm typecheck` + `pnpm lint` + `pnpm vitest` on affected packages
-4. Done
+Each task agent receives a prompt combining implementation + review instructions:
 
-**Escalation:** Switch to Agent Mode immediately if any of these occur during execution:
-- A task turns out to touch more files than expected
-- You find yourself doing structural changes or refactoring
-- The total change set exceeds ~100 lines of source code
+```
+You are implementing and reviewing Task N: [task name]
 
----
+## Task Description
 
-## Agent Mode
+[FULL TEXT of task from plan]
 
-Dependency-aware batching with parallel Task agents and formal reviews.
+## Context
 
-### Architecture
+[Scene-setting: where this fits, dependencies, architectural context]
 
-| Role | How | Model | Job |
-|------|-----|-------|-----|
-| Orchestrator | (you) | sonnet | Deps, prompts, lifecycle |
-| Implementer | `Task(general-purpose)` | default | Implement one task |
-| Spec reviewer | `Task(general-purpose)` | opus | Verify spec match |
-| Quality reviewer | `Task(general-purpose)` | opus | Verify code quality |
-| Final reviewer | `Task(general-purpose)` | opus | Cross-task integration |
+## Your Job
 
-### Process
+1. Implement exactly what the task specifies
+2. Write tests (following TDD if task says to)
+3. Verify implementation works
+4. Self-review: did I implement everything? Did I over-build?
+5. Launch TWO parallel sub-Tasks (spec review + quality review):
+   - Sub-Task 1: spec reviewer — send spec-reviewer-prompt.md based prompt
+   - Sub-Task 2: quality reviewer — send code-quality-reviewer-prompt.md based prompt
+6. If either reviewer finds issues → fix them → re-review only failed aspects (parallel sub-Tasks again)
+7. Repeat until both reviewers approve
+8. Report back with: what you implemented, test results, files changed, review outcomes
 
-```dot
-digraph agent_mode {
-    rankdir=TB;
+If you have questions about requirements — return them immediately WITHOUT implementing. Don't guess.
 
-    setup [label="1. Read plan, extract tasks, TaskCreate"];
-    deps [label="2. Dependency analysis → batch grouping"];
+Work from: [directory]
+```
 
-    subgraph cluster_batch {
-        label="3. Per Batch";
-        implement [label="Launch parallel implementer Tasks"];
-        questions [label="Questions?" shape=diamond];
-        ask [label="Ask user → re-launch with answers"];
-        reviews [label="Launch parallel reviews\n(spec + quality per task)"];
-        issues [label="Issues?" shape=diamond];
-        fix [label="Re-launch implementer with fix list\n→ re-review (max 3 cycles)"];
-        batch_done [label="Batch complete"];
-    }
+## Prompt Templates
+
+- `./implementer-prompt.md` — base implementer instructions (referenced by task agent)
+- `./spec-reviewer-prompt.md` — spec compliance review sub-Task prompt
+- `./code-quality-reviewer-prompt.md` — code quality review sub-Task prompt
+
+## Example Workflow
 
-    more [label="More batches?" shape=diamond];
-    final [label="4. Final review (opus)"];
-    done [label="5. Done" shape=ellipse];
-
-    setup -> deps -> implement;
-    implement -> questions;
-    questions -> ask [label="yes"];
-    ask -> implement;
-    questions -> reviews [label="no"];
-    reviews -> issues;
-    issues -> fix [label="yes"];
-    fix -> issues;
-    issues -> batch_done [label="no"];
-    batch_done -> more;
-    more -> implement [label="yes"];
-    more -> final [label="no"];
-    final -> done;
-}
 ```
+You: Using sd-plan-dev to execute this plan.
 
-### Dependency Analysis
+[Read plan file: docs/plans/feature-plan.md]
+[Extract all 5 tasks with full text + create TaskCreate]
 
-1. Per task: identify files created/modified
-2. File overlap → dependent (same batch is prohibited)
-3. Logical dependency (B uses what A creates) → dependent
-4. No dependencies between each other → same batch (parallel)
+[Dependency analysis]
+  Task 1 (validator): no deps
+  Task 2 (auth hook): no deps
+  Task 3 (login component): depends on Task 2
+  Task 4 (validator update): depends on Task 1
+  Task 5 (api endpoints): no deps
 
-```
-Example: Task 1 creates types.ts, Task 2 uses types.ts, Task 3 independent
-  Batch 1: [Task 1, Task 3]    ← parallel
-  Batch 2: [Task 2]            ← depends on Task 1
-```
+  Batch 1: [Task 1, Task 2, Task 5]
+  Batch 2: [Task 3, Task 4]
 
-### Prompt Construction
+--- Batch 1: parallel ---
 
-**Implementer:** Use `./implementer-prompt.md` template. Fill in:
-- Task name and full description (paste full text, NOT file reference)
-- Context: where it fits, what depends on it
-- Cross-batch context (for batch 2+): what previous batches produced, files created
-- Working directory
+[3 parallel Task calls in single message]
 
-**Reviews:** After **all** implementers in the batch report back (including question resolution), launch in parallel:
-- Spec review: `./spec-reviewer-prompt.md` -- fill in requirements + implementer report
-- Quality review: `./code-quality-reviewer-prompt.md` -- fill in report + changed files
-- Launch both in a single message (2 Task calls per completed task)
+  Task 1 agent:
+    - Implemented validator, tests 5/5 pass
+    - Parallel sub-Tasks: spec ✅, quality ✅
+    → Done
 
-**Final review:** `./final-review-prompt.md` -- fill in the design doc that corresponds to the current plan (match by topic/date in `docs/plans/`, if exists) + full plan + all task results
+  Task 2 agent:
+    - "Should auth use JWT or session?" (question returned)
 
-### Fix-Review Cycle
+  Task 5 agent:
+    - Implemented endpoints, tests 3/3 pass
+    - Parallel sub-Tasks: spec ✅, quality: Issues (magic number)
+    - Fixed magic number
+    - Parallel re-review: quality ✅
+    → Done
 
-When reviewers find issues:
-1. Compile all issues from both reviewers
-2. Re-launch the implementer Task with original prompt + fix list
-3. Re-review only failed aspects (re-launch only the reviewer that found issues)
-4. **Max 3 cycles.** After that, report remaining issues to user for decision.
+[Answer Task 2 question: "JWT"]
+[Re-launch Task 2 agent with answer]
 
-### Question Handling
+  Task 2 agent:
+    - Implemented auth hook with JWT, tests 4/4 pass
+    - Parallel sub-Tasks: spec ✅, quality ✅
+    → Done
 
-If an implementer returns questions (output contains `## Questions`):
-1. Present questions to the user
-2. Re-launch that implementer Task with original prompt + answers appended
-3. Other completed tasks in the batch are unaffected
+[Batch 1 complete]
 
-### Commit Strategy
+--- Batch 2: parallel ---
 
-- Agents work on filesystem directly -- no commits during implementation
-- After final review passes, commit (use sd-commit or manual)
-- Do NOT commit between batches
+[2 parallel Task calls in single message]
 
-## Red Flags
+  Task 3 agent:
+    - Implemented login component using Task 2's auth hook
+    - Parallel sub-Tasks: spec ❌ (missing error state), quality ✅
+    - Fixed error state
+    - spec re-review ✅
+    → Done
 
-- Skip reviews in Agent Mode
-- Put file-overlapping tasks in same parallel batch
-- Skip dependency analysis
-- Send plan file path to agents instead of full text
-- Accept "close enough" on spec compliance
-- Exceed 3 fix-review cycles without user input
-- Proceed to next batch before current batch fully passes
+  Task 4 agent:
+    - Updated validator with new rules
+    - Parallel sub-Tasks: spec ✅, quality ✅
+    → Done
 
-## Error Handling
+[Batch 2 complete]
 
-- Implementer fails completely → retry once, then report to user
-- Reviewer crashes → re-launch once
-- Fix-review loop at max → report to user for decision
-- File conflicts between parallel agents → stop batch, report to user
+--- Final ---
 
-## Example (Agent Mode)
+[Task — final review for entire implementation]
+Final reviewer: All requirements met, ready to merge
 
+Done!
 ```
-[Read plan: 5 tasks]
-[Dep analysis → Batch 1: [T1, T2], Batch 2: [T3, T4, T5]]
-
---- Batch 1 ---
-[2 parallel implementer Tasks]
-  T1: implemented, tests pass → report
-  T2: "Should this use JWT?" → questions returned
 
-[2 parallel reviews for T1]
-  Spec ✅, Quality ⚠️ magic number → CHANGES_NEEDED
+## Red Flags
 
-[Ask user T2's question → "JWT"]
-[Re-launch T2 with answer] → implemented → report
-[Fix T1 magic number → re-review quality] → ✅
-[2 parallel reviews for T2] → Spec ✅, Quality ✅
+**Never:**
+- Start implementation on main/master without explicit user consent
+- Skip reviews (spec compliance OR code quality)
+- Proceed with unfixed issues
+- Put tasks with file overlap in the same parallel batch
+- Skip dependency analysis
+- Make task agent read plan file directly (provide full text instead)
+- Skip scene-setting context
+- Accept "close enough" on spec compliance
+- Skip review loops (issue found → fix → re-review)
 
---- Batch 2 (with batch 1 context) ---
-[3 parallel implementer Tasks] → all pass
-[6 parallel reviews] → all pass
+**If task agent returns questions:**
+- Answer clearly and completely
+- Re-launch that agent with answers included
+- Other parallel agents continue unaffected
 
---- Final review (opus) ---
-Integration check ✅ → Done!
-```
+**If reviewers find issues:**
+- Task agent fixes all issues from both reviewers at once
+- Re-review only the failed aspects (parallel sub-Tasks)
+- Repeat until both approved
 
 ## After Completion
 
-When all tasks and final review pass:
-- If in a worktree (`.worktrees/`) → guide user to `/sd-worktree merge`
+When all tasks and final review are done, if the current working directory is inside a worktree (`.worktrees/`), guide the user to:
+- `/sd-worktree merge` — Merge the worktree branch back into main
 
 ## Integration
 
-- **sd-plan** -- creates the plan this skill executes
-- **sd-tdd** -- implementers follow TDD when plan specifies it
-- **sd-worktree** -- branch isolation for worktree-based workflows
+**Related skills:**
+- **sd-plan** — creates the plan this skill executes
+- **sd-tdd** — task agents follow TDD
+- **sd-worktree** — branch isolation for worktree-based workflows

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

@@ -31,6 +31,7 @@ Analyze user request from ARGUMENTS, select the best matching sd-* skill or agen
 | `sd-check` | Verify code — typecheck, lint, tests |
 | `sd-commit` | Create a git commit |
 | `sd-readme` | Update a package README.md |
+| `sd-discuss` | Evaluate code design decisions against industry standards and project conventions |
 | `sd-api-name-review` | Review public API naming consistency |
 | `sd-worktree` | Start new work in branch isolation |
 | `sd-skill` | Create or edit skills |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "13.0.37",
+  "version": "13.0.39",
   "description": "Simplysm Claude Code CLI — asset installer and cross-platform npx wrapper",
   "author": "김석래",
   "license": "Apache-2.0",
@@ -12,9 +12,6 @@
   "type": "module",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",
-  "bin": {
-    "sd-claude": "./dist/sd-claude.js"
-  },
   "files": [
     "dist",
     "src",
@@ -30,5 +27,8 @@
   },
   "scripts": {
     "postinstall": "node scripts/postinstall.mjs"
+  },
+  "bin": {
+    "sd-claude": "./dist/sd-claude.js"
   }
 }