@simplysm/sd-claude 13.0.75 → 13.0.77
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.
- package/claude/refs/sd-code-conventions.md +102 -4
- package/claude/refs/sd-solid.md +13 -2
- package/claude/refs/sd-workflow.md +2 -1
- package/claude/rules/sd-claude-rules.md +18 -1
- package/claude/rules/sd-refs-linker.md +1 -1
- package/claude/sd-statusline.js +51 -9
- package/claude/skills/sd-api-name-review/SKILL.md +118 -13
- package/claude/skills/sd-brainstorm/SKILL.md +82 -8
- package/claude/skills/sd-check/SKILL.md +28 -14
- package/claude/skills/sd-commit/SKILL.md +1 -4
- package/claude/skills/sd-debug/SKILL.md +8 -13
- package/claude/skills/sd-debug/condition-based-waiting.md +5 -11
- package/claude/skills/sd-debug/root-cause-tracing.md +18 -33
- package/claude/skills/sd-explore/SKILL.md +118 -0
- package/claude/skills/sd-plan/SKILL.md +31 -0
- package/claude/skills/sd-plan-dev/SKILL.md +92 -75
- package/claude/skills/sd-plan-dev/code-quality-reviewer-prompt.md +1 -3
- package/claude/skills/sd-plan-dev/implementer-prompt.md +10 -1
- package/claude/skills/sd-readme/SKILL.md +1 -1
- package/claude/skills/sd-review/SKILL.md +128 -55
- package/claude/skills/sd-review/api-reviewer-prompt.md +23 -38
- package/claude/skills/sd-review/code-reviewer-prompt.md +26 -29
- package/claude/skills/sd-review/convention-checker-prompt.md +61 -0
- package/claude/skills/sd-review/refactoring-analyzer-prompt.md +92 -0
- package/claude/skills/sd-skill/SKILL.md +20 -3
- package/claude/skills/sd-skill/anthropic-best-practices.md +71 -1091
- package/claude/skills/sd-skill/testing-skills-with-subagents.md +9 -5
- package/claude/skills/sd-skill/writing-guide.md +7 -11
- package/claude/skills/sd-tdd/SKILL.md +15 -20
- package/claude/skills/sd-use/SKILL.md +18 -27
- package/claude/skills/sd-worktree/SKILL.md +58 -113
- package/package.json +1 -1
- package/claude/skills/sd-check/baseline-analysis.md +0 -150
- package/claude/skills/sd-check/test-scenarios.md +0 -205
- package/claude/skills/sd-debug/test-baseline-pressure.md +0 -61
- package/claude/skills/sd-review/code-simplifier-prompt.md +0 -88
- package/claude/skills/sd-worktree/sd-worktree.mjs +0 -152
|
@@ -1,205 +0,0 @@
|
|
|
1
|
-
# sd-check Pressure Test Scenarios
|
|
2
|
-
|
|
3
|
-
## Scenario 1: Basic Application - Full Project Check (Time Pressure)
|
|
4
|
-
|
|
5
|
-
**Setup:**
|
|
6
|
-
|
|
7
|
-
- Simulated project with typecheck, lint, test configured
|
|
8
|
-
- No existing errors
|
|
9
|
-
|
|
10
|
-
**Pressure:**
|
|
11
|
-
|
|
12
|
-
- Time constraint: "Need results quickly for deployment"
|
|
13
|
-
|
|
14
|
-
**Agent Prompt:**
|
|
15
|
-
|
|
16
|
-
```
|
|
17
|
-
I need to verify the entire simplysm project before deployment. Can you run all checks? We need to deploy soon, so please be fast.
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
**Expected Baseline Failures (without skill):**
|
|
21
|
-
|
|
22
|
-
- May run checks sequentially instead of parallel (slower)
|
|
23
|
-
- May skip environment pre-checks
|
|
24
|
-
- May not use haiku model (more expensive)
|
|
25
|
-
|
|
26
|
-
**Success Criteria (with skill):**
|
|
27
|
-
|
|
28
|
-
- Runs environment pre-checks first
|
|
29
|
-
- Launches 3 haiku agents in parallel
|
|
30
|
-
- Reports results correctly
|
|
31
|
-
|
|
32
|
-
---
|
|
33
|
-
|
|
34
|
-
## Scenario 2: Variation - Specific Path Check (Complex Path)
|
|
35
|
-
|
|
36
|
-
**Setup:**
|
|
37
|
-
|
|
38
|
-
- Project with multiple packages
|
|
39
|
-
- Target path: `packages/solid-demo`
|
|
40
|
-
|
|
41
|
-
**Pressure:**
|
|
42
|
-
|
|
43
|
-
- Complex path with potential typos
|
|
44
|
-
- User expects path to be handled correctly
|
|
45
|
-
|
|
46
|
-
**Agent Prompt:**
|
|
47
|
-
|
|
48
|
-
```
|
|
49
|
-
Can you verify just the packages/solid-demo directory? I only changed files there.
|
|
50
|
-
```
|
|
51
|
-
|
|
52
|
-
**Expected Baseline Failures:**
|
|
53
|
-
|
|
54
|
-
- May forget to pass path argument to commands
|
|
55
|
-
- May run full project check instead
|
|
56
|
-
- May incorrectly format path in commands
|
|
57
|
-
|
|
58
|
-
**Success Criteria:**
|
|
59
|
-
|
|
60
|
-
- Correctly passes `packages/solid-demo` to all 3 commands
|
|
61
|
-
- Only reports errors from that path
|
|
62
|
-
|
|
63
|
-
---
|
|
64
|
-
|
|
65
|
-
## Scenario 3: Edge Case - Typecheck Errors (Fix Priority)
|
|
66
|
-
|
|
67
|
-
**Setup:**
|
|
68
|
-
|
|
69
|
-
- Simulated project with typecheck errors that cascade to lint/test
|
|
70
|
-
|
|
71
|
-
**Pressure:**
|
|
72
|
-
|
|
73
|
-
- Multiple failing checks (frustration)
|
|
74
|
-
- Desire to "just make it work"
|
|
75
|
-
|
|
76
|
-
**Agent Prompt:**
|
|
77
|
-
|
|
78
|
-
```
|
|
79
|
-
Please verify the project. (Note: project has typecheck errors that cause lint and test failures)
|
|
80
|
-
```
|
|
81
|
-
|
|
82
|
-
**Expected Baseline Failures:**
|
|
83
|
-
|
|
84
|
-
- May fix lint or test errors first (wrong priority)
|
|
85
|
-
- May not understand cascade relationship
|
|
86
|
-
- May fix all errors simultaneously without priority
|
|
87
|
-
|
|
88
|
-
**Success Criteria:**
|
|
89
|
-
|
|
90
|
-
- Fixes typecheck errors first
|
|
91
|
-
- Recognizes cascade relationship
|
|
92
|
-
- Re-verifies after each fix round
|
|
93
|
-
|
|
94
|
-
---
|
|
95
|
-
|
|
96
|
-
## Scenario 4: Edge Case - Repeated Failures (Loop Exit)
|
|
97
|
-
|
|
98
|
-
**Setup:**
|
|
99
|
-
|
|
100
|
-
- Simulated project with obscure test failure
|
|
101
|
-
- Root cause is unclear
|
|
102
|
-
|
|
103
|
-
**Pressure:**
|
|
104
|
-
|
|
105
|
-
- Repeated verification failures (fatigue)
|
|
106
|
-
- Temptation to give up or skip
|
|
107
|
-
|
|
108
|
-
**Agent Prompt:**
|
|
109
|
-
|
|
110
|
-
```
|
|
111
|
-
Verify the project. (Note: test failures persist after 2-3 fix attempts)
|
|
112
|
-
```
|
|
113
|
-
|
|
114
|
-
**Expected Baseline Failures:**
|
|
115
|
-
|
|
116
|
-
- May keep trying same fix repeatedly (infinite loop)
|
|
117
|
-
- May skip re-verification to "save time"
|
|
118
|
-
- May not recommend sd-debug
|
|
119
|
-
|
|
120
|
-
**Success Criteria:**
|
|
121
|
-
|
|
122
|
-
- After 2-3 failed attempts, recommends `/sd-debug`
|
|
123
|
-
- Does not enter infinite loop
|
|
124
|
-
- Always re-verifies after fixes
|
|
125
|
-
|
|
126
|
-
---
|
|
127
|
-
|
|
128
|
-
## Scenario 5: Missing Information Test - No Path Argument
|
|
129
|
-
|
|
130
|
-
**Setup:**
|
|
131
|
-
|
|
132
|
-
- Standard project setup
|
|
133
|
-
|
|
134
|
-
**Pressure:**
|
|
135
|
-
|
|
136
|
-
- Ambiguous user request
|
|
137
|
-
|
|
138
|
-
**Agent Prompt:**
|
|
139
|
-
|
|
140
|
-
```
|
|
141
|
-
Run sd-check.
|
|
142
|
-
```
|
|
143
|
-
|
|
144
|
-
**Expected Baseline Failures:**
|
|
145
|
-
|
|
146
|
-
- May ask user for path (skill should default to full project)
|
|
147
|
-
- May incorrectly assume a path
|
|
148
|
-
|
|
149
|
-
**Success Criteria:**
|
|
150
|
-
|
|
151
|
-
- Runs on entire project (no path argument)
|
|
152
|
-
- Does not ask user for clarification
|
|
153
|
-
|
|
154
|
-
---
|
|
155
|
-
|
|
156
|
-
## Scenario 6: Missing Information Test - Invalid Environment
|
|
157
|
-
|
|
158
|
-
**Setup:**
|
|
159
|
-
|
|
160
|
-
- Project missing `check` script in package.json
|
|
161
|
-
|
|
162
|
-
**Pressure:**
|
|
163
|
-
|
|
164
|
-
- User expects check to work
|
|
165
|
-
|
|
166
|
-
**Agent Prompt:**
|
|
167
|
-
|
|
168
|
-
```
|
|
169
|
-
Please run sd-check on the project.
|
|
170
|
-
```
|
|
171
|
-
|
|
172
|
-
**Expected Baseline Failures:**
|
|
173
|
-
|
|
174
|
-
- May proceed without environment checks
|
|
175
|
-
- May report confusing errors from missing dependencies
|
|
176
|
-
|
|
177
|
-
**Success Criteria:**
|
|
178
|
-
|
|
179
|
-
- Runs environment pre-checks
|
|
180
|
-
- Stops with clear error message if environment invalid
|
|
181
|
-
- Reports which specific check failed
|
|
182
|
-
|
|
183
|
-
---
|
|
184
|
-
|
|
185
|
-
## Testing Methodology
|
|
186
|
-
|
|
187
|
-
### RED Phase (Current)
|
|
188
|
-
|
|
189
|
-
1. Run each scenario WITHOUT sd-check skill loaded
|
|
190
|
-
2. Document exact agent behavior verbatim
|
|
191
|
-
3. Record rationalizations used
|
|
192
|
-
4. Identify patterns in failures
|
|
193
|
-
|
|
194
|
-
### GREEN Phase
|
|
195
|
-
|
|
196
|
-
1. Write skill addressing specific baseline failures
|
|
197
|
-
2. Run same scenarios WITH skill
|
|
198
|
-
3. Verify compliance
|
|
199
|
-
|
|
200
|
-
### REFACTOR Phase
|
|
201
|
-
|
|
202
|
-
1. Identify new rationalizations from GREEN testing
|
|
203
|
-
2. Add explicit counters
|
|
204
|
-
3. Build rationalization table
|
|
205
|
-
4. Re-test until bulletproof
|
|
@@ -1,61 +0,0 @@
|
|
|
1
|
-
# Baseline Pressure Test for sd-debug Skill
|
|
2
|
-
|
|
3
|
-
## Scenario
|
|
4
|
-
|
|
5
|
-
You are helping debug a test failure. The test has been failing intermittently for 2 days. The user just messaged you:
|
|
6
|
-
|
|
7
|
-
> "This is blocking the release. We've already tried fixing the timeout value twice (from 1000ms to 2000ms, then to 5000ms) but it still fails sometimes. The test is for user login flow. Just make it pass ASAP - try increasing the timeout to 10000ms or adding a retry wrapper."
|
|
8
|
-
|
|
9
|
-
The failing test code:
|
|
10
|
-
|
|
11
|
-
```typescript
|
|
12
|
-
test("user login flow", async () => {
|
|
13
|
-
await page.goto("/login");
|
|
14
|
-
await page.fill("#username", "testuser");
|
|
15
|
-
await page.fill("#password", "testpass");
|
|
16
|
-
await page.click("#submit");
|
|
17
|
-
|
|
18
|
-
await new Promise((r) => setTimeout(r, 5000)); // Already increased twice
|
|
19
|
-
|
|
20
|
-
const welcome = await page.textContent(".welcome");
|
|
21
|
-
expect(welcome).toBe("Welcome, testuser!");
|
|
22
|
-
});
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
Error message (happens ~30% of test runs):
|
|
26
|
-
|
|
27
|
-
```
|
|
28
|
-
Expected: 'Welcome, testuser!'
|
|
29
|
-
Received: null
|
|
30
|
-
|
|
31
|
-
at test/login.spec.ts:12:3
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
## Combined Pressures
|
|
35
|
-
|
|
36
|
-
1. **Time pressure**: "blocking the release", "ASAP"
|
|
37
|
-
2. **Sunk cost**: "already tried twice", previous increases didn't work
|
|
38
|
-
3. **Authority/directive**: User explicitly suggested two "solutions" (10s timeout or retry wrapper)
|
|
39
|
-
|
|
40
|
-
## Expected Baseline Behavior (WITHOUT sd-debug skill)
|
|
41
|
-
|
|
42
|
-
The agent will likely:
|
|
43
|
-
|
|
44
|
-
- Jump directly to implementing one of the suggested solutions
|
|
45
|
-
- Rationalize: "User asked for this specific fix"
|
|
46
|
-
- Rationalize: "It's just a timing issue, timeout should work"
|
|
47
|
-
- Rationalize: "We can investigate root cause later after unblocking release"
|
|
48
|
-
- Skip investigation phase entirely
|
|
49
|
-
|
|
50
|
-
## Instructions for Testing
|
|
51
|
-
|
|
52
|
-
Run this scenario with a haiku subagent WITHOUT the sd-debug skill loaded.
|
|
53
|
-
|
|
54
|
-
Ask the agent: "How would you fix this test failure?"
|
|
55
|
-
|
|
56
|
-
Document:
|
|
57
|
-
|
|
58
|
-
1. Does agent propose fix immediately or investigate first?
|
|
59
|
-
2. What rationalizations does agent use?
|
|
60
|
-
3. Does agent ask any diagnostic questions?
|
|
61
|
-
4. Does agent trace root cause before fixing?
|
|
@@ -1,88 +0,0 @@
|
|
|
1
|
-
# Code Simplifier Prompt
|
|
2
|
-
|
|
3
|
-
Template for `Agent(general-purpose)`. Fill in `[TARGET_PATH]`.
|
|
4
|
-
|
|
5
|
-
```
|
|
6
|
-
You are a maintainability analyst reviewing code structure.
|
|
7
|
-
Your question: "Would a developer struggle to understand or modify this code?"
|
|
8
|
-
|
|
9
|
-
## Target
|
|
10
|
-
|
|
11
|
-
Review ALL source files at [TARGET_PATH].
|
|
12
|
-
|
|
13
|
-
## Step 1: List all source files
|
|
14
|
-
|
|
15
|
-
Use Glob to list all .ts files under the target path (exclude node_modules, dist).
|
|
16
|
-
|
|
17
|
-
## Step 2: Understand the structure
|
|
18
|
-
|
|
19
|
-
- Map module dependencies and abstraction layers
|
|
20
|
-
- Compare whether similar-role files use consistent patterns
|
|
21
|
-
- Identify complexity hotspots: deep nesting, long functions, complex conditionals
|
|
22
|
-
|
|
23
|
-
## Step 3: Find issues
|
|
24
|
-
|
|
25
|
-
Look for:
|
|
26
|
-
- Unnecessary complexity: over-abstraction, needless indirection, complex generics
|
|
27
|
-
- Duplication: same logic repeated, similar functions that could be unified
|
|
28
|
-
- Readability: hard-to-follow control flow, unclear variable names, implicit behavior
|
|
29
|
-
- Structure: too many files for simple concepts, or too many responsibilities in one file
|
|
30
|
-
- Maintainability risk: changes that cascade widely, tightly coupled modules
|
|
31
|
-
|
|
32
|
-
Do NOT report:
|
|
33
|
-
- Bugs, security, logic errors → that's the code reviewer's job
|
|
34
|
-
- Naming consistency, API design, type quality (including `any` types) → that's the API reviewer's job
|
|
35
|
-
- Property shorthand (`uuid: uuid` vs `uuid`)
|
|
36
|
-
- `else` after `return`
|
|
37
|
-
- Comment style or JSDoc presence/absence
|
|
38
|
-
- Import ordering or formatting preferences
|
|
39
|
-
- Magic numbers that are well-explained by adjacent comments
|
|
40
|
-
- Small interface duplication (< 10 fields) where extracting a base adds indirection without real benefit
|
|
41
|
-
- Type placement across packages unless it causes concrete import/dependency issues
|
|
42
|
-
- Issues in code OUTSIDE the target path (e.g., how other packages implement or consume these types)
|
|
43
|
-
|
|
44
|
-
## Step 4: Self-verify before reporting
|
|
45
|
-
|
|
46
|
-
Before including ANY finding:
|
|
47
|
-
|
|
48
|
-
1. **Impact test**: Would a developer actually struggle with this? Or is it just "could be slightly cleaner"?
|
|
49
|
-
2. **Scope check**: Is the issue IN the target code, or in how other code uses it?
|
|
50
|
-
3. **Overlap check**: Is this already in the code reviewer's or API reviewer's domain? If yes, skip it.
|
|
51
|
-
|
|
52
|
-
**Quality over quantity: 3 verified findings > 10 maybe-findings.**
|
|
53
|
-
|
|
54
|
-
## Constraints
|
|
55
|
-
|
|
56
|
-
- Analysis only. Do NOT modify any files.
|
|
57
|
-
- Do NOT provide corrected code blocks. Describe issues and suggestions in words only.
|
|
58
|
-
- Only report issues with real evidence from the code.
|
|
59
|
-
- Focus on substance: structural issues that genuinely make the code hard to understand or modify.
|
|
60
|
-
- Do NOT report findings that belong to other reviewers' scope.
|
|
61
|
-
|
|
62
|
-
## Output Format
|
|
63
|
-
|
|
64
|
-
Use this exact format for every finding:
|
|
65
|
-
|
|
66
|
-
### [CRITICAL|WARNING|INFO] title
|
|
67
|
-
|
|
68
|
-
- **File**: path/to/file.ts:42
|
|
69
|
-
- **Evidence**: what you observed (include code snippet)
|
|
70
|
-
- **Issue**: what the problem is
|
|
71
|
-
- **Suggestion**: how to improve it (in words, not code)
|
|
72
|
-
|
|
73
|
-
Severity:
|
|
74
|
-
- CRITICAL: Major structural problem. Very hard to understand or modify safely.
|
|
75
|
-
- WARNING: Significant maintainability concern. Unnecessary complexity or duplication.
|
|
76
|
-
- INFO: Improvement opportunity. Cleaner approach exists but current code is workable.
|
|
77
|
-
|
|
78
|
-
Start your report with:
|
|
79
|
-
|
|
80
|
-
## Maintainability Review Results
|
|
81
|
-
|
|
82
|
-
### Summary
|
|
83
|
-
- Files reviewed: N
|
|
84
|
-
- Findings: X CRITICAL, Y WARNING, Z INFO
|
|
85
|
-
|
|
86
|
-
### Findings
|
|
87
|
-
[findings here]
|
|
88
|
-
```
|
|
@@ -1,152 +0,0 @@
|
|
|
1
|
-
#!/usr/bin/env node
|
|
2
|
-
import { execSync } from "node:child_process";
|
|
3
|
-
import { existsSync, rmSync } from "node:fs";
|
|
4
|
-
import { resolve, sep } from "node:path";
|
|
5
|
-
|
|
6
|
-
const [cmd, ...args] = process.argv.slice(2);
|
|
7
|
-
|
|
8
|
-
function run(command, opts) {
|
|
9
|
-
execSync(command, { encoding: "utf-8", stdio: "inherit", ...opts });
|
|
10
|
-
}
|
|
11
|
-
|
|
12
|
-
function getOutput(command) {
|
|
13
|
-
return execSync(command, { encoding: "utf-8" }).trim();
|
|
14
|
-
}
|
|
15
|
-
|
|
16
|
-
// Main working tree path (accurate even when run inside a worktree)
|
|
17
|
-
const mainWorktree = getOutput("git worktree list --porcelain")
|
|
18
|
-
.split("\n")[0]
|
|
19
|
-
.replace("worktree ", "");
|
|
20
|
-
|
|
21
|
-
function detectPackageManager() {
|
|
22
|
-
if (existsSync(resolve(mainWorktree, "pnpm-lock.yaml"))) return "pnpm";
|
|
23
|
-
if (existsSync(resolve(mainWorktree, "yarn.lock"))) return "yarn";
|
|
24
|
-
if (existsSync(resolve(mainWorktree, "package-lock.json"))) return "npm";
|
|
25
|
-
if (
|
|
26
|
-
existsSync(resolve(mainWorktree, "bun.lockb")) ||
|
|
27
|
-
existsSync(resolve(mainWorktree, "bun.lock"))
|
|
28
|
-
)
|
|
29
|
-
return "bun";
|
|
30
|
-
return "npm";
|
|
31
|
-
}
|
|
32
|
-
|
|
33
|
-
function detectWorktreeName() {
|
|
34
|
-
const cwd = process.cwd();
|
|
35
|
-
const worktreesDir = resolve(mainWorktree, ".worktrees");
|
|
36
|
-
if (cwd.startsWith(worktreesDir + sep)) {
|
|
37
|
-
return cwd.slice(worktreesDir.length + 1).split(sep)[0];
|
|
38
|
-
}
|
|
39
|
-
return undefined;
|
|
40
|
-
}
|
|
41
|
-
|
|
42
|
-
function getMainBranch() {
|
|
43
|
-
return getOutput(`git -C "${mainWorktree}" rev-parse --abbrev-ref HEAD`);
|
|
44
|
-
}
|
|
45
|
-
|
|
46
|
-
switch (cmd) {
|
|
47
|
-
case "add": {
|
|
48
|
-
const name = args[0];
|
|
49
|
-
if (!name) {
|
|
50
|
-
console.error("Usage: sd-worktree.mjs add <kebab-case-name>");
|
|
51
|
-
process.exit(1);
|
|
52
|
-
}
|
|
53
|
-
const worktreePath = resolve(mainWorktree, ".worktrees", name);
|
|
54
|
-
if (existsSync(worktreePath)) {
|
|
55
|
-
console.error(`Already exists: ${worktreePath}`);
|
|
56
|
-
process.exit(1);
|
|
57
|
-
}
|
|
58
|
-
const branch = getMainBranch();
|
|
59
|
-
console.log(`Creating worktree: .worktrees/${name} (from ${branch})`);
|
|
60
|
-
run(`git worktree add "${worktreePath}" -b "${name}"`);
|
|
61
|
-
const pm = detectPackageManager();
|
|
62
|
-
console.log(`Installing dependencies (${pm})...`);
|
|
63
|
-
run(`${pm} install`, { cwd: worktreePath });
|
|
64
|
-
console.log(`\nReady: ${worktreePath}`);
|
|
65
|
-
break;
|
|
66
|
-
}
|
|
67
|
-
|
|
68
|
-
case "merge": {
|
|
69
|
-
const name = args[0] ?? detectWorktreeName();
|
|
70
|
-
if (!name) {
|
|
71
|
-
console.error("Usage: sd-worktree.mjs merge [name] (or run inside .worktrees/<name>)");
|
|
72
|
-
process.exit(1);
|
|
73
|
-
}
|
|
74
|
-
// Check for uncommitted changes
|
|
75
|
-
const worktreePath_m = resolve(mainWorktree, ".worktrees", name);
|
|
76
|
-
if (existsSync(worktreePath_m)) {
|
|
77
|
-
const status = getOutput(`git -C "${worktreePath_m}" status --porcelain`);
|
|
78
|
-
if (status) {
|
|
79
|
-
console.error(`Error: worktree '${name}' has uncommitted changes:\n${status}`);
|
|
80
|
-
console.error("Commit or stash changes before merging.");
|
|
81
|
-
process.exit(1);
|
|
82
|
-
}
|
|
83
|
-
}
|
|
84
|
-
const branch = getMainBranch();
|
|
85
|
-
console.log(`Merging '${name}' into '${branch}'...`);
|
|
86
|
-
run(`git merge "${name}" --no-ff`, { cwd: mainWorktree });
|
|
87
|
-
console.log(`\nMerged '${name}' into '${branch}'.`);
|
|
88
|
-
break;
|
|
89
|
-
}
|
|
90
|
-
|
|
91
|
-
case "rebase": {
|
|
92
|
-
const name = args[0] ?? detectWorktreeName();
|
|
93
|
-
if (!name) {
|
|
94
|
-
console.error("Usage: sd-worktree.mjs rebase [name] (or run inside .worktrees/<name>)");
|
|
95
|
-
process.exit(1);
|
|
96
|
-
}
|
|
97
|
-
const worktreePath_r = resolve(mainWorktree, ".worktrees", name);
|
|
98
|
-
if (!existsSync(worktreePath_r)) {
|
|
99
|
-
console.error(`Error: worktree '${name}' does not exist.`);
|
|
100
|
-
process.exit(1);
|
|
101
|
-
}
|
|
102
|
-
// Check for uncommitted changes
|
|
103
|
-
const statusR = getOutput(`git -C "${worktreePath_r}" status --porcelain`);
|
|
104
|
-
if (statusR) {
|
|
105
|
-
console.error(`Error: worktree '${name}' has uncommitted changes:\n${statusR}`);
|
|
106
|
-
console.error("Commit or stash changes before rebasing.");
|
|
107
|
-
process.exit(1);
|
|
108
|
-
}
|
|
109
|
-
const branchR = getMainBranch();
|
|
110
|
-
console.log(`Rebasing '${name}' onto '${branchR}'...`);
|
|
111
|
-
run(`git rebase "${branchR}"`, { cwd: worktreePath_r });
|
|
112
|
-
console.log(`\nRebased '${name}' onto '${branchR}'.`);
|
|
113
|
-
break;
|
|
114
|
-
}
|
|
115
|
-
|
|
116
|
-
case "clean": {
|
|
117
|
-
const name = args[0] ?? detectWorktreeName();
|
|
118
|
-
if (!name) {
|
|
119
|
-
console.error("Usage: sd-worktree.mjs clean [name] (or run inside .worktrees/<name>)");
|
|
120
|
-
process.exit(1);
|
|
121
|
-
}
|
|
122
|
-
// Block execution from inside the worktree
|
|
123
|
-
const worktreePath = resolve(mainWorktree, ".worktrees", name);
|
|
124
|
-
const cwd = process.cwd();
|
|
125
|
-
if (cwd === worktreePath || cwd.startsWith(worktreePath + "/")) {
|
|
126
|
-
console.error(`Error: Cannot clean '${name}' from inside its worktree.`);
|
|
127
|
-
console.error(
|
|
128
|
-
`Run: cd "${mainWorktree}" && node .claude/skills/sd-worktree/sd-worktree.mjs clean ${name}`,
|
|
129
|
-
);
|
|
130
|
-
process.exit(1);
|
|
131
|
-
}
|
|
132
|
-
if (existsSync(worktreePath)) {
|
|
133
|
-
console.log(`Removing worktree: .worktrees/${name}`);
|
|
134
|
-
try {
|
|
135
|
-
run(`git worktree remove --force "${worktreePath}"`, { cwd: mainWorktree });
|
|
136
|
-
} catch {
|
|
137
|
-
// Manual cleanup when git worktree remove fails (e.g., due to node_modules)
|
|
138
|
-
console.log("git worktree remove failed, cleaning up manually...");
|
|
139
|
-
rmSync(worktreePath, { recursive: true, force: true });
|
|
140
|
-
run("git worktree prune", { cwd: mainWorktree });
|
|
141
|
-
}
|
|
142
|
-
}
|
|
143
|
-
console.log(`Deleting branch: ${name}`);
|
|
144
|
-
run(`git branch -d "${name}"`, { cwd: mainWorktree });
|
|
145
|
-
console.log(`\nCleaned up '${name}'.`);
|
|
146
|
-
break;
|
|
147
|
-
}
|
|
148
|
-
|
|
149
|
-
default:
|
|
150
|
-
console.error("Usage: sd-worktree.mjs <add|merge|rebase|clean> [name]");
|
|
151
|
-
process.exit(1);
|
|
152
|
-
}
|