@simplysm/sd-claude 13.0.40 → 13.0.41

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.
@@ -0,0 +1,34 @@
1
+ # Code Conventions
2
+
3
+ ## Generic Type Parameters
4
+
5
+ - Always use descriptive names — single-letter `T` alone is not allowed
6
+ - Use `T` prefix + descriptive name: `TItem`, `TData`, `TResult`, `TKey`, `TValue`, `TAuthInfo`
7
+
8
+ ## Prototype Extensions
9
+
10
+ Importing `@simplysm/core-common` adds extension methods to Array, Map, Set:
11
+ - `Array`: `single()`, `filterExists()`, `groupBy()`, `orderBy()`, etc.
12
+ - `Map`: `getOrCreate()`, `update()`
13
+ - `Set`: `adds()`, `toggle()`
14
+
15
+ Before using extension methods: Verify actual existence in `@simplysm/core-common` extensions (check README or source). Do not guess methods that don't exist.
16
+
17
+ ## Function Naming Conventions
18
+
19
+ - Do not use `Async` suffix on function names — Async is the default
20
+ - When both sync and async versions exist, use `Sync` suffix on the sync function
21
+
22
+ ```typescript
23
+ // Good
24
+ async function readFile() { ... } // Async (default)
25
+ function readFileSync() { ... } // Sync version
26
+
27
+ // Bad
28
+ async function readFileAsync() { ... } // Async suffix prohibited
29
+ ```
30
+
31
+ ## JSDoc Convention
32
+
33
+ - Not enforced — omit when code is self-explanatory
34
+ - When written, use Korean
@@ -0,0 +1,7 @@
1
+ # Directory Reference
2
+
3
+ - `.cache/`: Build cache (`eslint.cache`, `typecheck-{env}.tsbuildinfo`, `dts.tsbuildinfo`). Reset: delete `.cache/`
4
+ - `.playwright-mcp/`: Playwright MCP output directory
5
+ - Screenshots/snapshots must always be saved to the `.playwright-mcp/` directory
6
+ - When calling `browser_take_screenshot`, always prefix filename with `.playwright-mcp/` (e.g., `.playwright-mcp/screenshot.png`)
7
+ - `PLAYWRIGHT_OUTPUT_DIR` only applies to auto-generated filenames; explicitly specified filenames are resolved relative to cwd
@@ -4,4 +4,3 @@ Respond in the **system's configured language** (set via Claude Code's language
4
4
 
5
5
  - Technical terms, code identifiers (variable names, function names, etc.), and library names should remain as-is
6
6
  - Show English error messages and logs in their original form, but provide explanations in the system language
7
- - Files in `.claude/` folder and each package's `README.md` are written in English for consistent documentation
@@ -1,3 +1,18 @@
1
1
  # Workflow Rules
2
2
 
3
3
  - **No auto-proceeding after skill completion**: When the user explicitly invokes a skill, report the result and **stop** once the skill finishes. Do not guess the next step and proceed arbitrarily. Wait for explicit user instructions if further work is needed.
4
+
5
+ ## Problem-Solving Principles
6
+
7
+ - **Root cause first**: When encountering errors or unexpected behavior, always investigate the root cause before attempting a fix. Do not apply workarounds, hacks, or surface-level patches.
8
+ - **No band-aid fixes**: Avoid techniques like suppressing errors, adding defensive checks to hide symptoms, or bypassing validation. These mask the real problem and create technical debt.
9
+ - **Consider refactoring**: If the root cause reveals a design flaw or structural issue, propose a refactoring approach rather than working around it. A proper fix — even if larger in scope — is better than a fragile workaround.
10
+ - **Trace the full chain**: Follow the error or issue through the entire call chain (caller -> callee -> dependencies) to understand why it happens, not just where it happens.
11
+ - **When uncertain, ask**: If the root cause is unclear or the fix requires significant changes, discuss with the user before proceeding. Present findings and options rather than silently applying a quick fix.
12
+
13
+ ## Pre-coding Checklist
14
+
15
+ - Before creating new files: Glob/Read similar existing files to check structure and patterns
16
+ - Before modifying functions/classes: Read the file to understand existing code style
17
+ - When unsure about API/method usage: Check signatures in source code
18
+ - **If confidence is low, ask the user instead of writing code**
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@simplysm/sd-claude",
3
- "version": "13.0.40",
3
+ "version": "13.0.41",
4
4
  "description": "Simplysm Claude Code CLI — asset installer and cross-platform npx wrapper",
5
5
  "author": "김석래",
6
6
  "license": "Apache-2.0",
@@ -1,13 +0,0 @@
1
- # Function Naming Conventions
2
-
3
- - Do not use `Async` suffix on function names — Async is the default
4
- - When both sync and async versions exist, use `Sync` suffix on the sync function
5
-
6
- ```typescript
7
- // Good
8
- async function readFile() { ... } // Async (default)
9
- function readFileSync() { ... } // Sync version
10
-
11
- // Bad
12
- async function readFileAsync() { ... } // Async suffix prohibited
13
- ```