@simplysm/claude 13.0.0-beta.22

package/README.md

@@ -0,0 +1,32 @@
+# @simplysm/claude
+
+Simplysm Claude Code skills and agents. Automatically installs via `postinstall` when added as a dev dependency.
+
+## Installation
+
+```bash
+pnpm add -D @simplysm/claude
+# or
+npm install --save-dev @simplysm/claude
+```
+
+Skills and agents are automatically installed to `.claude/` on `pnpm install` / `npm install`.
+
+## How It Works
+
+When installed as a dependency, the `postinstall` script:
+
+1. Copies `sd-*` assets (skills, agents, rules) to the project's `.claude/` directory
+2. Configures `statusLine` in `.claude/settings.json`
+3. Existing `sd-*` entries are replaced with the latest version
+
+Updates also trigger reinstallation (`pnpm up @simplysm/claude`).
+
+## Note
+
+- If using `pnpm install --ignore-scripts`, the postinstall won't run
+- If using `onlyBuiltDependencies` in `pnpm-workspace.yaml`, add `@simplysm/claude` to the list
+
+## 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/rules/sd-context7.md

@@ -0,0 +1,26 @@
+# Simplysm Documentation via Context7 MCP
+
+When you need to look up usage examples or API details for `@simplysm/*` packages, use the Context7 MCP tools.
+
+The simplysm library is registered as `/kslhunter/simplysm` on Context7.
+
+## How to use
+
+Skip `resolve-library-id` (the ID is already known) and call `query-docs` directly:
+
+```
+query-docs(libraryId="/kslhunter/simplysm", query="<your question>")
+```
+
+## Example queries
+
+- `query-docs(libraryId="/kslhunter/simplysm", query="How to define ORM table with columns and primary key")`
+- `query-docs(libraryId="/kslhunter/simplysm", query="SolidJS Select component usage")`
+- `query-docs(libraryId="/kslhunter/simplysm", query="ServiceClient WebSocket RPC call")`
+- `query-docs(libraryId="/kslhunter/simplysm", query="DateTime custom type usage")`
+
+## When to use
+
+- Before writing code that uses an unfamiliar `@simplysm/*` API
+- When unsure about component props, method signatures, or configuration options
+- When looking for usage patterns or code examples within the framework

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: sonnet
+---
+
+# 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