@simplysm/sd-claude 13.0.39 → 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,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
|
-
```
|