@simplysm/sd-claude 13.0.59 → 13.0.61

package/claude/agents/sd-api-reviewer.md

@@ -62,6 +62,7 @@ Start with a brief summary of the package's public API surface.
 ### Findings by Category
 
 For each high-confidence issue:
+
 - Clear description with confidence score
 - File path and relevant export/type
 - Comparison with industry standard libraries (if applicable)
@@ -69,12 +70,12 @@ For each high-confidence issue:
 
 ### Priority
 
-| Priority | Criteria |
-|----------|----------|
-| **P0** | API misuse likely — naming misleads or types insufficient |
-| **P1** | Significant friction — unnecessary complexity or inconsistency |
-| **P2** | Minor improvement — better naming or defaults exist |
-| **Keep** | Already aligned with standards |
+| Priority | Criteria                                                       |
+| -------- | -------------------------------------------------------------- |
+| **P0**   | API misuse likely — naming misleads or types insufficient      |
+| **P1**   | Significant friction — unnecessary complexity or inconsistency |
+| **P2**   | Minor improvement — better naming or defaults exist            |
+| **Keep** | Already aligned with standards                                 |
 
 ### Summary Table
 

package/claude/agents/sd-code-simplifier.md

@@ -11,14 +11,12 @@ You will analyze recently modified code and apply refinements that:
 1. **Preserve Functionality**: Never change what the code does - only how it does it. All original features, outputs, and behaviors must remain intact.
 
 2. **Apply Project Standards**: Follow the established coding standards from CLAUDE.md including:
-
    - Import patterns, module structure, and naming conventions
    - Framework-specific component patterns (as defined in CLAUDE.md)
    - Error handling patterns
    - Type annotation conventions
 
 3. **Enhance Clarity**: Simplify code structure by:
-
    - Reducing unnecessary complexity and nesting
    - Eliminating redundant code and abstractions
    - Improving readability through clear variable and function names
@@ -28,7 +26,6 @@ You will analyze recently modified code and apply refinements that:
    - Choose clarity over brevity - explicit code is often better than overly compact code
 
 4. **Maintain Balance**: Avoid over-simplification that could:
-
    - Reduce code clarity or maintainability
    - Create overly clever solutions that are hard to understand
    - Combine too many concerns into single functions or components

package/claude/agents/sd-security-reviewer.md

@@ -12,6 +12,7 @@ simplysm ORM uses **string escaping** (NOT parameter binding) for SQL generation
 This means application-level input validation is the PRIMARY defense against SQL injection.
 
 ### Escaping mechanisms in place:
+
 - MySQL: Backslashes, quotes, NULL bytes, control characters escaped
 - Forces utf8mb4 charset (defends against multi-byte attacks)
 - These are necessary but NOT sufficient without input validation
@@ -25,16 +26,19 @@ By default, review unstaged changes from `git diff` that touch ORM queries or se
 For every ORM query in the diff, verify:
 
 ### 1. Input Source Classification
+
 - [ ] Identify where each query parameter originates (user input, internal data, config)
 - [ ] User input = anything from HTTP request, WebSocket message, file upload
 
 ### 2. Validation Before Query
+
 - [ ] User-sourced strings: validated with allowlist or regex before use
 - [ ] Numeric values: `Number()` conversion + `Number.isNaN()` check
 - [ ] Enum values: checked against valid set before use
 - [ ] No raw `req.query`, `req.params`, `req.body` values passed to ORM
 
 ### 3. Service Endpoint Review
+
 - [ ] All ServiceServer RPC handlers validate incoming arguments
 - WebSocket message payloads validated before ORM usage
 - [ ] Type coercion applied at service boundary
@@ -44,16 +48,22 @@ For every ORM query in the diff, verify:
 ```typescript
 // DANGEROUS: Direct user input in query
 const name = req.query.name;
-db.user().where((u) => [expr.eq(u.name, name)]).result();
+db.user()
+  .where((u) => [expr.eq(u.name, name)])
+  .result();
 
 // SAFE: Validated first
 const name = validateString(req.query.name, { maxLength: 100 });
-db.user().where((u) => [expr.eq(u.name, name)]).result();
+db.user()
+  .where((u) => [expr.eq(u.name, name)])
+  .result();
 
 // SAFE: Type coercion with check
 const id = Number(req.query.id);
 if (Number.isNaN(id)) throw new Error("Invalid ID");
-db.user().where((u) => [expr.eq(u.id, id)]).result();
+db.user()
+  .where((u) => [expr.eq(u.id, id)])
+  .result();
 ```
 
 ## Confidence Scoring
@@ -73,6 +83,7 @@ Rate each potential issue on a scale from 0-100:
 Start by stating what files/endpoints you reviewed.
 
 For each finding, provide:
+
 - Severity: **CRITICAL** (confidence >= 90) / **WARNING** (confidence >= 75)
 - File path and line number
 - Input source (where the unvalidated data comes from)

package/claude/refs/sd-angular.md

@@ -0,0 +1,127 @@
+# Angular Guidelines (v12 only)
+
+> v13에는 Angular 없음 (SolidJS로 대체됨). 아래 규칙은 v12 전용.
+
+## Core Rules
+
+- **Signal 기반**: 상태에 RxJS 사용 금지. `$signal`, `$computed`, `$effect` 사용
+- **Standalone only**: 모든 컴포넌트 `standalone: true`
+- **OnPush + None**: `ChangeDetectionStrategy.OnPush`, `ViewEncapsulation.None` 필수
+- **input()/output()**: `@Input()`, `@Output()` 데코레이터 사용 금지 → `input()`, `output()`, `model()` 사용
+- **Control flow**: `@if`, `@for`, `@switch` 사용 (`*ngIf`, `*ngFor` 금지)
+- **DI**: `inject()` 사용 (생성자 파라미터 주입 금지)
+- **아이콘**: `@ng-icons/tabler-icons` 사용 (FontAwesome 아님)
+- **패키지 import**: `@simplysm/sd-angular` 루트에서만 import (서브폴더 접근 금지)
+
+## Signal Utilities
+
+- `$signal<T>(value?)` — writable signal (`$mark()`로 dirty 표시 가능)
+- `$computed(fn)` — 동기 computed. 비동기: `$computed([deps], asyncFn, { initialValue })`
+- `$effect(fn)` — 조건 추적 가능: `$effect([() => dep1()], () => { ... })`
+- `$arr(signal)` — 배열 조작 (`.insert()`, `.remove()`, `.toggle()`, `.diffs()`)
+- `$obj(signal)` — 객체 조작 (`.updateField()`, `.snapshot()`, `.changed()`)
+- `$set(signal)` — Set 조작 (`.add()`, `.toggle()`)
+
+## Component Pattern
+
+```typescript
+@Component({
+  selector: "app-my-page",
+  changeDetection: ChangeDetectionStrategy.OnPush,
+  encapsulation: ViewEncapsulation.None,
+  standalone: true,
+  imports: [SdTextfieldControl, SdButtonControl],
+  template: `
+    ...
+  `,
+})
+export class MyPage {
+  #sdToast = inject(SdToastProvider);
+  #sdModal = inject(SdModalProvider);
+
+  busyCount = $signal(0);
+  data = $signal<IData>({});
+
+  constructor() {
+    $effect([], async () => {
+      await this.#loadData();
+    });
+  }
+}
+```
+
+## Bootstrap
+
+```typescript
+sdHmrBootstrapAsync(AppPage, {
+  providers: [
+    provideRouter([...routes], withHashLocation()),
+    provideSdAngular({
+      clientName: "my-app",
+      defaultTheme: "compact",
+    }),
+  ],
+});
+```
+
+## Modal
+
+`ISdModal<T>` 인터페이스 구현:
+
+```typescript
+export class MyModal implements ISdModal<TResult> {
+  param = input<string>();
+  close = output<TResult>();
+}
+
+// 호출
+await this.#sdModal.showAsync({
+  type: MyModal,
+  title: "제목",
+  inputs: { param: "value" },
+});
+```
+
+## Data Sheet
+
+CRUD 테이블은 `AbsSdDataSheet<TFilter, TItem, TKey>` 확장:
+
+- `search()` — 데이터 조회
+- `submit()` — 변경사항 저장
+- `downloadExcel()` / `uploadExcel()` — 엑셀 연동
+- `$mark()` — 셀 수정 시 dirty 표시 필수
+
+## Busy / Error Handling
+
+```typescript
+this.busyCount.update((v) => v + 1);
+try {
+  await this.#sdToast.try(async () => {
+    /* work */
+  });
+} finally {
+  this.busyCount.update((v) => v - 1);
+}
+```
+
+## Theming
+
+- CSS 변수 사용: `--theme-primary-default`, `--gap-sm`, `--border-radius-default` 등
+- 하드코딩 색상 금지
+- 테마: `"compact"` | `"mobile"` | `"kiosk"` + dark mode
+
+## Permissions
+
+```typescript
+perms = usePermsSignal(["base.partner"], ["use", "edit"]);
+canEdit = $computed(() => this.perms().includes("edit"));
+```
+
+## Routing
+
+```typescript
+{
+  path: "my-page",
+  loadComponent: () => import("./MyPage").then((m) => m.MyPage),
+}
+```

package/claude/refs/sd-orm-v12.md

@@ -0,0 +1,81 @@
+# ORM Guidelines (v12)
+
+## Table Definition — Decorator 기반
+
+```typescript
+@Table({ description: "사용자", database: "mydb" })
+export class User {
+  @Column({ primaryKey: 1, autoIncrement: true, description: "ID" })
+  id!: number;
+
+  @Column({ dataType: { type: "STRING", length: 100 }, description: "이름" })
+  name!: string;
+
+  @Column({ nullable: true, description: "이메일" })
+  email?: string;
+
+  @ForeignKey(["departmentId"], () => Department, "부서")
+  department?: Department;
+
+  @ForeignKeyTarget(() => Order, "user", "주문 목록")
+  orders?: Order[];
+}
+```
+
+### Decorators
+
+- `@Table({ description, database?, schema?, name?, view?, procedure? })` — 테이블/뷰/프로시저 정의
+- `@Column({ description, name?, dataType?, nullable?, autoIncrement?, primaryKey? })` — 컬럼 정의
+- `@ForeignKey(columnNames, targetTypeFwd, description)` — FK 관계
+- `@ForeignKeyTarget(sourceTypeFwd, fkPropertyKey, description, multiplicity?)` — FK 역방향
+- `@ReferenceKey(columnNames, targetTypeFwd, description)` — 참조 관계
+- `@ReferenceKeyTarget(sourceTypeFwd, refKeyPropertyKey, description, multiplicity?)` — 참조 역방향
+- `@Index({ name?, order?, orderBy?, unique? })` — 인덱스
+
+### 요구사항
+
+- `tsconfig`에 `experimentalDecorators: true`, `emitDecoratorMetadata: true` 필요
+
+## DbContext
+
+```typescript
+export abstract class MyDbContext extends DbContext {
+  user = new Queryable(this, User);
+  order = new Queryable(this, Order);
+
+  get migrations(): Type<IDbMigration>[] {
+    return [Migration001, Migration002];
+  }
+}
+```
+
+## Query
+
+```typescript
+// Select
+const users = await db.user
+  .select((item) => ({ id: item.id, name: item.name }))
+  .where((item) => [db.qh.equal(item.id, userId)])
+  .resultAsync();
+
+// Insert
+await db.user.insertAsync([{ name: "홍길동" }]);
+
+// Connect with transaction
+await db.connectAsync(async () => {
+  await db.user.insertAsync([{ name: "홍길동" }]);
+});
+```
+
+## SQL Injection Prevention
+
+ORM uses string escaping (not parameter binding). **Always validate user input before ORM queries.**
+
+```typescript
+const userId = Number(req.query.id);
+if (Number.isNaN(userId)) throw new Error("Invalid ID");
+await db.user
+  .select((item) => ({ id: item.id, name: item.name }))
+  .where((item) => [db.qh.equal(item.id, userId)])
+  .resultAsync();
+```

package/claude/refs/sd-orm.md

@@ -1,6 +1,7 @@
 # ORM Guidelines
 
 ## Table Definition
+
 ```typescript
 const User = Table("User")
   .database("mydb")
@@ -9,9 +10,14 @@ const User = Table("User")
 ```
 
 ## SQL Injection Prevention
+
 ORM uses string escaping (not parameter binding). **Always validate user input before ORM queries.**
+
 ```typescript
 const userId = Number(req.query.id);
 if (Number.isNaN(userId)) throw new Error("Invalid ID");
-await db.user().where((u) => [expr.eq(u.id, userId)]).result();
+await db
+  .user()
+  .where((u) => [expr.eq(u.id, userId)])
+  .result();
 ```

package/claude/refs/sd-solid.md

@@ -3,6 +3,7 @@
 **SolidJS is NOT React!**
 
 ## Core Concepts
+
 - Component functions run **once** at mount (not on every state change)
 - Fine-grained reactivity: unchanged signals don't re-evaluate expressions
 - `createMemo`: only for expensive computations used in multiple places
@@ -14,26 +15,32 @@
   - CSS NOT transpiled → no `aspect-ratio`, `inset`, `:is()`, `:where()`
 
 ## Props Design
+
 - Props that don't need parameters must accept plain values (`editable={perms().edit}`), not wrapped in functions (`editable={() => perms().edit}`) — use function props only when parameters are needed (callbacks)
 
 ## Implementation Rules
+
 - Prefer signals/stores over Provider/Context
 - Check existing patterns before introducing abstractions
 - Before modifying components: always Read the file to check existing props/patterns
 
 ## Hook Naming
+
 - `create*`: Reactive hooks wrapping SolidJS primitives
 - `use*`: Hooks depending on Provider Context
 - Others: no hook prefix
 
 ## Compound Components
+
 All sub-components via dot notation only (`Parent.Child`).
+
 - Define `interface ParentComponent { Child: typeof ChildComponent }`
 - Assign `Parent.Child = ChildComponent;`
 - Don't export sub-components separately (export parent only)
 - UI elements → compound sub-components, non-rendering config (state, behavior, callbacks) → props
 
 ## Tailwind CSS
+
 - `darkMode: "class"`, `aspectRatio` plugin disabled (Chrome 84)
 - Semantic colors: `primary`(blue), `info`(sky), `success`(green), `warning`(amber), `danger`(red), `base`(zinc) → never use `zinc-*` directly
 - Heights: `field`, `field-sm`, `field-lg`
@@ -43,6 +50,7 @@ All sub-components via dot notation only (`Parent.Child`).
 - Before modifying styles: Read existing class patterns of the same component
 
 ## Application View Naming (`client-*`)
+
 - `~Sheet` — List view based on DataSheet (e.g., `UserSheet`)
 - `~Detail` — Single record detail/edit view (e.g., `MyInfoDetail`)
 - `~View` — Everything else (e.g., `LoginView`, `MainView`)

package/claude/rules/sd-refs-linker.md

@@ -2,17 +2,49 @@
 
 Before starting work, **Read** the relevant reference files from `.claude/refs/`.
 
-| When | Read this file |
-|------|---------------|
-| Writing or modifying code | `.claude/refs/sd-code-conventions.md` |
-| Working with `.cache/` or Playwright screenshots | `.claude/refs/sd-directories.md` |
-| Using `@simplysm/*` package APIs | `.claude/refs/sd-simplysm-docs.md` |
-| Debugging, problem-solving, or planning approach | `.claude/refs/sd-workflow.md` |
+## Version Detection
+
+`package.json`의 `version` 필드로 메이저 버전을 판별한다.
+
+- `12.x.x` → **v12** (< 13)
+- `13.x.x` → **v13** (>= 13)
+
+## Common (all versions)
+
+| When                                             | Read this file                        |
+| ------------------------------------------------ | ------------------------------------- |
+| Writing or modifying code                        | `.claude/refs/sd-code-conventions.md` |
+| Working with `.cache/` or Playwright screenshots | `.claude/refs/sd-directories.md`      |
+| Using `@simplysm/*` package APIs                 | `.claude/refs/sd-simplysm-docs.md`    |
+| Debugging, problem-solving, or planning approach | `.claude/refs/sd-workflow.md`         |
+| @simplysm/service-\* 사용 시                     | `.claude/refs/sd-service.md`          |
+
+## v12 only (< 13)
+
+| When                                   | Read this file               |
+| -------------------------------------- | ---------------------------- |
+| Angular / @simplysm/sd-angular 작업 시 | `.claude/refs/sd-angular.md` |
+| @simplysm/sd-orm-\* 사용 시            | `.claude/refs/sd-orm-v12.md` |
+
+- v12는 **Angular** 기반 (SolidJS 없음)
+- ORM은 **데코레이터** 패턴 (`@Table`, `@Column`)
+- 패키지명: `sd-` prefix 사용 (`sd-core-common`, `sd-orm-common` 등)
+- 패키지 매니저: **yarn**
+
+## v13 only (>= 13)
+
+| When                                         | Read this file             |
+| -------------------------------------------- | -------------------------- |
 | SolidJS / @simplysm/solid / Tailwind 작업 시 | `.claude/refs/sd-solid.md` |
-| @simplysm/orm-* 사용 시 (`@^13`) | `.claude/refs/sd-orm.md` |
-| @simplysm/service-* 사용 시 (`@^13`) | `.claude/refs/sd-service.md` |
+| @simplysm/orm-\* 사용 시                     | `.claude/refs/sd-orm.md`   |
+
+- v13는 **SolidJS** 기반 (Angular 없음)
+- ORM은 **함수형 빌더** 패턴 (`Table().columns().primaryKey()`)
+- 패키지명: prefix 없음 (`core-common`, `orm-common` 등)
+- 패키지 매니저: **pnpm**
+
+## Rules
 
-**Rules:**
 - Read the reference BEFORE starting the related work (not after)
 - You may read multiple references if the task spans multiple areas
 - If unsure whether a reference applies, read it — the cost of reading is low

package/claude/skills/sd-api-name-review/SKILL.md

@@ -35,12 +35,12 @@ Based on Phase 1 results, determine comparison targets and perspectives:
 
 Cross-compare Phase 1 and Phase 2 results to produce the report.
 
-| Priority | Criteria |
-|----------|----------|
-| **P0** | Misaligned with majority of surveyed libraries |
-| **P1** | Internal inconsistency (same concept, different names) |
-| **P2** | Better industry term exists (optional) |
-| **Keep** | Already aligned with standards |
+| Priority | Criteria                                               |
+| -------- | ------------------------------------------------------ |
+| **P0**   | Misaligned with majority of surveyed libraries         |
+| **P1**   | Internal inconsistency (same concept, different names) |
+| **P2**   | Better industry term exists (optional)                 |
+| **Keep** | Already aligned with standards                         |
 
 Each item includes: current name, recommended change, rationale (usage patterns per library).
 

package/claude/skills/sd-brainstorm/SKILL.md

@@ -15,6 +15,7 @@ Start by understanding the current project context, then ask questions one at a
 ## The Process
 
 **Understanding the idea:**
+
 - Check out the current project state first (files, docs, recent commits)
 - Ask questions one at a time to refine the idea
 - Prefer multiple choice questions when possible, but open-ended is fine too
@@ -22,11 +23,13 @@ Start by understanding the current project context, then ask questions one at a
 - Focus on understanding: purpose, constraints, success criteria
 
 **Exploring approaches:**
+
 - Propose 2-3 different approaches with trade-offs
 - Present options conversationally with your recommendation and reasoning
 - Lead with your recommended option and explain why
 
 **Presenting the design:**
+
 - Once you believe you understand what you're building, present the design
 - Break it into sections of 200-300 words
 - Ask after each section whether it looks right so far
@@ -36,6 +39,7 @@ Start by understanding the current project context, then ask questions one at a
 ## After the Design
 
 **Documentation:**
+
 - Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
 - Commit the design document to git
 

package/claude/skills/sd-check/SKILL.md

@@ -1,31 +1,31 @@
 ---
 name: sd-check
 description: Use when verifying code quality via typecheck, lint, and tests - before deployment, PR creation, after code changes, or when type errors, lint violations, or test failures are suspected. Applies to whole project or specific paths.
-allowed-tools: Bash(pnpm check), Bash(pnpm typecheck), Bash(pnpm lint --fix), Bash(pnpm vitest)
+allowed-tools: Bash(npm run check), Bash(npm run typecheck), Bash(npm run lint --fix), Bash(npm run vitest)
 ---
 
 # sd-check
 
-Run `pnpm check`, fix errors, repeat until clean.
+Run `npm run check`, fix errors, repeat until clean.
 
 ## Usage
 
 ```
-pnpm check [path] [--type typecheck|lint|test]
+npm run check [path] [--type typecheck|lint|test]
 ```
 
-| Example | Effect |
-|---------|--------|
-| `/sd-check` | Full project, all checks |
-| `/sd-check packages/core-common` | Specific path, all checks |
-| `/sd-check test` | Tests only, full project |
-| `/sd-check packages/core-common lint` | Specific path + type |
+| Example                               | Effect                    |
+| ------------------------------------- | ------------------------- |
+| `/sd-check`                           | Full project, all checks  |
+| `/sd-check packages/core-common`      | Specific path, all checks |
+| `/sd-check test`                      | Tests only, full project  |
+| `/sd-check packages/core-common lint` | Specific path + type      |
 
 Multiple types: `--type typecheck,lint`. No path = full project. No type = all checks.
 
 ## Workflow
 
-1. **Run** `pnpm check [path] [--type type]` (timeout: 600000)
+1. **Run** `npm run check [path] [--type type]` (timeout: 600000)
 2. **All passed?** Report with actual output numbers → done
 3. **Errors?** Fix in priority order: typecheck → lint → test (fixes cascade)
    - Test failures: run `git diff` to decide — update test or fix source

package/claude/skills/sd-check/baseline-analysis.md

@@ -7,6 +7,7 @@ Tested 6 scenarios with agents WITHOUT sd-check skill. All agents failed to foll
 ## Common Failures Across All Scenarios
 
 ### 1. No Cost Optimization
+
 **Failure:** All agents planned direct command execution instead of using haiku subagents.
 
 **Observed in:** All scenarios (1-6)
@@ -16,9 +17,11 @@ Tested 6 scenarios with agents WITHOUT sd-check skill. All agents failed to foll
 **What skill must prevent:** Skill must explicitly require haiku subagent usage
 
 ### 2. Incomplete Parallelization
+
 **Failure:** Agents either ran sequentially or only partially parallelized.
 
 **Examples:**
+
 - Scenario 1: Used `&` for typecheck/lint but ran tests sequentially ("stratified parallel")
 - Scenario 2: No parallelization at all
 - Scenario 3: Sequential fix → verify → fix → verify
@@ -28,20 +31,24 @@ Tested 6 scenarios with agents WITHOUT sd-check skill. All agents failed to foll
 **What skill must prevent:** Skill must require ALL 3 checks (typecheck, lint, test) in parallel via 3 separate haiku agents
 
 ### 3. Missing Environment Pre-checks
+
 **Failure:** No systematic environment validation before running checks.
 
 **Observed:**
+
 - Scenario 1: Checked Docker for ORM tests, but not other prerequisites
-- Scenario 6: Only checked pnpm-lock.yaml, missed package.json version, scripts, vitest.config.ts
+- Scenario 6: Only checked lock file, missed package.json scripts
 
 **Impact:** Confusing errors if environment misconfigured
 
-**What skill must prevent:** Skill must require 4 pre-checks (package.json v13, pnpm workspace, scripts, vitest config)
+**What skill must prevent:** Skill must require pre-check (package.json `check` script exists)
 
 ### 4. Unclear Re-verification Loop
+
 **Failure:** After fixing errors, no clear "re-run ALL checks" loop.
 
 **Examples:**
+
 - Scenario 3: Phase 1 verify → Phase 2 verify → Phase 3 verify (but no final "all phases" re-verify)
 - Agents treated it as linear progression, not a loop
 
@@ -50,9 +57,11 @@ Tested 6 scenarios with agents WITHOUT sd-check skill. All agents failed to foll
 **What skill must prevent:** Skill must explicitly state "re-run ALL 3 checks until ALL pass"
 
 ### 5. No sd-debug Recommendation
+
 **Failure:** When root cause unclear after multiple attempts, agents didn't recommend sd-debug.
 
 **Observed:**
+
 - Scenario 4: After 4 failed attempts, agent suggested various debugging approaches but NOT `/sd-debug` skill
 
 **Impact:** User wastes time when systematic root-cause investigation needed
@@ -60,9 +69,11 @@ Tested 6 scenarios with agents WITHOUT sd-check skill. All agents failed to foll
 **What skill must prevent:** Skill must state "after 2-3 failed fix attempts → recommend /sd-debug"
 
 ### 6. Incorrect Default Behavior
+
 **Failure:** When no path argument provided, agents asked user for clarification instead of defaulting to full project.
 
 **Observed:**
+
 - Scenario 5: Agent wanted to ask "which package?" instead of running on entire project
 
 **Impact:** Unnecessary user friction
@@ -70,10 +81,12 @@ Tested 6 scenarios with agents WITHOUT sd-check skill. All agents failed to foll
 **What skill must prevent:** Skill must state "if no path argument → run on entire project (omit path in commands)"
 
 ### 7. Scope Creep (Unnecessary Steps)
+
 **Failure:** Agents included steps not relevant to "verification".
 
 **Examples:**
-- Scenario 1: Included `pnpm build` (verification doesn't need build)
+
+- Scenario 1: Included build step (verification doesn't need build)
 - Scenario 2: Included dev server test (not verification)
 
 **Impact:** Wasted time, confusion about scope
@@ -83,33 +96,40 @@ Tested 6 scenarios with agents WITHOUT sd-check skill. All agents failed to foll
 ## Rationalization Patterns (Verbatim)
 
 ### "Parallelization while maintaining logical dependencies"
+
 - Used to justify partial parallelization
 - Agents ran typecheck & lint in parallel, but tests sequentially
 - **Counter:** ALL 3 checks are independent → all 3 in parallel
 
 ### "Stratified parallel execution"
+
 - Used to justify sequential test runs grouped by environment
 - **Counter:** Vitest projects are independent → run all via single command
 
 ### "Faster to fail fast on static checks"
+
 - Good principle, but used to justify including build step
 - **Counter:** Build is not a static check, and not required for verification
 
 ### "Type safety first" / "Incremental verification"
+
 - Used to justify Phase 1 → Phase 2 → Phase 3 linear progression
 - **Counter:** After fixes, must re-verify ALL phases (loop), not just next phase
 
 ### "Understanding first, then ONE comprehensive fix"
+
 - Used to justify continued debugging without tools
 - **Counter:** After 2-3 attempts, recommend /sd-debug for systematic investigation
 
 ### "Ask for clarification" / "Explicit and predictable"
+
 - Used to justify asking user for path when none provided
 - **Counter:** Default to full project is explicit and predictable behavior
 
 ## Success Criteria for Skill
 
 Skill is effective if agents:
+
 1. ✅ Launch 3 haiku agents in parallel (typecheck, lint, test)
 2. ✅ Run environment pre-checks before verification
 3. ✅ Default to full project when no path argument
@@ -123,6 +143,7 @@ Skill is effective if agents:
 After writing skill, re-run scenarios 1-6. Agents should now exhibit correct behavior above.
 
 Focus on:
+
 - Scenario 1: Verify parallel haiku agents + env checks
 - Scenario 3: Verify re-verification loop + priority
 - Scenario 4: Verify sd-debug recommendation