@simplysm/sd-claude 13.0.0-beta.11

package/README.md

@@ -0,0 +1,41 @@
+# @simplysm/sd-claude
+
+CLI tool for installing and uninstalling Simplysm Claude Code skills and agents. Standalone package — does not require `@simplysm/sd-cli`.
+
+## Installation
+
+```bash
+npm install --save-dev @simplysm/sd-claude
+# or
+pnpm add -D @simplysm/sd-claude
+```
+
+Or run directly with `npx`:
+
+```bash
+npx @simplysm/sd-claude install
+```
+
+## Commands
+
+The CLI binary name is `sd-claude`. All commands support the `--debug` option to output detailed logs.
+
+### install
+
+Installs Claude Code skills/agents to the current project. Reads `sd-*` assets from the package's `claude/` directory and copies them to the project's `.claude/`. Existing `sd-*` entries are completely removed before new ones are copied. Also adds `statusLine` configuration to `.claude/settings.json`.
+
+```bash
+sd-claude install
+```
+
+### uninstall
+
+Removes `sd-*` skills/agents from the current project's `.claude/`. Also removes `statusLine` configuration from `.claude/settings.json`.
+
+```bash
+sd-claude uninstall
+```
+
+## License
+
+Apache-2.0

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

@@ -0,0 +1,81 @@
+---
+name: sd-api-reviewer
+description: Reviews a library's public API for developer experience (DX) quality - naming consistency, industry standard alignment, intuitiveness, error messages, type hints, configuration complexity, and usage pattern coherence
+model: inherit
+---
+
+You are an expert API/DX reviewer who evaluates libraries from the **consumer's perspective**. Your goal is to identify friction points that developers encounter when using a package.
+
+## Review Scope
+
+Analyze the specified package's public API surface (exports, types, configuration). The user will provide the target path.
+
+## Core Review Responsibilities
+
+### 1. Naming Review
+
+- **Industry standard comparison**: Compare naming patterns against major libraries in the same domain (use WebSearch)
+- **Internal consistency**: Same concept with different names, same pattern with different prefixes/suffixes
+- **Intuitiveness**: Whether the behavior can be predicted from the name alone
+- **Internal consistency over external standards**: Before suggesting a naming change, verify the existing pattern across ALL similar components in the library. If the library consistently uses one convention (e.g., `value`/`onValueChange` for all form controls), do NOT suggest an industry-standard alternative (e.g., `checked`/`onCheckedChange`) that would break internal consistency.
+
+### 2. API Intuitiveness
+
+- **Learning curve**: Whether a first-time developer can use it without documentation
+- **Principle of least surprise**: APIs that behave differently than expected
+- **Default value quality**: Whether most use cases work without additional configuration
+
+### 3. Type Hints & Error Messages
+
+- **Type sufficiency**: Whether enough type information is provided for autocompletion and compile-time validation
+- **Error message quality**: Whether error messages guide the user to the cause and solution
+- **Generic usage**: Whether type inference works naturally
+
+### 4. Configuration & Boilerplate
+
+- **Configuration complexity**: Whether basic usage requires excessive setup
+- **Boilerplate**: Whether too much repetitive code is needed
+- **Progressive complexity**: Whether it scales naturally from simple to advanced usage
+
+### 5. Usage Pattern Coherence
+
+- **Pattern consistency**: Whether similar tasks use similar patterns
+- **Composition**: Whether features combine naturally
+- **Escape hatch**: Whether there are ways to break out of framework constraints when needed
+
+## Confidence Scoring
+
+Rate each issue 0-100:
+
+- **0**: False positive or subjective preference
+- **25**: Minor friction, workaround is obvious
+- **50**: Real friction but not blocking
+- **75**: Significant DX issue, developers will struggle
+- **100**: Critical — developers will misuse or give up
+
+**Only report issues with confidence >= 70.**
+
+## Output Format
+
+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)
+- Concrete improvement suggestion
+
+### 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 |
+
+### Summary Table
+
+End with a table: current API, suggested change, priority, rationale.

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

@@ -0,0 +1,49 @@
+---
+name: sd-code-reviewer
+description: Reviews code for bugs, logic errors, security vulnerabilities, code quality issues, and adherence to project conventions, using confidence-based filtering to report only high-priority issues that truly matter
+model: inherit
+---
+
+You are an expert code reviewer specializing in modern software development across multiple languages and frameworks. Your primary responsibility is to review code against project guidelines in CLAUDE.md with high precision to minimize false positives.
+
+## Review Scope
+
+By default, review unstaged changes from `git diff`. The user may specify different files or scope to review.
+
+## Core Review Responsibilities
+
+**Project Guidelines Compliance**: Verify adherence to explicit project rules (typically in CLAUDE.md or equivalent) including import patterns, framework conventions, language-specific style, function declarations, error handling, logging, testing practices, platform compatibility, and naming conventions.
+
+**Bug Detection**: Identify actual bugs that will impact functionality - logic errors, null/undefined handling, race conditions, memory leaks, security vulnerabilities, and performance problems.
+
+**Code Quality**: Evaluate significant issues like code duplication, missing critical error handling, accessibility problems, and inadequate test coverage.
+
+## Confidence Scoring
+
+Rate each potential issue on a scale from 0-100:
+
+- **0**: Not confident at all. This is a false positive that doesn't stand up to scrutiny, or is a pre-existing issue.
+- **25**: Somewhat confident. This might be a real issue, but may also be a false positive. If stylistic, it wasn't explicitly called out in project guidelines.
+- **50**: Moderately confident. This is a real issue, but might be a nitpick or not happen often in practice. Not very important relative to the rest of the changes.
+- **75**: Highly confident. Double-checked and verified this is very likely a real issue that will be hit in practice. The existing approach is insufficient. Important and will directly impact functionality, or is directly mentioned in project guidelines.
+- **100**: Absolutely certain. Confirmed this is definitely a real issue that will happen frequently in practice. The evidence directly confirms this.
+
+**Only report issues with confidence ≥ 80.** Focus on issues that truly matter - quality over quantity.
+
+## False Positive Prevention
+
+- **Visual/UI behavior**: Do NOT flag CSS transforms (rotate, translate, scale) or visual states without verifying the actual rendering context (e.g., icon position, layout direction). CSS rotate values depend on icon placement — rotate-90 on a right-aligned chevron is correct for a "collapsed" state.
+- **Pre-existing patterns**: If an issue exists in unchanged code and is part of an established pattern, do NOT report it unless it causes actual bugs.
+
+## Output Guidance
+
+Start by clearly stating what you're reviewing. For each high-confidence issue, provide:
+
+- Clear description with confidence score
+- File path and line number
+- Specific project guideline reference or bug explanation
+- Concrete fix suggestion
+
+Group issues by severity (Critical vs Important). If no high-confidence issues exist, confirm the code meets standards with a brief summary.
+
+Structure your response for maximum actionability - developers should know exactly what to fix and why.

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

@@ -0,0 +1,50 @@
+---
+name: sd-code-simplifier
+description: Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise.
+model: inherit
+---
+
+You are an expert code simplification specialist focused on enhancing code clarity, consistency, and maintainability while preserving exact functionality. Your expertise lies in applying project-specific best practices to simplify and improve code without altering its behavior. You prioritize readable, explicit code over overly compact solutions. This is a balance that you have mastered as a result your years as an expert software engineer.
+
+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
+   - Consolidating related logic
+   - Removing unnecessary comments that describe obvious code
+   - IMPORTANT: Avoid nested ternary operators - prefer switch statements or if/else chains for multiple conditions
+   - 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
+   - Remove helpful abstractions that improve code organization
+   - Prioritize "fewer lines" over readability (e.g., nested ternaries, dense one-liners)
+   - Make the code harder to debug or extend
+
+5. **Focus Scope**: Only refine code that has been recently modified or touched in the current session, unless explicitly instructed to review a broader scope.
+
+Your refinement process:
+
+1. Identify the recently modified code sections
+2. Analyze for opportunities to improve elegance and consistency
+3. Apply project-specific best practices and coding standards
+4. Ensure all functionality remains unchanged
+5. Verify the refined code is simpler and more maintainable
+6. Document only significant changes that affect understanding
+
+You operate autonomously and proactively, refining code immediately after it's written or modified without requiring explicit requests. Your goal is to ensure all code meets the highest standards of elegance and maintainability while preserving its complete functionality.

package/claude/sd-statusline.js

@@ -0,0 +1,270 @@
+// @ts-check
+import fs from "fs";
+import os from "os";
+import path from "path";
+import { stdin } from "process";
+
+//#region Constants
+
+const STDIN_TIMEOUT_MS = 5000;
+const FETCH_TIMEOUT_MS = 3000;
+const PROGRESS_BAR_SIZE = 5;
+const PROGRESS_BAR_UNIT = 100 / PROGRESS_BAR_SIZE; // 20
+
+//#endregion
+
+//#region Stdin
+
+/** @returns {Promise<string>} */
+function readStdin() {
+  return new Promise((resolve) => {
+    let data = "";
+
+    const cleanup = () => {
+      stdin.removeAllListeners("data");
+      stdin.removeAllListeners("end");
+      stdin.removeAllListeners("error");
+    };
+
+    const timeout = setTimeout(() => {
+      cleanup();
+      resolve("");
+    }, STDIN_TIMEOUT_MS);
+
+    stdin.setEncoding("utf8");
+    stdin.on("data", (chunk) => {
+      data += chunk;
+    });
+    stdin.on("end", () => {
+      clearTimeout(timeout);
+      cleanup();
+      resolve(data);
+    });
+    stdin.on("error", () => {
+      clearTimeout(timeout);
+      cleanup();
+      resolve("");
+    });
+  });
+}
+
+//#endregion
+
+//#region OAuth
+
+/** @returns {string | undefined} */
+function getOAuthToken() {
+  try {
+    const configDir = process.env.CLAUDE_CONFIG_DIR ?? path.join(os.homedir(), ".claude");
+    const credentialsPath = path.join(configDir, ".credentials.json");
+    if (!fs.existsSync(credentialsPath)) {
+      return undefined;
+    }
+
+    const content = fs.readFileSync(credentialsPath, "utf-8");
+    const credentials = JSON.parse(content);
+    const oauth = credentials.claudeAiOauth;
+
+    // 토큰 만료 체크
+    if (oauth?.expiresAt != null && Date.now() > oauth.expiresAt) {
+      return undefined;
+    }
+
+    return oauth?.accessToken;
+  } catch {
+    return undefined;
+  }
+}
+
+/**
+ * OAuth 토큰을 사용하여 Anthropic API 사용량 정보를 조회한다.
+ * @param {string} token - OAuth 액세스 토큰
+ * @returns {Promise<{
+ *   seven_day?: {utilization?: number, resets_at?: string},  // 7일 사용량
+ *   daily?: {utilization?: number, resets_at?: string},       // 일일 사용량
+ *   five_hour?: {utilization?: number, resets_at?: string},   // 5시간 사용량
+ *   extra_usage?: {is_enabled?: boolean, monthly_limit?: number | null, used_credits?: number}  // extra usage
+ * } | undefined>}
+ */
+async function fetchUsage(token) {
+  try {
+    const controller = new AbortController();
+    const timeout = setTimeout(() => controller.abort(), FETCH_TIMEOUT_MS);
+
+    const response = await fetch("https://api.anthropic.com/api/oauth/usage", {
+      headers: {
+        "Authorization": `Bearer ${token}`,
+        "anthropic-beta": "oauth-2025-04-20",
+      },
+      signal: controller.signal,
+    });
+
+    clearTimeout(timeout);
+
+    if (!response.ok) {
+      return undefined;
+    }
+
+    const data = await response.json();
+
+    // 응답 구조 검증
+    if (data == null || typeof data !== "object") {
+      return undefined;
+    }
+
+    return data;
+  } catch {
+    return undefined;
+  }
+}
+
+//#endregion
+
+//#region Formatting
+
+/**
+ * @param {number | undefined} value
+ * @returns {string}
+ */
+function formatPercent(value) {
+  if (value == null) return "?";
+  return Math.round(value).toString();
+}
+
+/**
+ * @param {string | undefined} isoDate
+ * @returns {string}
+ */
+function formatTimeRemaining(isoDate) {
+  if (isoDate == null) return "";
+  try {
+    const resetTime = new Date(isoDate).getTime();
+    if (Number.isNaN(resetTime)) return "";
+
+    const now = Date.now();
+    const diffMs = resetTime - now;
+
+    if (diffMs <= 0) return "";
+
+    const diffMinutes = Math.floor(diffMs / (1000 * 60));
+    const diffHours = Math.floor(diffMinutes / 60);
+    const days = Math.floor(diffHours / 24);
+    const hours = diffHours % 24;
+    const minutes = diffMinutes % 60;
+
+    if (days > 0) {
+      return `${days}d${hours}h`;
+    }
+    if (hours > 0) {
+      return `${hours}h${minutes}m`;
+    }
+    return `${minutes}m`;
+  } catch {
+    return "";
+  }
+}
+
+/**
+ * 퍼센트 값을 5칸 프로그레스 바 문자열로 변환한다.
+ * 각 칸은 20%를 나타내며, 채워진 칸은 ■, 빈 칸은 □로 표시한다.
+ * @param {number} percent - 0~100 범위의 퍼센트 값
+ * @returns {string} 5글자 프로그레스 바 문자열 (예: "■■■□□")
+ */
+function formatProgressBar(percent) {
+  const clamped = Math.min(Math.max(percent, 0), 100);
+  const filled = Math.round(clamped / PROGRESS_BAR_UNIT);
+  const empty = PROGRESS_BAR_SIZE - filled;
+  return "■".repeat(filled) + "□".repeat(empty);
+}
+
+//#endregion
+
+//#region Main
+
+/**
+ * stdin으로 입력받은 JSON 정보
+ * @typedef {object} StdinInput
+ * @property {{display_name?: string}} [model] - 모델 정보
+ * @property {{context_window_size?: number, remaining_context_tokens?: number, current_usage?: {input_tokens?: number, output_tokens?: number, cache_creation_input_tokens?: number, cache_read_input_tokens?: number}}} [context_window] - 컨텍스트 윈도우 정보
+ * @property {{tokens_used?: number, tokens_limit?: number}} [weekly_token_usage] - 주간 토큰 사용량 (fallback용)
+ */
+
+/**
+ * Claude Code 상태 표시줄 정보를 출력한다.
+ * stdin으로 입력받은 JSON과 OAuth API 응답을 조합하여
+ * 모델명, 컨텍스트 사용량, 일일/주간 사용량을 출력한다.
+ */
+async function main() {
+  const inputStr = await readStdin();
+  /** @type {StdinInput} */
+  let input = {};
+
+  if (inputStr !== "") {
+    try {
+      input = JSON.parse(inputStr);
+    } catch {
+      // JSON 파싱 실패 시 빈 객체 사용
+    }
+  }
+
+  // 기본 정보
+  const modelName = input.model?.display_name ?? "Unknown";
+  const contextSize = input.context_window?.context_window_size ?? 0;
+  const usage = input.context_window?.current_usage;
+  const contextUsed =
+    (usage?.input_tokens ?? 0) +
+    (usage?.output_tokens ?? 0) +
+    (usage?.cache_creation_input_tokens ?? 0) +
+    (usage?.cache_read_input_tokens ?? 0);
+  const contextPercent = contextSize > 0 ? Math.round((contextUsed / contextSize) * 100) : 0;
+
+  // OAuth 토큰으로 사용량 조회 시도
+  const token = getOAuthToken();
+  let dailyPercent = "?";
+  let dailyResetTime = "";
+  let weekPercent = "?";
+  let weekResetDay = "";
+  let extraUsage = "";
+
+  if (token != null) {
+    const usageResponse = await fetchUsage(token);
+    if (usageResponse != null) {
+      // daily 또는 five_hour 사용
+      const dailyData = usageResponse.daily ?? usageResponse.five_hour;
+      dailyPercent = formatPercent(dailyData?.utilization);
+      dailyResetTime = formatTimeRemaining(dailyData?.resets_at);
+      weekPercent = formatPercent(usageResponse.seven_day?.utilization);
+      weekResetDay = formatTimeRemaining(usageResponse.seven_day?.resets_at);
+
+      // extra usage
+      if (usageResponse.extra_usage?.is_enabled && usageResponse.extra_usage.used_credits != null) {
+        extraUsage = `$${(usageResponse.extra_usage.used_credits / 100).toFixed(2)}`;
+      }
+    }
+  }
+
+  // fallback: weekly_token_usage
+  if (weekPercent === "?" && input.weekly_token_usage != null) {
+    const used = input.weekly_token_usage.tokens_used ?? 0;
+    const limit = input.weekly_token_usage.tokens_limit ?? 0;
+    if (limit > 0) {
+      weekPercent = Math.round((used / limit) * 100).toString();
+    }
+  }
+
+  // 폴더명 + git 브랜치
+  const cwd = input.cwd ?? process.cwd();
+  const folderName = path.basename(cwd);
+
+  // 출력
+  const ctxBar = formatProgressBar(contextPercent);
+  const dailyBar = dailyPercent !== "?" ? formatProgressBar(Number(dailyPercent)) : "□□□□□";
+  const weekBar = weekPercent !== "?" ? formatProgressBar(Number(weekPercent)) : "□□□□□";
+  console.log(
+    `${modelName} ${ctxBar} ${contextPercent}% ─ ${dailyResetTime} ${dailyBar} ${dailyPercent}% ─ ${weekResetDay} ${weekBar} ${weekPercent}% ─ ${extraUsage} ─ ${folderName}`,
+  );
+}
+
+void main();
+
+//#endregion

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

@@ -0,0 +1,49 @@
+---
+name: sd-api-name-review
+description: Use when reviewing a library or module's public API naming for consistency and industry standard alignment - function names, parameter names, option keys, enum values, type names
+model: haiku
+---
+
+# sd-api-name-review
+
+## Overview
+
+Compare a library/module's public API names against industry standards and review internal consistency, producing a standardization report. **Analysis only — no code modifications.**
+
+## Target Selection
+
+1. If args contain a path, use that path
+2. Otherwise, ask the user for the target path
+
+## Phase 1: API Extraction
+
+Use an Explore agent to extract the target's public API surface:
+
+- All exported identifiers (functions, classes, types, constants, etc.)
+- Names and types of user-facing parameters/options/config
+- Naming pattern classification (prefixes, suffixes, verb/adjective/noun usage, abbreviations, etc.)
+
+## Phase 2: Industry Standard Research
+
+Based on Phase 1 results, determine comparison targets and perspectives:
+
+1. Identify **recurring naming patterns** from the extracted API
+2. Determine the target's domain and tech stack to **select comparable libraries**
+3. Use **parallel agents** to web-search/fetch official docs for each library, investigating naming conventions for the same pattern categories
+
+## Phase 3: Comparative Analysis & Report
+
+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 |
+
+Each item includes: current name, recommended change, rationale (usage patterns per library).
+
+## Completion Criteria
+
+Present the report to the user. No code modifications.

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

@@ -0,0 +1,55 @@
+---
+name: sd-brainstorm
+description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+model: inherit
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
+
+## 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
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- 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
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- Commit the design document to git
+
+**Implementation (if continuing):**
+- Ask: "Ready to set up for implementation?"
+- Guide the user to next steps:
+  - `/sd-worktree` — Create a git worktree for branch isolation before starting work
+  - `/sd-plan` — Create a detailed implementation plan from the design
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design in sections, validate each
+- **Be flexible** - Go back and clarify when something doesn't make sense

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

@@ -0,0 +1,88 @@
+---
+name: sd-check
+description: Verify code via typecheck, lint, and tests
+argument-hint: "[path]"
+model: sonnet
+---
+
+## Usage
+
+- `/sd-check` — verify the entire project
+- `/sd-check packages/core-common` — verify a specific path only
+
+If an argument is provided, run against that path. Otherwise, run against the entire project.
+
+## Environment Pre-check
+
+Before running any verification, confirm the project environment is properly set up.
+Run these checks **in parallel** and report results before proceeding.
+
+### 1. pnpm workspace
+
+Verify this is a pnpm project:
+
+```
+ls pnpm-workspace.yaml pnpm-lock.yaml
+```
+
+Both files must exist. If missing, stop and report to the user.
+
+### 2. package.json scripts
+
+Read the root `package.json` and confirm these scripts are defined:
+
+- `typecheck`
+- `lint`
+
+If either is missing, stop and report to the user.
+
+### 3. Vitest config
+
+Verify vitest is configured:
+
+```
+ls vitest.config.ts
+```
+
+If missing, stop and report to the user.
+
+---
+
+If all pre-checks pass, report "Environment OK" and proceed to code verification.
+
+## Code Verification
+
+Run the following 3 checks **in order**.
+If errors occur at any step, **fix the code directly** and re-run that step.
+Repeat until no errors remain, then proceed to the next step.
+
+### Step 1: TypeScript Typecheck
+
+```
+pnpm typecheck $ARGUMENTS
+```
+
+On error: Read the failing file to identify the cause, fix with Edit, then re-run typecheck.
+
+### Step 2: ESLint Lint
+
+```
+pnpm lint --fix $ARGUMENTS
+```
+
+On error: Read the failing file, fix with Edit, then re-run lint.
+
+### Step 3: Tests (Vitest)
+
+```
+pnpm vitest $ARGUMENTS --run
+```
+
+Run with `--run` flag for single execution (no watch mode).
+Some packages may require integration tests as configured in vitest.config.ts.
+
+On failure: Read the failing test and related source files to identify the cause, fix with Edit, then re-run tests.
+
+## Completion Criteria
+
+Complete when all 3 steps pass without errors.