ai-nexus 1.3.8 → 1.3.10

package/README.ko.md

@@ -19,14 +19,9 @@ npx ai-nexus install
 
 ## 문제
 
-Claude Code에 질문할 때마다 **모든** 룰이 로드됩니다:
+Claude Code에 질문할 때마다 **모든** 룰이 로드됩니다 — Git 커밋을 물어보는데 React 룰까지, 스타일링을 하는데 보안 룰까지.
 
-```
-Loading rules... 4,300 lines
-토큰 비용: 요청당 ~5,000 토큰
-```
-
-Git 커밋에 대해 물어보는데 React 룰까지 로드되는 건 낭비입니다.
+룰을 추가할수록 매 프롬프트마다 낭비되는 토큰이 늘어납니다.
 
 ## 해결
 
@@ -41,7 +36,7 @@ Semantic Router 활성화:
   ✗ react.md (건너뜀)
   ✗ security.md (건너뜀)
 
-토큰 비용: ~800 토큰 (84% 절약)
+룰을 얼마든지 추가하세요 — 필요한 것만 로딩됩니다.
 ```
 
 ---
@@ -77,11 +72,11 @@ npx ai-nexus install --rules github.com/your-org/team-rules
 
 ## 지원 도구
 
-| 도구 | 동작 방식 | 토큰 절약 |
+| 도구 | 동작 방식 | 토큰 부담 |
 |------|-----------|-----------|
-| **Claude Code** | 시맨틱 라우터가 프롬프트마다 동적으로 룰 교체 | ~84% |
-| **Cursor** | `.mdc` description 필드를 통한 시맨틱 서치 | ~70% |
-| **Codex** | 정적 `AGENTS.md` (동적 로딩 없음) | - |
+| **Claude Code** | 시맨틱 라우터가 프롬프트마다 동적으로 룰 교체 | 필요한 룰만 로딩 |
+| **Cursor** | `.mdc` description 필드를 통한 시맨틱 서치 | Description 기반 필터링 |
+| **Codex** | 정적 `AGENTS.md` (동적 로딩 없음) | 전체 룰 로딩 |
 
 ---
 

package/README.md

@@ -19,14 +19,9 @@ npx ai-nexus install
 
 ## The Problem
 
-Every time you ask Claude Code a question, it loads **all** your rules:
+Every time you ask Claude Code a question, it loads **all** your rules — React rules when you're asking about Git commits, security rules when you're styling a button.
 
-```
-Loading rules... 4,300 lines
-Token cost: ~5,000 tokens per request
-```
-
-That's tokens wasted on React rules when you're asking about Git commits.
+The more rules you add, the more tokens get wasted on every single prompt.
 
 ## The Solution
 
@@ -41,7 +36,7 @@ Semantic Router activates:
   ✗ react.md (skipped)
   ✗ security.md (skipped)
 
-Token cost: ~800 tokens (84% savings)
+Add as many rules as you want — only the relevant ones are loaded.
 ```
 
 ---
@@ -77,11 +72,11 @@ npx ai-nexus install --rules github.com/your-org/team-rules
 
 ## Supported Tools
 
-| Tool | How it works | Token Savings |
-|------|--------------|---------------|
-| **Claude Code** | Semantic Router dynamically swaps rules per prompt | ~84% |
-| **Cursor** | Semantic Search via `.mdc` description fields | ~70% |
-| **Codex** | Static `AGENTS.md` (no dynamic loading) | - |
+| Tool | How it works | Token overhead |
+|------|--------------|----------------|
+| **Claude Code** | Semantic Router dynamically swaps rules per prompt | Only relevant rules loaded |
+| **Cursor** | Semantic Search via `.mdc` description fields | Description-based filtering |
+| **Codex** | Static `AGENTS.md` (no dynamic loading) | All rules loaded |
 
 ---
 

package/config/commands/debug.md

@@ -0,0 +1,31 @@
+---
+description: Debugging slash command
+keywords: [debug, bug, fix, issue, error]
+---
+
+# /debug
+
+When asked to debug an issue:
+
+1. **Reproduce** — Understand the exact steps to trigger the bug
+2. **Read error** — Analyze the full error message and stack trace
+3. **Locate** — Find the exact line/function where the error originates
+4. **Understand** — Read surrounding code to understand intended behavior
+5. **Fix** — Make the minimal change to fix the root cause
+6. **Verify** — Run tests or demonstrate the fix works
+
+## Debugging Checklist
+- Read the full error message and stack trace
+- Check recent changes (git diff, git log)
+- Verify inputs at the failure point
+- Check for null/undefined values
+- Check for type mismatches
+- Check async/await and promise handling
+- Check environment variables and config
+
+## Rules
+- Fix the root cause, not the symptom
+- Don't add try/catch to hide errors
+- Don't change unrelated code while debugging
+- Write a test that reproduces the bug before fixing
+- Explain what caused the bug and why the fix works

package/config/commands/refactor.md

@@ -0,0 +1,30 @@
+---
+description: Code refactoring slash command
+keywords: [refactor, clean, improve, simplify]
+---
+
+# /refactor
+
+When asked to refactor code:
+
+1. **Analyze first** — Read the entire file before making changes
+2. **Identify issues** — List specific problems (duplication, complexity, naming)
+3. **Propose changes** — Explain what you'll change and why
+4. **Preserve behavior** — Refactoring must not change functionality
+5. **Verify** — Run existing tests after refactoring
+
+## Refactoring Checklist
+- Extract repeated code into functions
+- Simplify nested conditionals (guard clauses, early returns)
+- Rename unclear variables and functions
+- Split large functions (> 50 lines)
+- Split large files (> 300 lines)
+- Remove dead code
+- Replace magic numbers with named constants
+
+## Rules
+- Make one type of change at a time
+- Keep each change small and reviewable
+- Don't add features during refactoring
+- Don't change formatting during logic refactoring
+- If tests don't exist, write them before refactoring

package/config/commands/test.md

@@ -0,0 +1,47 @@
+---
+description: Test generation slash command
+keywords: [test, generate, spec, unit]
+---
+
+# /test
+
+When asked to write tests:
+
+1. **Read the source** — Understand what the code does before writing tests
+2. **Identify cases** — Happy path, edge cases, error cases
+3. **Write tests** — Use AAA pattern (Arrange, Act, Assert)
+4. **Run tests** — Verify they pass
+5. **Check coverage** — Ensure critical paths are covered
+
+## Test Structure
+```typescript
+describe('functionName', () => {
+  it('should return X when given Y', () => {
+    // Arrange
+    const input = createInput();
+
+    // Act
+    const result = functionName(input);
+
+    // Assert
+    expect(result).toBe(expected);
+  });
+
+  it('should throw when input is invalid', () => {
+    expect(() => functionName(null)).toThrow();
+  });
+});
+```
+
+## What to Cover
+- Normal inputs → expected outputs
+- Empty/null/undefined inputs
+- Boundary values (0, -1, MAX)
+- Error conditions and exceptions
+- Async operations (resolve and reject)
+
+## Rules
+- One assertion per test (when practical)
+- No test interdependence — each test runs independently
+- Use descriptive names: "should [expected] when [condition]"
+- Don't test private/internal methods directly

package/config/contexts/debug.md

@@ -0,0 +1,35 @@
+---
+description: Debug mode — systematic bug investigation
+keywords: [debug, investigate, troubleshoot, diagnose]
+---
+
+# Debug Mode
+
+When in debug mode:
+
+## Mindset
+- Be systematic, not random — follow the evidence
+- The bug is in the code, not the framework (usually)
+- Recent changes are the most likely cause
+- Simplify the problem until the cause is obvious
+
+## Investigation Steps
+1. **Reproduce** — Get exact steps, inputs, and expected vs actual output
+2. **Isolate** — Narrow down to the smallest reproducible case
+3. **Trace** — Follow execution path from input to error
+4. **Identify** — Find the exact line where behavior diverges
+5. **Verify hypothesis** — Confirm the cause before fixing
+
+## Common Causes
+- Null/undefined where a value is expected
+- Off-by-one errors in loops or array access
+- Async race conditions (missing await)
+- Stale closures capturing old values
+- Type coercion surprises (== vs ===)
+- Environment differences (dev vs prod config)
+
+## Rules
+- Don't guess — read the code and trace the execution
+- Don't fix multiple things at once
+- Explain the root cause, not just the fix
+- Write a regression test for every bug fixed

package/config/contexts/research.md

@@ -0,0 +1,33 @@
+---
+description: Research mode — explore before implementing
+keywords: [research, explore, investigate, analyze]
+---
+
+# Research Mode
+
+When in research mode:
+
+## Principles
+- Read first, code never — this is a research-only session
+- Explore the codebase thoroughly before drawing conclusions
+- Trust code over documentation — the codebase is the source of truth
+- Exhaust all search methods before saying "not found"
+
+## Process
+1. **Map the system** — Identify key files, entry points, and data flow
+2. **Read related code** — Follow imports, function calls, and references
+3. **Check tests** — Tests reveal intended behavior and edge cases
+4. **Check git history** — `git log` and `git blame` show why code exists
+5. **Summarize findings** — Present what you found with file references
+
+## Output Format
+- State findings as facts with file:line references
+- List assumptions separately from confirmed facts
+- Identify unknowns and suggest how to investigate further
+- Keep responses concise — bullet points over paragraphs
+
+## Rules
+- Don't modify any files
+- Don't suggest changes unless explicitly asked
+- Don't make assumptions — verify by reading code
+- If unsure, say "I need to check X to confirm"

package/config/hooks/README.md

@@ -18,7 +18,7 @@ The semantic router hook analyzes keywords in prompts to **dynamically activate
          ↓
 5. Claude Code loads only necessary rules
          ↓
-6. Token savings!
+6. Only relevant rules loaded!
 ```
 
 ## Installation
@@ -101,10 +101,6 @@ OPENAI_API_KEY=sk-xxx
 ANTHROPIC_API_KEY=sk-ant-xxx
 ```
 
-## Token Savings
+## Token Efficiency
 
-| Method | Rules Loaded | Estimated Tokens |
-|--------|--------------|------------------|
-| Load all | All rules (15) | ~5000 tokens |
-| Semantic Router | Only needed (2-3) | ~800 tokens |
-| **Savings** | | **~84%** |
+Add as many rules as you need — the Semantic Router loads only the relevant ones per prompt, so token usage stays minimal regardless of how many rules you have.

package/config/rules/error-handling.md

@@ -0,0 +1,52 @@
+---
+description: Error handling patterns and best practices
+keywords: [error, exception, handling, try, catch]
+---
+
+# Error Handling
+
+## Principles
+- Handle errors at the beginning of functions
+- Use early returns for error conditions to avoid deep nesting
+- Place the happy path last for readability
+- Use guard clauses for preconditions and invalid states
+
+## Patterns
+- Avoid unnecessary else — use if-return pattern
+- Use custom error types for domain-specific errors
+- Model expected errors as return values, not exceptions
+- Use error boundaries for unexpected errors (React error.tsx)
+
+## Do
+```typescript
+function process(input: string): Result {
+  if (!input) return { error: 'Input required' };
+  if (input.length > MAX) return { error: 'Too long' };
+
+  // Happy path
+  const result = transform(input);
+  return { data: result };
+}
+```
+
+## Don't
+```typescript
+function process(input: string): Result {
+  if (input) {
+    if (input.length <= MAX) {
+      const result = transform(input);
+      return { data: result };
+    } else {
+      return { error: 'Too long' };
+    }
+  } else {
+    return { error: 'Input required' };
+  }
+}
+```
+
+## Logging
+- Log errors with enough context to reproduce
+- Include: what failed, input values, stack trace
+- Never log sensitive data (passwords, tokens, PII)
+- Use structured logging (JSON) in production

package/config/rules/naming.md

@@ -0,0 +1,35 @@
+---
+description: Naming conventions for variables, functions, and files
+keywords: [naming, convention, variable, function]
+---
+
+# Naming Conventions
+
+## Variables
+- Use descriptive names with auxiliary verbs: `isLoading`, `hasError`, `canSubmit`
+- Boolean: prefix with `is`, `has`, `can`, `should`
+- Arrays: use plural nouns (`users`, `items`)
+- Numbers: prefix with `num`, `max`, `min`, `total` (`maxRetries`, `totalCount`)
+
+## Functions
+- Use verbs: `getUser`, `createOrder`, `validateInput`
+- Event handlers: `handleClick`, `onSubmit`
+- Return boolean: `isValid`, `hasPermission`, `canAccess`
+- Async functions: describe the result, not the mechanism (`fetchUser`, not `asyncGetUser`)
+
+## Files and Directories
+- Use lowercase with dashes: `auth-wizard.ts`, `user-profile/`
+- Component files match component name: `UserProfile.tsx`
+- Test files: `user-profile.test.ts`
+- Types: `user.types.ts` or co-locate with source
+
+## Constants
+- UPPER_SNAKE_CASE for true constants: `MAX_RETRIES`, `API_BASE_URL`
+- camelCase for const references: `const defaultConfig = { ... }`
+
+## Avoid
+- Single letter names (except `i` in loops, `e` in event handlers)
+- Abbreviations: `btn`, `usr`, `msg` → `button`, `user`, `message`
+- Generic names: `data`, `info`, `item`, `thing`
+- Hungarian notation: `strName`, `bIsActive`
+- Negated booleans: `isNotReady` → `isReady`

package/config/rules/testing.md

@@ -0,0 +1,37 @@
+---
+description: Testing best practices and conventions
+keywords: [test, testing, unit, integration, e2e, vitest, jest]
+---
+
+# Testing
+
+## Principles
+- Write tests first when fixing bugs (TDD for bug fixes)
+- Test behavior, not implementation details
+- Each test should have a single reason to fail
+- Keep tests independent — no shared mutable state
+
+## Structure
+- Use AAA pattern: Arrange → Act → Assert
+- Use descriptive test names: "should return error when input is empty"
+- Group related tests with `describe` blocks
+- Keep test files next to source: `foo.ts` → `foo.test.ts`
+
+## What to Test
+- Unit tests for pure functions and utilities
+- Integration tests for API endpoints and database queries
+- E2E tests for critical user flows only
+- Edge cases: empty input, null, boundaries, error paths
+
+## What NOT to Test
+- Third-party library internals
+- Trivial getters/setters
+- Framework boilerplate
+- Implementation details that may change
+
+## Practices
+- Prefer real objects over mocks when practical
+- Use factories or builders for test data, not fixtures
+- Run single tests during development, full suite in CI
+- Aim for 80% coverage, but don't chase 100%
+- Failing test first, then make it pass, then refactor

package/config/rules/typescript.md

@@ -0,0 +1,38 @@
+---
+description: TypeScript best practices and coding standards
+keywords: [typescript, ts, type, interface]
+---
+
+# TypeScript
+
+## Key Principles
+- Use TypeScript for all code. Prefer interfaces over types
+- Avoid enums — use const objects or maps instead
+- Use `function` keyword for pure functions
+- Prefer iteration and modularization over duplication
+- Use descriptive variable names with auxiliary verbs (isLoading, hasError)
+
+## Types
+- Prefer `interface` for object shapes, `type` for unions/intersections
+- Use `unknown` over `any`. Narrow types with guards
+- Avoid type assertions (`as`) — prefer type narrowing
+- Use `satisfies` operator for type checking without widening
+- Define return types explicitly for public functions
+
+## Patterns
+- Use discriminated unions for state modeling
+- Prefer `readonly` arrays and properties where possible
+- Use `Record<K, V>` for dictionary types
+- Avoid `null` — prefer `undefined` for optional values
+- Use optional chaining (`?.`) and nullish coalescing (`??`)
+
+## Imports
+- Use ES modules (import/export), not CommonJS (require)
+- Destructure imports when possible
+- Group imports: external → internal → types
+
+## File Structure
+- Exported component → subcomponents → helpers → static content → types
+- One concept per file. Keep files under 300 lines
+- Use lowercase with dashes for directories (components/auth-wizard)
+- Favor named exports over default exports

package/config/skills/api-design.md

@@ -0,0 +1,59 @@
+---
+description: REST API design principles and conventions
+keywords: [api, rest, endpoint, http]
+---
+
+# API Design
+
+## URL Conventions
+- Use nouns, not verbs: `/users`, not `/getUsers`
+- Use plural: `/users`, `/orders`
+- Nest for relationships: `/users/:id/orders`
+- Use kebab-case: `/user-profiles`, not `/userProfiles`
+- Keep URLs shallow — max 3 levels deep
+
+## HTTP Methods
+- GET: Read (idempotent, cacheable)
+- POST: Create
+- PUT: Full replace
+- PATCH: Partial update
+- DELETE: Remove
+
+## Status Codes
+- 200: Success
+- 201: Created
+- 204: No Content (successful delete)
+- 400: Bad Request (validation error)
+- 401: Unauthorized (no/invalid auth)
+- 403: Forbidden (no permission)
+- 404: Not Found
+- 409: Conflict (duplicate)
+- 422: Unprocessable Entity
+- 500: Internal Server Error
+
+## Response Format
+```json
+{
+  "data": { ... },
+  "meta": { "page": 1, "total": 100 }
+}
+```
+
+Error:
+```json
+{
+  "error": {
+    "code": "VALIDATION_ERROR",
+    "message": "Email is required",
+    "details": [{ "field": "email", "issue": "required" }]
+  }
+}
+```
+
+## Best Practices
+- Version your API: `/v1/users`
+- Paginate lists: `?page=1&limit=20`
+- Filter with query params: `?status=active`
+- Use consistent date format (ISO 8601)
+- Rate limit all endpoints
+- Validate all inputs at the boundary

package/config/skills/docker.md

@@ -0,0 +1,50 @@
+---
+description: Docker and containerization best practices
+keywords: [docker, container, dockerfile, compose]
+---
+
+# Docker
+
+## Dockerfile
+- Use multi-stage builds to minimize image size
+- Use specific base image tags, never `latest`
+- Order layers by change frequency (least → most changing)
+- Combine RUN commands to reduce layers
+- Use `.dockerignore` to exclude node_modules, .git, etc.
+
+## Security
+- Don't run as root — use `USER` directive
+- Don't store secrets in images — use build args or runtime env
+- Scan images for vulnerabilities (Trivy, Snyk)
+- Use minimal base images (alpine, distroless, slim)
+
+## Example (Node.js)
+```dockerfile
+FROM node:20-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci --production=false
+COPY . .
+RUN npm run build
+
+FROM node:20-alpine
+WORKDIR /app
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/node_modules ./node_modules
+USER node
+EXPOSE 3000
+CMD ["node", "dist/index.js"]
+```
+
+## Docker Compose
+- Use `depends_on` with health checks
+- Use named volumes for persistent data
+- Set resource limits (memory, CPU)
+- Use `.env` file for environment variables
+
+## Best Practices
+- One process per container
+- Log to stdout/stderr, not files
+- Use health checks
+- Graceful shutdown with SIGTERM handling
+- Tag images with version, not just `latest`

package/config/skills/go.md

@@ -0,0 +1,43 @@
+---
+description: Go coding standards and idioms
+keywords: [go, golang]
+---
+
+# Go
+
+## Style
+- Follow Effective Go and Go Code Review Comments
+- Use `gofmt` / `goimports` — no style debates
+- Keep functions short. If it needs a comment, it's too complex
+- Use meaningful package names — short, lowercase, no underscores
+
+## Error Handling
+- Check errors immediately. Never ignore with `_`
+- Return errors, don't panic. Reserve panic for truly unrecoverable
+- Wrap errors with context: `fmt.Errorf("fetch user %d: %w", id, err)`
+- Use `errors.Is` and `errors.As` for error checking
+- Define sentinel errors: `var ErrNotFound = errors.New("not found")`
+
+## Patterns
+- Accept interfaces, return structs
+- Use composition over inheritance (embed structs)
+- Use table-driven tests
+- Keep interfaces small (1-3 methods)
+- Use `context.Context` as first parameter for cancellation
+
+## Concurrency
+- Don't communicate by sharing memory; share memory by communicating
+- Use channels for coordination, mutexes for state protection
+- Always clean up goroutines (use `context` or `done` channel)
+- Use `sync.WaitGroup` for fan-out patterns
+- Use `errgroup` for concurrent error handling
+
+## Project Layout
+```
+cmd/app/main.go
+internal/
+  service/
+  repository/
+pkg/          # Public libraries only
+go.mod
+```

package/config/skills/nextjs.md

@@ -0,0 +1,41 @@
+---
+description: Next.js App Router and React best practices
+keywords: [nextjs, next, react, app-router, rsc, server-components]
+---
+
+# Next.js / React
+
+## Key Principles
+- Use functional components with TypeScript interfaces
+- Minimize `use client` — prefer Server Components and SSR
+- Use `use client` only for Web API access in small components
+- Rely on Next.js App Router for state changes
+
+## Components
+- Use `function` keyword, not `const`, for components
+- Place static content and interfaces at file end
+- Wrap client components in Suspense with fallback
+- Use dynamic loading for non-critical components
+
+## Data Fetching
+- Fetch data in Server Components, not client
+- Use Server Actions for mutations
+- Model expected errors as return values in Server Actions
+- Avoid `useEffect` for data fetching
+
+## State Management
+- Minimize `useEffect` and `setState`
+- Favor RSC (React Server Components) for data
+- Use `useActionState` with react-hook-form for forms
+- Use Zod for form validation
+
+## Styling
+- Use Tailwind CSS with mobile-first approach
+- Use Shadcn UI and Radix UI for components
+- Use `cn()` utility for conditional classes
+
+## Performance
+- Prioritize Web Vitals (LCP, CLS, FID)
+- Optimize images: WebP format, size data, lazy loading
+- Use `next/image` for all images
+- Use `next/font` for font optimization

package/config/skills/python.md

@@ -0,0 +1,49 @@
+---
+description: Python coding standards and best practices
+keywords: [python, py, django, fastapi, flask]
+---
+
+# Python
+
+## Style
+- Follow PEP 8. Use type hints for all function signatures
+- Use f-strings for formatting, not `.format()` or `%`
+- Prefer list/dict/set comprehensions over loops when readable
+- Use `pathlib.Path` over `os.path`
+
+## Types
+- Add type hints to all functions: parameters and return types
+- Use `Optional[T]` for nullable values
+- Use `TypedDict` for dictionary shapes
+- Use `Protocol` for structural subtyping (duck typing)
+
+## Patterns
+- Use dataclasses or Pydantic models for structured data
+- Prefer `with` statements for resource management
+- Use generators for large datasets (`yield` over building lists)
+- Use `enum.Enum` for fixed choices
+
+## Error Handling
+- Use specific exception types, not bare `except`
+- Use `raise ... from` to preserve exception chains
+- Define custom exceptions for domain errors
+- Use `contextlib.suppress()` for expected exceptions
+
+## Project Structure
+```
+src/
+  __init__.py
+  models/
+  services/
+  api/
+tests/
+  conftest.py
+  test_models/
+pyproject.toml
+```
+
+## Dependencies
+- Use `pyproject.toml` for project config
+- Pin dependency versions in production
+- Use virtual environments (venv, uv, poetry)
+- Separate dev and production dependencies

package/config/skills/rust.md

@@ -0,0 +1,49 @@
+---
+description: Rust coding patterns and best practices
+keywords: [rust, cargo, rs]
+---
+
+# Rust
+
+## Style
+- Follow Rust API Guidelines and clippy lints
+- Use `rustfmt` — no manual formatting
+- Prefer `snake_case` for functions/variables, `CamelCase` for types
+- Keep functions under 50 lines
+
+## Ownership
+- Prefer borrowing (`&T`, `&mut T`) over ownership transfer
+- Use `Clone` only when necessary — avoid implicit copies
+- Use lifetimes only when the compiler can't infer them
+- Prefer `String` for owned data, `&str` for borrowed
+
+## Error Handling
+- Use `Result<T, E>` for recoverable errors
+- Use `?` operator for error propagation
+- Define custom error types with `thiserror`
+- Use `anyhow` for application-level errors
+- Never use `.unwrap()` in production code — use `.expect("reason")`
+
+## Patterns
+- Use `enum` with variants for state machines
+- Prefer iterators over manual loops
+- Use `Option` over sentinel values (null, -1)
+- Use builder pattern for complex struct construction
+- Derive traits: `Debug`, `Clone`, `PartialEq` as needed
+
+## Project Structure
+```
+src/
+  main.rs (or lib.rs)
+  models/
+  services/
+tests/
+  integration/
+Cargo.toml
+```
+
+## Performance
+- Use `&[T]` slices over `Vec<T>` in function parameters
+- Avoid unnecessary allocations — reuse buffers
+- Use `cargo bench` for benchmarking
+- Profile before optimizing

package/config/skills/svelte.md

@@ -0,0 +1,49 @@
+---
+description: Svelte 5 and SvelteKit best practices
+keywords: [svelte, sveltekit]
+---
+
+# Svelte 5
+
+## Key Principles
+- Use runes (`$state`, `$derived`, `$effect`) for reactivity
+- Use TypeScript with `<script lang="ts">`
+- Keep components small — extract logic into modules
+- Use SvelteKit for routing and SSR
+
+## Runes (Svelte 5)
+- `$state()` for reactive variables
+- `$derived()` for computed values (replaces `$:`)
+- `$effect()` for side effects (use sparingly)
+- `$props()` for component props
+- `$bindable()` for two-way binding props
+
+## Components
+- One component per `.svelte` file
+- Use `{#snippet}` for reusable template fragments
+- Use `{@render}` to render snippets
+- Props: `let { title, count = 0 } = $props()`
+
+## SvelteKit
+- Use `+page.svelte` for pages, `+layout.svelte` for layouts
+- Use `+page.server.ts` for server-side data loading
+- Use form actions for mutations
+- Use `$app/navigation` for programmatic navigation
+
+## Structure
+```
+src/
+  lib/
+    components/
+    utils/
+  routes/
+    +page.svelte
+    +layout.svelte
+    api/
+```
+
+## Best Practices
+- Prefer server-side loading over client-side fetch
+- Use `{#each}` with `key` for lists
+- Avoid `$effect` for derived state — use `$derived`
+- Use CSS scoping (default in Svelte)

package/config/skills/vue.md

@@ -0,0 +1,45 @@
+---
+description: Vue 3 Composition API best practices
+keywords: [vue, vuejs, nuxt, composition-api]
+---
+
+# Vue 3
+
+## Key Principles
+- Use Composition API with `<script setup>` syntax
+- Use TypeScript with `defineProps` and `defineEmits`
+- Keep components small and focused
+- Use composables for reusable logic
+
+## Components
+- One component per file (SFC: .vue)
+- Use PascalCase for component names: `UserProfile.vue`
+- Props: use type-safe `defineProps<{ title: string }>()`
+- Emits: use `defineEmits<{ (e: 'update', value: string): void }>()`
+
+## Reactivity
+- Use `ref()` for primitives, `reactive()` for objects
+- Use `computed()` for derived state
+- Use `watch()` sparingly — prefer computed
+- Avoid mutating props — emit events instead
+
+## Composables
+- Name with `use` prefix: `useAuth`, `useFetch`
+- Return reactive refs and functions
+- Keep composables pure — no side effects in setup
+- Extract shared logic into `/composables/` directory
+
+## Structure
+```
+src/
+  components/     # Shared components
+  composables/    # Reusable logic
+  views/          # Page components
+  stores/         # Pinia stores
+  types/          # TypeScript types
+```
+
+## State Management
+- Use Pinia for global state
+- Keep stores small and domain-specific
+- Use `storeToRefs()` for destructuring reactive state

package/dist/utils/semantic-router.js

@@ -216,8 +216,38 @@ const KEYWORD_MAP = {
     '리뷰': { commands: ['review.md'], skills: ['review.md'], agents: ['review-checklist.md'] },
     'react': { skills: ['react.md'] },
     '리액트': { skills: ['react.md'] },
-    'next': { skills: ['react.md'] },
-    'nextjs': { skills: ['react.md'] },
+    'next': { skills: ['nextjs.md'] },
+    'nextjs': { skills: ['nextjs.md'] },
+    'typescript': { rules: ['typescript.md'] },
+    'ts': { rules: ['typescript.md'] },
+    'test': { rules: ['testing.md'], commands: ['test.md'] },
+    'testing': { rules: ['testing.md'], commands: ['test.md'] },
+    '테스트': { rules: ['testing.md'], commands: ['test.md'] },
+    'error': { rules: ['error-handling.md'] },
+    'exception': { rules: ['error-handling.md'] },
+    'naming': { rules: ['naming.md'] },
+    'python': { skills: ['python.md'] },
+    'django': { skills: ['python.md'] },
+    'fastapi': { skills: ['python.md'] },
+    'go': { skills: ['go.md'] },
+    'golang': { skills: ['go.md'] },
+    'rust': { skills: ['rust.md'] },
+    'cargo': { skills: ['rust.md'] },
+    'docker': { skills: ['docker.md'] },
+    'container': { skills: ['docker.md'] },
+    'dockerfile': { skills: ['docker.md'] },
+    'api': { skills: ['api-design.md'] },
+    'rest': { skills: ['api-design.md'] },
+    'endpoint': { skills: ['api-design.md'] },
+    'vue': { skills: ['vue.md'] },
+    'nuxt': { skills: ['vue.md'] },
+    'svelte': { skills: ['svelte.md'] },
+    'sveltekit': { skills: ['svelte.md'] },
+    'refactor': { commands: ['refactor.md'] },
+    '리팩토링': { commands: ['refactor.md'] },
+    'debug': { commands: ['debug.md'], contexts: ['debug.md'] },
+    '디버그': { commands: ['debug.md'], contexts: ['debug.md'] },
+    'bug': { commands: ['debug.md'], contexts: ['debug.md'] },
     'code': { agents: ['code-standards.md'] },
     '코드': { agents: ['code-standards.md'] },
     'standard': { agents: ['code-standards.md'] },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ai-nexus",
-  "version": "1.3.8",
+  "version": "1.3.10",
   "description": "AI coding assistant rule manager for Claude Code, Codex, and Cursor",
   "main": "dist/index.js",
   "bin": {