claude-dev-kit 2.1.0

package/.claude/commands/bs/grok.md

@@ -0,0 +1,37 @@
+---
+description: Run opencode cli with grok llm to execute current promt
+---
+
+# Run Grok LLM
+
+Execute the prompt using Grok LLM via opencode CLI in background mode.
+
+## Instructions
+
+1. If `$ARGUMENTS` is **empty**, ask the user for their prompt and wait for their response.
+
+2. Set `PROMPT` to `$ARGUMENTS` (or the user's response if arguments were empty).
+
+   `PROMPT_ESCAPED` is properly shell-escaped `PROMPT`.
+
+3. **Launch in background** using **Bash** tool:
+   - `command`: `opencode run --model openrouter/x-ai/grok-4.1-fast "PROMPT_ESCAPED"`
+   - `run_in_background`: `true`
+   - `description`: `Grok execution`
+
+4. **Wait for completion** using **TaskOutput** tool:
+   - `task_id`: the task ID returned from step 3
+   - `block`: `true`
+   - Do NOT set any timeout - let it run as long as necessary
+
+5. Display the result clearly:
+   ```
+   ### Grok Response
+   [paste the response here]
+   ```
+
+## Behavior Notes
+
+- Do **not** impose any timeouts. Let the LLM work as long as necessary.
+- Do **not** check intermediate output. Wait for full completion.
+- Do **not** make any code changes or modify files unless the response explicitly requires it and user confirms.

package/.claude/commands/bs/kimi.md

@@ -0,0 +1,37 @@
+---
+description: Run opencode cli with Kimi K2.5 llm to execute current promt
+---
+
+# Run Kimi K2.5 LLM
+
+Execute the prompt using Kimi K2.5 LLM via opencode CLI in background mode.
+
+## Instructions
+
+1. If `$ARGUMENTS` is **empty**, ask the user for their prompt and wait for their response.
+
+2. Set `PROMPT` to `$ARGUMENTS` (or the user's response if arguments were empty).
+
+   `PROMPT_ESCAPED` is properly shell-escaped `PROMPT`.
+
+3. **Launch in background** using **Bash** tool:
+   - `command`: `opencode run --model openrouter/moonshotai/kimi-k2.5 "PROMPT_ESCAPED"`
+   - `run_in_background`: `true`
+   - `description`: `Kimi execution`
+
+4. **Wait for completion** using **TaskOutput** tool:
+   - `task_id`: the task ID returned from step 3
+   - `block`: `true`
+   - Do NOT set any timeout - let it run as long as necessary
+
+5. Display the result clearly:
+   ```
+   ### Kimi Response
+   [paste the response here]
+   ```
+
+## Behavior Notes
+
+- Do **not** impose any timeouts. Let the LLM work as long as necessary.
+- Do **not** check intermediate output. Wait for full completion.
+- Do **not** make any code changes or modify files unless the response explicitly requires it and user confirms.

package/.claude/commands/bs/minimax.md

@@ -0,0 +1,37 @@
+---
+description: Run claude cli with MiniMax LLM to execute current promt
+---
+
+# Run Claude LLM
+
+Execute the prompt using Claude CLI with MiniMax LLM in background mode.
+
+## Instructions
+
+1. If `$ARGUMENTS` is **empty**, ask the user for their prompt and wait for their response.
+
+2. Set `PROMPT` to `$ARGUMENTS` (or the user's response if arguments were empty).
+
+   `PROMPT_ESCAPED` is properly shell-escaped `PROMPT`.
+
+3. **Launch in background** using **Bash** tool:
+   - `command`: `echo "PROMPT_ESCAPED" | env -u CLAUDECODE ccmy -p`
+   - `run_in_background`: `true`
+   - `description`: `MiniMax execution`
+
+4. **Wait for completion** using **TaskOutput** tool:
+   - `task_id`: the task ID returned from step 3
+   - `block`: `true`
+   - Do NOT set any timeout - let it run as long as necessary
+
+5. Display the result clearly:
+   ```
+   ### Claude with MiniMax LLM Response
+   [paste the response here]
+   ```
+
+## Behavior Notes
+
+- Do **not** impose any timeouts. Let the LLM work as long as necessary.
+- Do **not** check intermediate output. Wait for full completion.
+- Do **not** make any code changes or modify files unless the response explicitly requires it and user confirms.

package/.claude/commands/bs/ollama.md

@@ -0,0 +1,71 @@
+---
+description: "Run a prompt with a local Ollama model. Data stays on your machine — no cloud calls. Optionally specify a model with 'model:name prompt'."
+argument-hint: [prompt | model:<name> prompt]
+---
+
+# Run Ollama (Local LLM)
+
+Execute the prompt using a locally running Ollama model. Nothing leaves your machine.
+
+## Instructions
+
+1. If `$ARGUMENTS` is **empty**, ask the user for their prompt and wait for their response.
+
+2. Set `PROMPT` to `$ARGUMENTS` (or the user's response if arguments were empty).
+
+3. **Check for model override in PROMPT:**
+   - If PROMPT starts with `model:` (e.g. `model:codellama explain this code`):
+     - Extract `MODEL` = word after `model:` (e.g. `codellama`)
+     - Set `PROMPT` = rest of the string after the model word
+   - Otherwise, read the active model from providers.json:
+     ```bash
+     python3 -c "import json; d=json.load(open('.claude/providers.json')); print(d['providers']['ollama'].get('model','llama3.2'))" 2>/dev/null || echo "llama3.2"
+     ```
+     Set `MODEL` = result (default: `llama3.2`)
+
+4. **Verify Ollama is running:**
+   ```bash
+   ollama list 2>/dev/null | head -1 || echo "OLLAMA_DOWN"
+   ```
+   If output is `OLLAMA_DOWN` or contains an error:
+   ```
+   Ollama is not running. Start it first:
+     ollama serve
+
+   Then pull a model if you haven't:
+     ollama pull llama3.2
+     ollama pull codellama
+     ollama pull qwen2.5-coder
+
+   Install Ollama: https://ollama.ai
+   ```
+   Stop.
+
+5. **Launch in background** using **Bash** tool:
+   - `command`: `ollama run MODEL "PROMPT_ESCAPED"`
+   - `run_in_background`: `true`
+   - `description`: `Ollama (<MODEL>) execution`
+
+   Replace `MODEL` with the actual model name and `PROMPT_ESCAPED` with the properly shell-escaped prompt.
+
+6. **Wait for completion** using **TaskOutput** tool:
+   - `task_id`: the task ID returned from step 5
+   - `block`: `true`
+   - Do NOT set any timeout — local models can take time on first run
+
+7. Display the result clearly:
+   ```
+   ### Ollama Response [model: <MODEL>] [LOCAL — no cloud]
+
+   [paste the response here]
+   ```
+
+## Behavior Notes
+
+- **Private by design**: all computation happens on your machine, no data is sent to any API
+- Do **not** impose any timeouts — first runs may be slow while the model loads into memory
+- If the model isn't pulled yet, Ollama will automatically download it (this can take several minutes)
+- Use `model:` prefix to override the active model for a one-off: `/bs:ollama model:codellama explain this function`
+- To permanently switch models: `/ai:switch ollama:codellama`
+- To see available models: `ollama list`
+- Do **not** make any code changes or modify files unless explicitly confirmed by the user

package/.claude/commands/code/build-and-fix.md

@@ -0,0 +1,80 @@
+---
+description: Build project and automatically fix simple errors (formatting, linting)
+allowed-tools: Bash(realpath:*), Bash(test:*), Bash(ls:*), Bash(pwd:*)
+---
+
+# Build & Fix Project
+
+Invoke the **build-and-fix** skill to automatically build the project and fix simple compilation errors like formatting and linting issues.
+
+## Purpose
+
+- Build the project and ensure successful compilation
+- Automatically fix simple build errors (formatting, linting)
+- Validate code changes before committing
+- Efficiently debug build failures
+
+## Supported Languages
+
+- JavaScript/TypeScript (npm/yarn/pnpm)
+- Python (pip/poetry/pipenv)
+- Rust (cargo)
+- C++ (cmake)
+
+## Process
+
+1. **Parse arguments** (optional)
+   - If `$ARGUMENTS` is provided, change to that directory first
+   - Otherwise, operate in current working directory
+   - Example: `/code:build-and-fix ./backend` or just `/code:build-and-fix`
+
+2. **Change directory if needed**
+
+   ```bash
+   if [ -n "$ARGUMENTS" ]; then
+     # Resolve to absolute path
+     TARGET_DIR=$(realpath "$ARGUMENTS" 2>/dev/null)
+
+     # Verify directory exists
+     if [ ! -d "$TARGET_DIR" ]; then
+       echo "Error: Directory '$ARGUMENTS' does not exist"
+       exit 1
+     fi
+
+     cd "$TARGET_DIR"
+     echo "Changed to directory: $TARGET_DIR"
+   fi
+   ```
+
+3. **Invoke the build-and-fix skill**
+   - Use the Skill tool to invoke: `skill: "build-and-fix"`
+   - The skill will:
+     - Auto-detect project type
+     - Run build
+     - Parse errors and apply auto-fixes (formatting, linting)
+     - Retry build until success or max retries reached
+
+4. **Report results**
+   - The skill handles all output and reporting
+   - Success: Shows fixes applied and build time
+   - Failure: Shows remaining errors and suggested manual actions
+
+## Examples
+
+```bash
+# Build current directory
+/code:build-and-fix
+
+# Build specific project directory
+/code:build-and-fix ./backend
+
+# Build relative path
+/code:build-and-fix ../api-service
+```
+
+## Notes
+
+- Requires build tools to be pre-installed (npm/cargo/cmake/etc.)
+- Only fixes simple errors (formatting, linting)
+- Cannot fix semantic/logic errors or missing dependencies
+- Max 2 retry cycles for efficiency

package/.claude/commands/code/simplify.md

@@ -0,0 +1,77 @@
+---
+description: Simplify and refine code for clarity and maintainability
+argument-hint: [file-or-pattern]
+---
+
+# Code Simplifier
+
+Invoke the **@"code-simplifier:code-simplifier (agent)"** to simplify and refine code for clarity, consistency, and maintainability while preserving all functionality.
+
+## Purpose
+
+- Simplify code structure and reduce unnecessary complexity
+- Apply project coding standards from CLAUDE.md
+- Enhance readability through clear naming and organization
+- Remove redundant code and abstractions
+- Maintain balance - avoid over-simplification
+
+## Process
+
+1. **Determine scope**
+   - If `$ARGUMENTS` is provided, focus on those specific files/patterns
+   - Otherwise, review the whole project in its current state
+
+2. **Launch the code-simplifier agent**
+   - Use the Task tool with `subagent_type: "code-simplifier:code-simplifier"`
+   - Pass the target scope: `$ARGUMENTS`
+
+3. **The agent will:**
+   - Identify target code sections
+   - Analyze for opportunities to improve clarity and consistency
+   - Apply project-specific best practices
+   - Ensure all functionality remains unchanged
+
+4. **Verify results**
+   - Run tests if available
+   - Run linting/formatting checks
+   - Confirm no behavioral changes
+
+5. **Report statistics**
+   - Lines simplified/removed
+   - Functions refactored
+   - Patterns standardized
+
+## Examples
+
+```bash
+# Simplify entire project
+/code:simplify
+
+# Simplify specific file
+/code:simplify src/utils.ts
+
+# Simplify multiple files
+/code:simplify src/utils.ts src/helpers.ts lib/core.ts
+
+# Simplify matching pattern
+/code:simplify **/*.tsx
+
+# Simplify a directory
+/code:simplify src/components/
+```
+
+## Notes
+
+- Preserves exact functionality - only changes how code is written
+- Follows CLAUDE.md project standards
+- Prefers clarity over brevity
+- Avoids nested ternaries - uses switch/if-else instead
+- Does not over-simplify or create overly clever solutions
+
+## Error Handling
+
+- If no files match the pattern, reports back without making changes
+- Invalid paths are reported explicitly, not silently ignored
+- Syntax errors in target code are flagged before attempting simplification
+- If tests fail after changes, reverts and reports the issue
+- If CLAUDE.md is missing, proceeds with general best practices

package/.claude/commands/dev/backend.md

@@ -0,0 +1,47 @@
+---
+description: "Targeted backend work only. API routes, services, DB queries, auth. Spawns dev-backend → dev-test → dev-reviewer via dev-lead. Pass an issue number or free-text task description."
+argument-hint: [issue-number | task description]
+---
+
+# /dev:backend
+
+Run targeted backend implementation through the dev-lead orchestrator (backend path only).
+
+## Steps
+
+### 1. Parse the task
+
+If `$ARGUMENTS` looks like a number → `gh issue view $ARGUMENTS`
+Otherwise → use the text as the task description
+
+### 2. Find relevant backend files
+
+Search for files related to the task domain:
+```bash
+# Find related route handlers, services, schema
+grep -r "<domain-keyword>" app/api/ lib/ prisma/ --include="*.ts" -l 2>/dev/null | head -10
+```
+
+### 3. Spawn dev-lead with backend-only flag
+
+Use the Task tool:
+```
+description: "Backend implementation only"
+agent: dev-lead
+prompt: |
+  ## Task (backend-only)
+  [issue body or free-text task]
+
+  ## Scope: backend-only
+  Do NOT spawn dev-frontend.
+  Spawn: dev-backend → dev-test → dev-reviewer → validate
+
+  ## Relevant files found
+  [list from step 2]
+
+  ## Validation commands (from CLAUDE.md)
+  [lint, test, build commands]
+```
+
+### 4. Report
+Return the list of files created/modified and validation gate results.

package/.claude/commands/dev/e2e.md

@@ -0,0 +1,49 @@
+---
+description: "Write E2E tests for a user flow. Pass a description of the flow or an issue number. Spawns dev-e2e via dev-lead."
+argument-hint: [flow description | issue-number]
+---
+
+# /dev:e2e
+
+Write Playwright or Cypress E2E tests for a user journey.
+
+## Steps
+
+### 1. Parse the task
+
+If `$ARGUMENTS` is an issue number → `gh issue view <N>` to get acceptance criteria
+Otherwise → use the text as the flow description
+
+### 2. Find existing E2E spec as pattern
+
+```bash
+find . -name "*.spec.ts" -path "*/e2e/*" -o -name "*.cy.ts" 2>/dev/null | head -2
+```
+
+### 3. Detect E2E runner
+
+```bash
+ls playwright.config.* cypress.config.* 2>/dev/null
+```
+
+### 4. Spawn dev-lead with e2e-only flag
+
+Use the Task tool:
+```
+description: "Write E2E tests for flow"
+agent: dev-lead
+prompt: |
+  ## Task (e2e-only)
+  Write E2E tests for this user journey:
+  [acceptance criteria or flow description]
+
+  ## Scope: e2e-only
+  Spawn: dev-e2e → dev-reviewer
+
+  ## E2E runner: [playwright | cypress]
+  ## Pattern reference: [existing spec file path]
+  ## Base URL: [from CLAUDE.md or ask]
+```
+
+### 5. Report
+Return test files created and selector additions.

package/.claude/commands/dev/frontend.md

@@ -0,0 +1,45 @@
+---
+description: "Targeted frontend work only. Components, pages, state, styling. Spawns dev-frontend → dev-test → dev-e2e → dev-reviewer via dev-lead. Pass an issue number or task description."
+argument-hint: [issue-number | task description]
+---
+
+# /dev:frontend
+
+Run targeted frontend implementation through the dev-lead orchestrator (frontend path only).
+
+## Steps
+
+### 1. Parse the task
+
+If `$ARGUMENTS` looks like a number → `gh issue view $ARGUMENTS`
+Otherwise → use the text as the task description
+
+### 2. Find relevant frontend files
+
+```bash
+grep -r "<domain-keyword>" app/ components/ src/ --include="*.tsx" --include="*.vue" --include="*.svelte" -l 2>/dev/null | head -10
+```
+
+### 3. Spawn dev-lead with frontend-only flag
+
+Use the Task tool:
+```
+description: "Frontend implementation only"
+agent: dev-lead
+prompt: |
+  ## Task (frontend-only)
+  [issue body or free-text task]
+
+  ## Scope: frontend-only
+  Do NOT spawn dev-backend.
+  Spawn: dev-frontend → dev-test → dev-e2e → dev-reviewer → validate
+
+  ## Relevant files found
+  [list from step 2]
+
+  ## Validation commands (from CLAUDE.md)
+  [lint, test, E2E, build commands]
+```
+
+### 4. Report
+Return files created/modified and gate results.

package/.claude/commands/dev/review.md

@@ -0,0 +1,48 @@
+---
+description: "Review the current branch's changes. Returns a structured PASS/FAIL report with security, correctness, pattern, type safety, and test quality checks."
+argument-hint: [issue-number for context | empty]
+---
+
+# /dev:review
+
+Run a structured code review on the current branch via the `dev-reviewer` sub-agent.
+
+## Steps
+
+### 1. Get fresh diff
+```bash
+git diff main...HEAD --stat
+git diff main...HEAD
+```
+
+### 2. Get issue context (optional)
+If `$ARGUMENTS` is an issue number → `gh issue view <N>` to get acceptance criteria for correctness review.
+
+### 3. Spawn dev-lead with review-only flag
+
+Use the Task tool:
+```
+description: "Review current branch changes"
+agent: dev-lead
+prompt: |
+  ## Task (review-only)
+  Review the changes on the current branch. Do NOT implement anything.
+
+  ## Scope: review-only
+  Spawn ONLY: dev-reviewer
+
+  ## Git diff
+  [paste full diff here]
+
+  ## Acceptance Criteria (for correctness check)
+  [from issue if available, otherwise "N/A"]
+
+  ## Domain context
+  [note if changes touch payments, auth, or data migration — for risk scoring]
+```
+
+### 4. Present report
+Return the full review report with PASS/FAIL verdict and issue table.
+
+If FAIL: list the BLOCKERs that must be resolved.
+If PASS with WARNINGs: show warnings but confirm it is safe to merge.

package/.claude/commands/dev/test.md

@@ -0,0 +1,54 @@
+---
+description: "Write unit/integration tests for specific files. Pass file paths or an issue number. Spawns dev-test via dev-lead."
+argument-hint: [file-paths | issue-number]
+---
+
+# /dev:test
+
+Write tests for existing files that lack coverage.
+
+## Steps
+
+### 1. Identify files to test
+
+If `$ARGUMENTS` looks like file paths → use them directly
+If `$ARGUMENTS` is an issue number → `gh issue view <N>`, then find the implementation files
+Otherwise → ask: "Which files need tests?"
+
+### 2. Find existing test patterns
+
+```bash
+# Find 1-2 representative test files as pattern reference
+find . -name "*.test.ts" -o -name "*.spec.ts" -o -name "*_test.py" 2>/dev/null | head -3
+```
+
+### 3. Read CLAUDE.md for test command
+
+### 4. Spawn dev-lead with test-only flag
+
+Use the Task tool:
+```
+description: "Write tests for listed files"
+agent: dev-lead
+prompt: |
+  ## Task (tests-only)
+  Write comprehensive unit tests for the following files:
+  [file list]
+
+  ## Scope: tests-only
+  Do NOT spawn dev-backend or dev-frontend.
+  Spawn: dev-test → dev-reviewer
+
+  ## Pattern reference files
+  [1-2 example test file paths]
+
+  ## Test command
+  [from CLAUDE.md]
+```
+
+### 5. Run tests to verify
+```bash
+[TEST_CMD] --testPathPatterns='<pattern>'
+```
+
+Report coverage results.