@simplysm/sd-claude 13.0.64 → 13.0.66

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

@@ -25,20 +25,44 @@ Start by understanding the current project context, then ask questions one at a
 
 When you think you've asked enough, **STOP and run a gap review before moving on.**
 
-1. Silently check ALL of these categories for unanswered questions:
-   - **Scope**: What's in? What's explicitly out?
-   - **User flows**: All inputs, outputs, feedback, navigation
-   - **Edge cases**: Empty states, errors, limits, concurrency, undo
-   - **Data**: Shape, validation, persistence, migration, relationships
-   - **Integration**: How does this connect to existing code/systems?
-   - **Non-functional**: Performance, accessibility, security, i18n
-   - **Assumptions**: Anything you assumed but never confirmed
-2. If ANY new question emerges → ask it, then **restart from step 1**
-3. Only when zero questions remain across ALL categories → proceed to exploring approaches.
+Tell the user you're running a gap review, then check ALL categories. For each ✅, you MUST **cite specific evidence** (which Q&A, code reference, or explicit user requirement). "I already know" is not evidence.
+
+| Category | Check for... |
+|----------|-------------|
+| Scope | What's in? What's explicitly out? |
+| User flows | All inputs, outputs, feedback, navigation |
+| Edge cases | Empty states, errors, limits, concurrency, undo |
+| Data | Shape, validation, persistence, migration, relationships |
+| Integration | How does this connect to existing code/systems? |
+| Non-functional | Performance, accessibility, security, i18n |
+| Assumptions | Anything you assumed but never confirmed |
+
+Output format — cite evidence for each:
+- `✅ Scope — [Q2: user confirmed X / code at file:line / requirement doc says Y]`
+- `❓ Edge cases — gap: [what's missing]`
+
+If evidence is vague ("obvious", "I already know", "common sense") → mark as ❓, not ✅.
+
+- If ANY ❓ exists → ask about it. After the user answers, **run the full checklist again from scratch**.
+- Only when ALL categories show ✅ with cited evidence → proceed to exploring approaches.
+
+**All-✅ on first run is PROHIBITED — not "suspicious", prohibited.**
+If your first gap review shows all ✅:
+1. You are rubber-stamping. Prior investigation ≠ complete design exploration.
+2. Pick the 2 weakest categories (thinnest evidence).
+3. Write one concrete unasked question per category.
+4. Ask those questions, then re-run the full checklist from scratch.
+
+| Excuse | Reality |
+|--------|---------|
+| "Requirements are already clear" | Clear requirements ≠ complete design. Edge cases, error states, integration points still need exploration. |
+| "I already investigated the code" | Code investigation reveals what IS. Design exploration asks what SHOULD BE. Different activities. |
+| "It's just a bug fix" | Bug fixes have edge cases: error states, concurrent access, timing changes, consumer compatibility. |
+| "User is frustrated/in a hurry" | Rushing causes exactly the mistakes brainstorming prevents. Slow down. |
 
 **Rules:**
-- Each loop must seriously re-examine all categories, not just skim.
-- Looping only once is suspicious — double-check.
+- You MUST show the checklist to the user every time you run it. No silent/internal-only checks.
+- Each run must re-examine ALL categories from zero — do not carry over previous results.
 - When in doubt, ask. One extra question costs less than a flawed design.
 
 **Exploring approaches:**

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

@@ -10,12 +10,12 @@ model: haiku
 
 ## Overview
 
-Stages and commits changes using Conventional Commits format. Two modes: **default** (context-relevant files, single commit) and **all** (all changed files, split by intent if needed).
+Stages and commits changes using Conventional Commits format. Two modes: **default** (context-relevant files, single commit) and **all** (all changed files, single commit).
 
 ## Mode
 
 - **Default mode** (no arguments): Stage files relevant to the current conversation context. Always a **single commit**.
-- **"all" mode** (`$ARGUMENTS` is "all"): Target **all** changed/untracked files. May produce multiple commits.
+- **"all" mode** (`$ARGUMENTS` is "all"): Target **all** changed/untracked files. Always a **single commit**.
 
 ## File Selection Rules
 
@@ -60,30 +60,10 @@ Examples:
 
 Use a HEREDOC for multi-line messages when needed.
 
-## Commit Strategy (all mode only)
-
-Group by **intent/purpose**, not by package.
-
-**Single commit** — all changes share the same intent:
-
-- Version bumps across packages → `chore: bump version to x.y.z`
-- One feature spanning multiple packages → single `feat`
-- Dependency updates across packages → single `chore`
-
-**Split commits** — changes have different intents:
-
-- Version bump + unrelated bug fix → `chore` + `fix`
-- New feature + unrelated refactor → two commits
-- `docs` changes + independent `feat` changes → two commits
-
 ## Execution
 
 **Default mode:** `git add <context-relevant files>` → `git commit`
 
-**All mode:**
-
-1. Decide: single or split.
-2. Single: `git add .` → `git commit`.
-3. Split: group by logical unit, commit in dependency order (foundations first). Per group: `git add <files>` → `git commit`.
+**All mode:** `git add .` → `git commit` with a single message summarizing all changes (message may be long).
 
 Call multiple tools in one response when possible. Do not use other tools or output other text.

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

@@ -1,11 +1,18 @@
 ---
 name: sd-plan
-description: Use when you have a spec or requirements for a multi-step task, before touching code
+description: "NEVER invoke directly from user requests. This skill is ONLY called as a follow-up step after sd-brainstorm has completed. If the user asks to plan, design, or implement something, use sd-brainstorm first."
 model: opus
 ---
 
 # Writing Plans
 
+## Prerequisite Check
+
+**MANDATORY:** Before proceeding, verify that `sd-brainstorm` has already been completed in this conversation.
+
+- If a brainstorm design document exists (discussed or saved in this session) → proceed.
+- If NOT → **STOP** and tell the user (in the system's configured language) that sd-plan requires sd-brainstorm to be completed first, then invoke sd-brainstorm instead.
+
 ## Overview
 
 Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
@@ -96,7 +103,9 @@ git commit -m "feat: add specific feature"
 
 ## Execution Handoff
 
-After saving the plan:
+After saving the plan, **commit the plan document to git** before proceeding.
+
+Then:
 
 - If in **yolo mode** (user chose "yolo" from sd-brainstorm): Immediately proceed to sd-plan-dev without asking. No confirmation needed.
 - Otherwise: Display this message **in the system's configured language** (detect from the language setting and translate accordingly):

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "13.0.64",
+  "version": "13.0.66",
   "description": "Simplysm Claude Code CLI — asset installer and cross-platform npx wrapper",
   "author": "김석래",
   "license": "Apache-2.0",