@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.
Files changed (37) hide show
  1. package/claude/refs/sd-code-conventions.md +102 -4
  2. package/claude/refs/sd-solid.md +13 -2
  3. package/claude/refs/sd-workflow.md +2 -1
  4. package/claude/rules/sd-claude-rules.md +18 -1
  5. package/claude/rules/sd-refs-linker.md +1 -1
  6. package/claude/sd-statusline.js +51 -9
  7. package/claude/skills/sd-api-name-review/SKILL.md +118 -13
  8. package/claude/skills/sd-brainstorm/SKILL.md +82 -8
  9. package/claude/skills/sd-check/SKILL.md +28 -14
  10. package/claude/skills/sd-commit/SKILL.md +1 -4
  11. package/claude/skills/sd-debug/SKILL.md +8 -13
  12. package/claude/skills/sd-debug/condition-based-waiting.md +5 -11
  13. package/claude/skills/sd-debug/root-cause-tracing.md +18 -33
  14. package/claude/skills/sd-explore/SKILL.md +118 -0
  15. package/claude/skills/sd-plan/SKILL.md +31 -0
  16. package/claude/skills/sd-plan-dev/SKILL.md +92 -75
  17. package/claude/skills/sd-plan-dev/code-quality-reviewer-prompt.md +1 -3
  18. package/claude/skills/sd-plan-dev/implementer-prompt.md +10 -1
  19. package/claude/skills/sd-readme/SKILL.md +1 -1
  20. package/claude/skills/sd-review/SKILL.md +128 -55
  21. package/claude/skills/sd-review/api-reviewer-prompt.md +23 -38
  22. package/claude/skills/sd-review/code-reviewer-prompt.md +26 -29
  23. package/claude/skills/sd-review/convention-checker-prompt.md +61 -0
  24. package/claude/skills/sd-review/refactoring-analyzer-prompt.md +92 -0
  25. package/claude/skills/sd-skill/SKILL.md +20 -3
  26. package/claude/skills/sd-skill/anthropic-best-practices.md +71 -1091
  27. package/claude/skills/sd-skill/testing-skills-with-subagents.md +9 -5
  28. package/claude/skills/sd-skill/writing-guide.md +7 -11
  29. package/claude/skills/sd-tdd/SKILL.md +15 -20
  30. package/claude/skills/sd-use/SKILL.md +18 -27
  31. package/claude/skills/sd-worktree/SKILL.md +58 -113
  32. package/package.json +1 -1
  33. package/claude/skills/sd-check/baseline-analysis.md +0 -150
  34. package/claude/skills/sd-check/test-scenarios.md +0 -205
  35. package/claude/skills/sd-debug/test-baseline-pressure.md +0 -61
  36. package/claude/skills/sd-review/code-simplifier-prompt.md +0 -88
  37. 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
- }