fix: close SDD workflow handoff gaps across 5 plugins

brain-storm-plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "brain-storm-plugin",
   "description": "Brainstorm future features and improvements, then generate standalone HTML previews for UI ideas",
-  "version": "1.2.0",
+  "version": "1.2.4",
   "author": {
     "name": "Stefan Cho"
   }

brain-storm-plugin/skills/brain-storm/SKILL.md

@@ -88,7 +88,9 @@ After writing all idea files, include this report in the final response:
 | `{path}` | {title} | {complexity} |
 
 ### Next Steps
-- Refine an idea into a spec: `/writing-specs {idea title}`
+- Refine an idea into a spec (recommended — pass the file path so writing-specs reads it directly):
+  `/writing-specs brain-storm/{file-name}.md`
+  (Title or keyword also works: `/writing-specs "{idea title}"`)
 - Generate a UI prototype preview for a UI-focused idea: `/ui-prototype-preview {idea title}`
 ```
 
@@ -115,3 +117,15 @@ Triggered by requests such as "clean up brainstorm notes" or "remove ideas that
 2. Ask the user whether to delete all, delete selected ideas, or cancel.
 3. Delete files only after explicit confirmation.
 4. Report the result with status and evidence for each reviewed idea.
+
+---
+
+## Non-interactive defaults
+
+If the harness signals non-interactive mode (auto mode, scheduled run, headless agent — i.e. `AskUserQuestion` is unavailable or the user has stated "automatic" / "no questions"), use these defaults instead of asking. **Always echo the defaulted decisions back in the final report so the user can override.**
+
+| Decision point | Default | Rationale |
+|---|---|---|
+| Which ideas to save (Brainstorm Step 1) | Save 2 ideas: pick the most diverse pair (1 UX/polish + 1 new capability), preferring Low/Medium complexity. | Diversity beats volume; low-complexity proves out the workflow without committing to large work. |
+| Duplicate detected (Brainstorm Step 2) | Skip writing the new file. | Never overwrite user-authored notes silently. |
+| Cleanup deletion (Cleanup Step 2) | **Refuse**: report candidates only, do not delete. | Deletion is unrecoverable; require an explicit follow-up command. |

brain-storm-plugin/skills/brain-storm/templates/wireframe-guide.md

@@ -2,6 +2,20 @@
 
 ASCII wireframe conventions for UI ideas. Follow these rules for consistency.
 
+## Project Type Branch (read this first)
+
+Pick the branch that matches the project being brainstormed:
+
+- **GUI / web / mobile UI** → use the box-drawing rules below.
+- **CLI tool / library / backend service** → skip the GUI layout style. Use one of:
+  - **Terminal session**: a faithful transcript of the proposed commands and their output (see CLI Example).
+  - **Data flow / system sketch**: ASCII arrows between components, JSON/YAML schema snippets, pipeline diagrams.
+  The 10-line minimum still applies; the spirit of the rule is "make the implementation direction visible." Small flow-chart rectangles wrapping a process step (e.g. boxed pseudo-code in a sequence) are fine — what to avoid is GUI-style layouts (toolbars, button rows, modals, multi-column dashboards) that imply a screen the project does not have.
+
+---
+
+## GUI Branch (default sections below)
+
 ## Box Drawing Characters
 
 Use Unicode box-drawing characters for all borders:
@@ -57,3 +71,34 @@ Characters: `┌ ─ ┐ │ └ ┘ ├ ┤ ┬ ┴ ┼`
 │         [ Load More ]               │
 └─────────────────────────────────────┘
 ```
+
+---
+
+## CLI Example (terminal session style)
+
+```
+$ todo add "buy milk" --priority high --due 2026-04-30
+added [1] buy milk  [HIGH] (due 2026-04-30)
+
+$ todo list
+[ ] 1: buy milk        [HIGH] (due 2026-04-30)
+[ ] 2: write spec      [MED]
+[x] 3: ship feature
+
+$ todo list --open --search milk
+[ ] 1: buy milk        [HIGH] (due 2026-04-30)
+
+$ todo list --done --search xyz
+no matching todos
+```
+
+## CLI Example (data flow style)
+
+```
+   stdin / argv ──► parser ──► validator ──► store(JSON)
+                                  │              │
+                                  ▼              ▼
+                              friendly       atomic write
+                              error msgs     (~/.todo.json)
+```
+

implement-with-test-plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "implement-with-test-plugin",
   "description": "Implement code with tests from specs or direct requests",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "author": {
     "name": "Stefan Cho"
   }

implement-with-test-plugin/skills/implement-with-test/SKILL.md

@@ -134,10 +134,10 @@ Phase 1 argument가 **파일 경로**였을 때만 실행한다. 직접 설명
 
 목적: 해당 task 문서의 상태를 갱신해 추적 가능하게 만든다. **surgical edit만 허용** — 요청한 필드/체크박스 외의 내용은 수정·정렬·재포맷하지 않는다.
 
-1. **Status 결정**
-   - 모든 Verification 테스트 통과 → `completed`
-   - 일부만 통과 (3회 재시도 후에도 실패 존재) → `partial`
-   - 모든 테스트 실패 → `failed`
+1. **Status 결정** (writing-tasks schema 와 호환되는 값을 사용)
+   - 모든 Verification 테스트 통과 → `done`
+   - 일부만 통과 (3회 재시도 후에도 실패 존재) → `review` (사람이 잔여 항목 확인 필요)
+   - 모든 테스트 실패 → `blocked`
 
 2. **Frontmatter 갱신**
    - Frontmatter 존재 (`---` 블록) → `status: {status}` 와 `completed_at: YYYY-MM-DD` 필드를 설정. 해당 키가 이미 있으면 값만 교체, 없으면 추가.
@@ -160,3 +160,14 @@ Phase 1 argument가 **파일 경로**였을 때만 실행한다. 직접 설명
 | Existing tests use unfamiliar patterns | Follow patterns as-is; do not "modernize" |
 | Tests fail after 3 fix attempts | Report the current state honestly in "테스트" section with error details, and list remaining failures under "다음 단계" |
 | Task is ambiguous | Ask user to clarify before implementing |
+
+## Non-interactive defaults
+
+If `AskUserQuestion` is unavailable (auto mode, headless agent, scheduled run), use these defaults and document every defaulted decision in the report so the user can override.
+
+| Decision point | Default | Rationale |
+|---|---|---|
+| Conversation-inferred task confirmation (Phase 1) | Skip the confirmation. Instead, restate the extracted Purpose/Requirements/Approach/Verification at the top of the Phase 3 plan so the user sees the assumption. | Keeps the workflow flowing while preserving auditability. |
+| No argument and no clear conversation task | **Refuse**: report "no implementable task identified, please pass a task file path or describe the work." | Silent guessing produces wrong code. |
+| Test framework not detected | Try in order: `python -m pytest --collect-only -q` → `npm test --silent --listTests` → `go test ./... -list .*` → `cargo test --list`. Use the first one that exits 0 with at least one test discovered. If all fail, refuse and report. | Detection order mirrors common project types. |
+| Ambiguous task content | Pick the most conservative interpretation (smallest behavior change, fewest new files), and list the assumptions in the "기술 구현" section. | Minimal-diff principle is the project's tie-breaker. |

split-work-plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "split-work-plugin",
   "description": "Split current project work into parallel-safe task groups with worktree branch names and structured starting prompts",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "author": {
     "name": "Stefan Cho"
   }

split-work-plugin/skills/split-work/SKILL.md

@@ -23,11 +23,14 @@ allowed-tools: Read, Glob, Grep, Bash
    ```
    - `{project-slug}` 결정 (worktree 안에서도 main repo 기준):
      ```bash
-     main_repo="$(dirname "$(git rev-parse --git-common-dir)")"
+     # --path-format=absolute 로 워크트리에서도 main repo 의 .git 절대 경로를 얻는다.
+     git_common_dir="$(git rev-parse --path-format=absolute --git-common-dir)"
+     main_repo="$(dirname "$git_common_dir")"
      slug="$(basename "$(dirname "$main_repo")")-$(basename "$main_repo")"
      # 예: ~/works/runner/web → runner-web
      ```
      basename 만 쓰면 `web` 같은 generic 이름이 다른 repo 와 충돌하므로 부모 한 단계 결합.
+     `--path-format=absolute` 플래그를 빠뜨리면 워크트리 안에서 `git_common_dir` 가 `../../.git` 같은 상대 경로가 되어 슬러그가 `.-.` 으로 망가진다.
    - 디렉토리 없으면 `mkdir -p` 로 생성. 타임스탬프는 KST 기준.
 6. **출력** — 저장한 파일의 **전체 내용을 그대로** 반환한다. 맨 앞에 `💾 저장됨: <절대경로>` 한 줄 추가.
 

writing-specs-plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "writing-specs-plugin",
   "description": "Spec-driven development with search, conflict detection, and reporting",
-  "version": "1.0.0",
+  "version": "1.0.3",
   "author": {
     "name": "Stefan Cho"
   }

writing-specs-plugin/skills/writing-specs/SKILL.md

@@ -21,13 +21,44 @@ Manages spec files in `specs/` directory with conflict detection and concise rep
 ## Directory Rules
 
 - Specs live in `specs/` at the project root
-- File format: `specs/{name}.md` or `specs/{subdir}/{name}.md`
-- Only 1-depth subdirectories allowed (e.g., `specs/api/auth.md` is OK, `specs/api/v2/auth.md` is NOT)
+- **Default file format (recommended): `specs/phase-N/NN-name.md`**
+  - This is the convention `writing-tasks-plugin` consumes — using it makes the spec→task handoff zero-friction.
+  - `phase-N` is a 1-indexed sprint/milestone number that monotonically increases across the project lifetime (never reset).
+  - `NN` is a 2-digit local index within the phase, starting at `01`.
+  - Example: `specs/phase-1/01-jwt-authentication.md`, `specs/phase-3/02-profile-delete.md`
+- Alternative formats (only when no `writing-tasks` integration is planned): `specs/{name}.md` or `specs/{subdir}/{name}.md`
+- Only 1-depth subdirectories allowed (e.g., `specs/phase-1/auth.md` is OK, `specs/phase-1/v2/auth.md` is NOT)
 - Filenames use lowercase-with-hyphens (e.g., `jwt-authentication.md`)
-- Create subdirectories only when the user explicitly requests grouping or when there are 5+ specs that share a clear category
+- Create subdirectories (or new phases) only when the user explicitly requests grouping or when there are 5+ specs that share a clear category
+
+### Choosing the phase + NN automatically
+
+When the user does not specify a phase or number:
+1. `Glob specs/phase-*/` → list existing phases. If none, default to `phase-1`.
+2. Pick the **active phase**: the highest-numbered existing phase, unless the user signals a new milestone (in which case create `phase-{N+1}`).
+3. `Glob specs/phase-N/*.md` → find the highest existing `NN`. New spec gets `NN+1`, zero-padded.
+4. If the spec belongs to an explicitly different milestone (different feature epic, separate timeline), ask the user via `AskUserQuestion` whether to create a new phase.
 
 ## Workflow
 
+### Phase 0: Argument Resolution
+
+The user-provided argument can be one of four shapes. Resolve it to a single **input source** before searching.
+
+| Argument shape | Resolution |
+|---|---|
+| Path to a `brain-storm/{name}.md` (or `brain-storm/{subdir}/{name}.md`) file | `Read` the file. Treat its `Summary`, `Motivation`, `Proposed Approach` as the spec source. The brain-storm idea title becomes the spec H1. |
+| Path to any other markdown file | `Read` it and treat its content as the spec source. |
+| Bare title or keyword (e.g. `"List Filter and Search"`) | `Glob brain-storm/**/*.md` and match the title (case-insensitive H1 match, then filename slug match). If exactly one match, use it. If multiple, list candidates via `AskUserQuestion`. If zero, treat the argument as a freestyle description (next row). |
+| Freestyle natural-language description, or no argument | Use the conversation context. If empty, ask the user via `AskUserQuestion` what spec to create. |
+
+When a brain-storm idea is the source, carry over its content explicitly:
+- The idea's `Summary` → seeds the spec `Purpose`.
+- The idea's `Proposed Approach` bullets → seeds `Requirements` (prune to 3-5 concrete items) and the prose `Approach`.
+- The idea's `Wireframe` and `Open Questions` are **not** copied (template has fixed sections); mention them in the final report under "Carried over" so the user knows what was dropped.
+
+After resolution, proceed to Phase 1 with the resolved input source.
+
 ### Phase 1: Search (mandatory)
 
 Before any create or update operation, search for existing specs:
@@ -57,8 +88,9 @@ Use `AskUserQuestion` for all user decisions.
 
 1. Read the spec template: [templates/spec-template.md](templates/spec-template.md)
 2. Fill each section based on the user's request, strictly following the template structure
-3. Write to the appropriate path under `specs/`
-4. If updating an existing spec, preserve any content the user didn't ask to change
+3. Resolve the destination path using the **Choosing the phase + NN automatically** rules in Directory Rules (default to `specs/phase-N/NN-name.md`).
+4. Write to the resolved path under `specs/`
+5. If updating an existing spec, preserve any content the user didn't ask to change
 
 Section constraints (enforced, not suggested):
 - **Purpose**: Exactly 1-2 sentences. No bullet points.
@@ -85,3 +117,18 @@ Output the completed report as the final message. This is how the user sees what
 - **Search Results**: List each related/outdated spec found, or "No related specs found"
 - **Changes**: For updates, summarize what changed. For new specs, say "New spec created"
 - **Next Steps**: One actionable suggestion (e.g., "Run implementation" or "Review related spec at specs/auth.md")
+
+---
+
+## Non-interactive defaults
+
+If `AskUserQuestion` is unavailable (auto mode, headless agent, scheduled run), use these defaults and echo every defaulted decision in the Phase 5 report so the user can override.
+
+| Decision point | Default | Rationale |
+|---|---|---|
+| Phase 0: title matches multiple brain-storm files | Pick the file whose H1 exactly matches (case-insensitive) the argument; if still ambiguous, pick the first by alphabetical filename. | Determinism > guessing user intent. |
+| Phase 0: no input source resolvable (no arg, no conversation context) | Refuse: report "no spec source identified, please provide a brain-storm path or description." | Silent guessing produces wrong specs. |
+| Phase 2: exact match found | **Update** the existing spec, preserving any sections the user did not ask to change. | The intent is almost always "evolve the existing spec." |
+| Phase 2: related specs found | Proceed with a **new file**, listing the related specs in the report so the user can merge later if needed. | Avoid silent merges into adjacent specs. |
+| Phase 2: outdated specs found | Skip auto-update; list them in the report under "Outdated specs detected". | Phase 4 explicitly forbids auto-modify. |
+| Choosing phase + NN: ambiguous milestone | Use the **active phase** (highest existing) and append `NN+1`. Do not create a new phase automatically. | New phases imply a milestone boundary the user should own. |

writing-tasks-plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "writing-tasks-plugin",
   "description": "Decompose specs into persistent task files with dependency graph, parallel lane suggestion, and dynamic progress tracking",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "author": {
     "name": "Stefan Cho"
   }

writing-tasks-plugin/skills/writing-tasks/SKILL.md

@@ -49,11 +49,14 @@ estimate: "S" | "M" | "L"
 status: "todo" | "in_progress" | "review" | "done" | "blocked"
 owner: ""
 sprint: ""                  # optional, reserved for v2 filtering
+completed_at: ""            # optional, ISO date set by implement-with-test when status flips to done
 ---
 ```
 
 Reject writes if any required field (`id`, `phase`, `title`, `spec`, `depends_on`, `estimate`, `status`) is missing.
 
+Optional fields (`sprint`, `completed_at`) may be absent or empty. `completed_at` is set automatically by `implement-with-test` when the task transitions to `done`; treat any other value as user-authored.
+
 ## Commands
 
 Only two user-facing commands. Everything else is derived.
@@ -194,6 +197,7 @@ Reject if any fail:
 Warn (non-blocking):
 - Task with `depends_on: []` but body's "의존성" section is empty — prompt to add reasoning or mark as "독립 task".
 - Orphan task — task whose `spec:` was deleted (spec file no longer exists).
+- **Non-schema status value** — if `status` is anything other than the five enum values (e.g. `completed`, `partial`, `failed`), normalize it for dashboard purposes (`completed`→`done`, `failed`→`blocked`, `partial`→`review`) and warn. Do not auto-rewrite the file; surface the file path so the user can fix it.
 
 ## Incremental Updates
 
@@ -232,3 +236,15 @@ The skill detects `.claude/worktrees/task-N.NN-*` branch naming. When invoked in
 - Never create shared files the user didn't ask for. Only `tasks/phase-N-slug/NN-name.md`.
 - All user decisions go through `AskUserQuestion`.
 - When proposing decompositions, show the inference trail (which signal → which dependency) so the user can correct.
+
+## Non-interactive defaults
+
+If `AskUserQuestion` is unavailable (auto mode, headless agent, scheduled run), use these defaults and echo every defaulted decision back in the Step 4 report so the user can override.
+
+| Decision point | Default | Rationale |
+|---|---|---|
+| Decomposition proposal (`proceed/edit/cancel`) | `proceed` | The proposal is already grounded in the four signals; user can edit task files after. |
+| Phase slug for a brand-new phase | Derive from spec filename(s): kebab-case, drop trailing numbers, truncate to 3 words. Example: `specs/phase-3/01-profile-migration.md` → `phase-3-profile`. | Deterministic, recoverable. |
+| Modified spec encountered (resync diff?) | **Skip resync**, surface the orphan-warning style note in the report. | Never silently rewrite a task body that may have been hand-edited. |
+| Manual `/writing-tasks new` (phase / depends_on / estimate) | **Refuse** in non-interactive mode: report "manual task creation requires interactive input." | These are intent-heavy decisions; defaulting them silently produces wrong graphs. |
+| `depends_on: []` warning + empty 의존성 section | Auto-write `독립 task` placeholder in the body and warn in the report. | Keeps validation clean; warning surfaces it for human review. |