@simplysm/claude 13.0.0-beta.41 → 13.0.0-beta.43
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -81,7 +81,13 @@ pnpm vitest $ARGUMENTS --run
|
|
|
81
81
|
Run with `--run` flag for single execution (no watch mode).
|
|
82
82
|
Some packages may require integration tests as configured in vitest.config.ts.
|
|
83
83
|
|
|
84
|
-
On failure:
|
|
84
|
+
On failure:
|
|
85
|
+
|
|
86
|
+
1. **Check git diff**: Run `git diff` (staged + unstaged) to identify intentional code changes.
|
|
87
|
+
2. **Determine root cause**: Check whether the test failure is caused by intentional code changes (feature changes, API changes, behavior changes) that haven't been reflected in tests yet.
|
|
88
|
+
- **Intentional changes not reflected in tests**: Update the **test code** to match the new behavior, not the source code.
|
|
89
|
+
- **Source code bug**: Fix the source code.
|
|
90
|
+
3. Re-run tests after the fix.
|
|
85
91
|
|
|
86
92
|
## Completion Criteria
|
|
87
93
|
|
|
@@ -8,8 +8,8 @@ model: haiku
|
|
|
8
8
|
|
|
9
9
|
## Mode
|
|
10
10
|
|
|
11
|
-
-
|
|
12
|
-
-
|
|
11
|
+
- **"all" mode** (`$ARGUMENTS` is "all"): Target is **all** changed/untracked files. May split into multiple commits (see Commit Strategy).
|
|
12
|
+
- **Default mode** (no arguments): Target is only the files relevant to the current conversation context. Always a **single commit**.
|
|
13
13
|
|
|
14
14
|
## Context
|
|
15
15
|
|
|
@@ -38,11 +38,30 @@ Examples:
|
|
|
38
38
|
|
|
39
39
|
Use a HEREDOC for multi-line messages when needed.
|
|
40
40
|
|
|
41
|
+
## Commit Strategy (all mode only)
|
|
42
|
+
|
|
43
|
+
In "all" mode, analyze the changes and decide whether to create a **single commit** or **split into multiple commits**:
|
|
44
|
+
|
|
45
|
+
Group changes by **intent/purpose**, not by package. Files across multiple packages that share the same intent belong in one commit.
|
|
46
|
+
|
|
47
|
+
**Single commit examples:**
|
|
48
|
+
- Version bumps across all `package.json` files → `chore: bump version to x.y.z`
|
|
49
|
+
- A feature spanning `orm-common` + `orm-node` + `service-server` → one `feat` commit
|
|
50
|
+
- Dependency updates across multiple packages → one `chore` commit
|
|
51
|
+
|
|
52
|
+
**Split commit examples:**
|
|
53
|
+
- Version bumps + an unrelated bug fix in `solid` → separate `chore` + `fix` commits
|
|
54
|
+
- A `feat` in `solid` + a `refactor` in `core-common` with no relation → two commits
|
|
55
|
+
- `docs` changes + `feat` changes that are independent → two commits
|
|
56
|
+
|
|
41
57
|
## Your task
|
|
42
58
|
|
|
43
|
-
|
|
59
|
+
**Default mode:**
|
|
60
|
+
- Stage only the context-relevant files with `git add <file>...`, then `git commit` (single commit).
|
|
44
61
|
|
|
45
|
-
|
|
46
|
-
|
|
62
|
+
**All mode:**
|
|
63
|
+
1. Decide: single commit or split commits.
|
|
64
|
+
2. If single: run `git add .` then `git commit`.
|
|
65
|
+
3. If splitting: group files by logical unit, create commits in dependency order (foundations first). For each group, `git add <files>...` then `git commit`.
|
|
47
66
|
|
|
48
|
-
You have the capability to call multiple tools in a single response.
|
|
67
|
+
You have the capability to call multiple tools in a single response. When creating a single commit, stage and commit in one message. When splitting, execute each commit sequentially. Do not use any other tools or do anything else. Do not send any other text or messages besides these tool calls.
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sd-design-dev
|
|
3
|
+
description: Use when brainstorming is complete and the user wants to proceed with planning and implementation - orchestrates worktree setup, planning, and execution
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Design to Development Pipeline
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Orchestrate the full design-to-development pipeline after sd-brainstorm. Asks about branch isolation, then chains the right skills automatically.
|
|
11
|
+
|
|
12
|
+
## The Process
|
|
13
|
+
|
|
14
|
+
```dot
|
|
15
|
+
digraph pipeline {
|
|
16
|
+
rankdir=TB;
|
|
17
|
+
|
|
18
|
+
"Ask: use worktree?" [shape=diamond];
|
|
19
|
+
|
|
20
|
+
subgraph cluster_worktree {
|
|
21
|
+
label="With Worktree";
|
|
22
|
+
"Skill: sd-worktree add" [shape=box];
|
|
23
|
+
}
|
|
24
|
+
|
|
25
|
+
"Skill: sd-plan" [shape=box];
|
|
26
|
+
"Skill: sd-plan-dev" [shape=box];
|
|
27
|
+
"Guide: sd-worktree merge/clean" [shape=box, style=dashed];
|
|
28
|
+
"Done" [shape=ellipse];
|
|
29
|
+
|
|
30
|
+
"Ask: use worktree?" -> "Skill: sd-worktree add" [label="yes"];
|
|
31
|
+
"Ask: use worktree?" -> "Skill: sd-plan" [label="no"];
|
|
32
|
+
"Skill: sd-worktree add" -> "Skill: sd-plan";
|
|
33
|
+
"Skill: sd-plan" -> "Skill: sd-plan-dev";
|
|
34
|
+
"Skill: sd-plan-dev" -> "Guide: sd-worktree merge/clean" [label="if worktree"];
|
|
35
|
+
"Skill: sd-plan-dev" -> "Done" [label="if no worktree"];
|
|
36
|
+
"Guide: sd-worktree merge/clean" -> "Done";
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
### Step 1: Ask about worktree
|
|
41
|
+
|
|
42
|
+
Ask the user (via AskUserQuestion):
|
|
43
|
+
|
|
44
|
+
> "Worktree로 브랜치를 분리할까요?"
|
|
45
|
+
> - Yes (Recommended) — 별도 브랜치에서 작업 후 merge
|
|
46
|
+
> - No — 현재 브랜치에서 직접 작업
|
|
47
|
+
|
|
48
|
+
### Step 2: Worktree setup (if yes)
|
|
49
|
+
|
|
50
|
+
Invoke `/sd-worktree` with `add` and the feature name derived from the brainstorm context.
|
|
51
|
+
|
|
52
|
+
After worktree is created, continue to Step 3 (do NOT stop).
|
|
53
|
+
|
|
54
|
+
### Step 3: Plan
|
|
55
|
+
|
|
56
|
+
Invoke `/sd-plan` — creates the implementation plan from the design.
|
|
57
|
+
|
|
58
|
+
After plan is saved and user approves, continue to Step 4 (do NOT stop).
|
|
59
|
+
|
|
60
|
+
### Step 4: Execute
|
|
61
|
+
|
|
62
|
+
Invoke `/sd-plan-dev` — executes the plan task-by-task with parallel agents and reviews.
|
|
63
|
+
|
|
64
|
+
### Step 5: Post-completion guide (worktree only)
|
|
65
|
+
|
|
66
|
+
If a worktree was created in Step 2, inform the user:
|
|
67
|
+
|
|
68
|
+
> "구현이 완료되었습니다. 다음 명령으로 merge 및 정리를 진행하세요:"
|
|
69
|
+
> 1. `/sd-worktree merge` — worktree 브랜치를 main에 merge
|
|
70
|
+
> 2. `/sd-worktree clean <name>` — worktree 제거 및 브랜치 삭제
|
|
71
|
+
|
|
72
|
+
Do NOT execute merge/clean automatically.
|
|
73
|
+
|
|
74
|
+
## Key Rules
|
|
75
|
+
|
|
76
|
+
- Each skill invocation follows that skill's own process completely
|
|
77
|
+
- Do NOT skip any skill in the chain
|
|
78
|
+
- If any skill asks for user input, wait for the answer before proceeding
|
|
79
|
+
- After sd-plan-dev completes, do NOT auto-merge — guide only
|
package/package.json
CHANGED