clikit-plugin 0.2.45 → 0.2.47

package/skill/deep-research/SKILL.md

@@ -1,130 +1,61 @@
 ---
 name: deep-research
-description: Use when exploring unfamiliar code or implementing complex features. Structured LSP exploration with memory-first protocol.
+description: Use when exploring unfamiliar code or implementing complex features. Structured LSP exploration with confidence-scored findings saved to memory.
 ---
 
-# Deep Research Skill
+# Deep Research
 
-You are running the **deep-research** skill. Systematic codebase exploration with confidence-scored findings.
-
-## When to Use
-
-- Exploring unfamiliar code
-- Implementing complex features
-- Understanding architecture before changes
-- Debugging across multiple files
-
-## Memory-First Protocol
-
-Always save findings to `.opencode/memory/research/`:
+## Workflow
 
 ```
-memory/research/
-  ├── [topic]-findings.md
-  ├── [topic]-architecture.md
-  └── [topic]-decisions.md
-```
-
-## LSP Operations
-
-Use all 9 LSP operations systematically:
-
-### 1. Go to Definition
-- Trace symbol origins
-- Understand type definitions
-- Find implementation details
-
-### 2. Find References
-- Locate all usages
-- Understand impact of changes
-- Identify consumers
-
-### 3. Go to Type Definition
-- Understand data structures
-- Trace interface contracts
-- Find source types
-
-### 4. Find Implementations
-- Locate concrete implementations
-- Understand polymorphism
-- Find all variants
-
-### 5. Document Symbol
-- Get file overview
-- Understand exports
-- Quick navigation
-
-### 6. Workspace Symbol
-- Find symbols across project
-- Locate related code
-- Cross-file navigation
-
-### 7. Call Hierarchy (Incoming)
-- Find callers
-- Understand entry points
-- Trace data flow up
-
-### 8. Call Hierarchy (Outgoing)
-- Find callees
-- Understand dependencies
-- Trace data flow down
-
-### 9. Rename
-- Preview changes
-- Understand scope
-- Safe refactoring
-
-## Research Workflow
-
-```
-1. Define research question
-2. Start with workspace symbol search
-3. Navigate via go to definition
-4. Trace references for coverage
-5. Map call hierarchy for flow
-6. Document findings with confidence score
-7. Save to memory
+1. Define question
+2. lsp_workspace_symbols → find entry points
+3. lsp_goto_definition → trace origins
+4. lsp_find_references → map all usages
+5. lsp_document_symbols → understand exports
+6. Incoming/outgoing call hierarchy → trace data flow
+7. Score each finding 1–10
+8. Save to memory/research/[topic]-findings.md
 ```
 
 ## Confidence Scoring
 
-Score each finding 1-10:
-
 | Score | Meaning |
 |-------|---------|
-| 1-3 | Speculation, needs verification |
-| 4-6 | Probable, partial evidence |
-| 7-9 | Confident, strong evidence |
-| 10 | Certain, verified in code |
+| 1–3 | Speculation — needs verification |
+| 4–6 | Probable — partial evidence |
+| 7–9 | Confident — strong evidence |
+| 10 | Certain — verified in code |
+
+Never assert anything below 4 without flagging uncertainty.
 
 ## Output Format
 
+Save to `.opencode/memory/research/[topic]-findings.md`:
+
 ```markdown
-# [Topic] Research Findings
+# [Topic] Research
 
 ## Summary
-[Brief overview]
+[1–2 sentences]
 
 ## Key Findings
-
-### Finding 1: [Title]
-- **Confidence**: 8/10
-- **Evidence**: [Code references]
-- **Notes**: [Additional context]
-
-## Architecture
-[Diagram or description]
+### [Finding]
+- Confidence: N/10
+- Evidence: file:line
+- Notes: …
 
 ## Open Questions
-[What needs more investigation]
-
 ## Recommendations
-[Based on findings]
 ```
 
-## Anti-Patterns
+## Red Flags
+
+- Skipping LSP — guessing structure instead of tracing it
+- Not saving findings to memory (lost between sessions)
+- Asserting with confidence < 4 without flagging it
+
+## References
 
-- Skipping LSP operations
-- Not saving to memory
-- Low confidence assertions
-- Missing evidence for claims
+- [LSP tool reference](references/lsp-ops.md) — all LSP tools, when to use each, research sequence
+- MCP: `context7` (library docs) + `grep` (GitHub patterns) — see [mcp.json](mcp.json)

package/skill/deep-research/mcp.json

@@ -0,0 +1,21 @@
+{
+  "mcpServers": {
+    "context7": {
+      "type": "remote",
+      "url": "https://mcp.context7.com/mcp",
+      "description": "Library documentation lookup — resolve library ID then query docs",
+      "tools": [
+        "resolve-library-id",
+        "get-library-docs"
+      ]
+    },
+    "grep": {
+      "type": "remote",
+      "url": "https://mcp.grep.app",
+      "description": "GitHub code search — real-world usage patterns",
+      "tools": [
+        "search"
+      ]
+    }
+  }
+}

package/skill/deep-research/references/lsp-ops.md

@@ -0,0 +1,44 @@
+# LSP Operations Reference
+
+Tools available via LSP in OpenCode. Use these in order during exploration.
+
+## Navigation Tools
+
+| Tool | Use | When |
+|------|-----|------|
+| `lsp_workspace_symbols(query)` | Find symbols across project | Start here — discover entry points |
+| `lsp_goto_definition(file, line, col)` | Jump to symbol definition | Trace where something is implemented |
+| `lsp_find_references(file, line, col)` | Find all usages | Map blast radius before changing |
+| `lsp_document_symbols(file)` | List exports/structure of a file | Understand a file's API |
+| `lsp_hover(file, line, col)` | Show type/doc at position | Understand a symbol's contract |
+
+## Refactoring Tools
+
+| Tool | Use | When |
+|------|-----|------|
+| `lsp_rename(file, line, col, new_name)` | Rename across project | Always prepare_rename first |
+| `lsp_prepare_rename(file, line, col)` | Check if rename is safe | Before every rename |
+| `lsp_code_actions(file, range)` | Suggest fixes/refactors | After diagnostics find issues |
+
+## Quality Tools
+
+| Tool | Use | When |
+|------|-----|------|
+| `lsp_diagnostics(file)` | Show type errors, warnings | Before editing + after every change |
+| `lsp_code_action_resolve(action)` | Apply a code action | After selecting from lsp_code_actions |
+
+## Research Sequence
+
+```
+1. lsp_workspace_symbols("keyword")     → find candidates
+2. lsp_document_symbols("file.ts")      → understand structure
+3. lsp_goto_definition(...)             → trace to source
+4. lsp_find_references(...)             → see all usages
+5. lsp_hover(...)                       → confirm types/contracts
+```
+
+## Call Hierarchy
+
+OpenCode doesn't expose call hierarchy directly — approximate with:
+- **Incoming callers**: `lsp_find_references` on the function
+- **Outgoing callees**: `lsp_document_symbols` + manual trace via `lsp_goto_definition`

package/skill/defense-in-depth/SKILL.md

@@ -1,89 +1,49 @@
 ---
 name: defense-in-depth
-description: Validate at every layer. Makes bugs structurally impossible through layered guards.
+description: Validate at every layer. Makes bugs structurally impossible through entry point, domain, and environment guards.
 ---
 
-# Defense in Depth Skill
+# Defense in Depth
 
-You are running the **defense-in-depth** skill. Trust nothing. Validate everything.
+## Validation Layers
 
-## Core Principle
+| Layer | Where | What to validate |
+|-------|-------|-----------------|
+| 1 — Entry point | API handler, CLI input, form | Input shape, required fields, types |
+| 2 — Business logic | Domain functions | Domain rules, invariants, state |
+| 3 — Environment | App startup | Required env vars, config in prod |
+| 4 — Debug | Dev only | State snapshots, stack traces |
 
-Bugs slip through single validation. Multiple validation layers catch what one misses.
+## Minimal Patterns
 
-## Validation Layers
+```js
+// Layer 1 — entry
+if (!input?.id || typeof input.id !== 'string') throw new Error('id required');
 
-### Layer 1: Entry Point Validation
-```javascript
-// API endpoint, CLI input, user form
-function handler(input) {
-  if (!input || typeof input !== 'object') {
-    throw new Error('Invalid input: expected object');
-  }
-  if (!input.id || typeof input.id !== 'string') {
-    throw new Error('Invalid input: id required');
-  }
-  // ... continue
-}
-```
-
-### Layer 2: Business Logic Validation
-```javascript
-// Domain rules, invariants
-function processOrder(order) {
-  if (order.items.length === 0) {
-    throw new Error('Order must have items');
-  }
-  if (order.total < 0) {
-    throw new Error('Order total cannot be negative');
-  }
-  // ... continue
-}
-```
+// Layer 2 — domain
+if (order.items.length === 0) throw new Error('Order must have items');
 
-### Layer 3: Environment Guards
-```javascript
-// Runtime environment checks
-if (process.env.NODE_ENV === 'production' && !process.env.DATABASE_URL) {
+// Layer 3 — environment
+if (process.env.NODE_ENV === 'production' && !process.env.DATABASE_URL)
   throw new Error('DATABASE_URL required in production');
-}
-```
 
-### Layer 4: Debug Instrumentation
-```javascript
-// Developer sanity checks (removed in production)
-if (process.env.NODE_ENV !== 'production') {
-  console.error('[DEBUG] State:', JSON.stringify(state));
-  console.error('[DEBUG] Stack:', new Error().stack);
-}
+// Layer 4 — debug (dev only)
+if (process.env.NODE_ENV !== 'production')
+  console.error('[DBG]', JSON.stringify(state));
 ```
 
-## Validation Checklist
-
-| Layer | Validated | Confidence |
-|-------|-----------|------------|
-| Entry point | Input shape, types | High |
-| Business logic | Domain rules | Higher |
-| Environment | Config, secrets | Highest |
-| Debug | State snapshots | Debug only |
-
 ## When to Add Each Layer
 
-| Scenario | Add Layer |
-|----------|-----------|
-| New API endpoint | Entry point + Business |
-| New function with external callers | Entry point |
-| Production deployment | Environment guards |
-| Debugging session | Debug instrumentation |
-| Test polluter suspected | Debug instrumentation |
+| Situation | Add |
+|-----------|-----|
+| New API endpoint | L1 + L2 |
+| New function with external callers | L1 |
+| Production deploy | L3 |
+| Debugging / test pollution | L4 |
 
 ## Red Flags
 
-- Assuming caller provides valid input
+- Assuming callers always provide valid input
 - Skipping validation "for performance"
-- Only validating at one layer
-- Removing validation to "fix" tests
-
-## Rule
-
-**Validate at every layer. Make bugs structurally impossible.**
+- Only one layer total
+- Removing validation to make tests pass

package/skill/executing-plans/SKILL.md

@@ -1,54 +1,45 @@
 ---
 name: executing-plans
-description: Use when a plan exists and you need to execute tasks with checkpoints and review.
+description: Use when a plan exists and you need to execute tasks with checkpoints and review after each batch.
 ---
 
-# Executing Plans Skill
+# Executing Plans
 
-You are running the **executing-plans** skill. Execute implementation plans systematically with checkpoints.
-
-## Batch Execution
-
-Default: **3 tasks per batch**
-
-After each batch:
-1. Run verification commands
-2. Summarize changes made
-3. Ask for confirmation to continue
-
-## Execution Flow
+## Flow
 
 ```
-Read plan → Select next batch → Execute → Verify → Checkpoint → Continue/Adjust
+Read plan → batch 3 tasks → execute each → verify → checkpoint → continue/adjust
 ```
 
-## Checkpoint Questions
+## Per-Task Steps
+
+1. Read the task fully
+2. Verify file exists (or create it)
+3. Apply exactly what is specified
+4. Run the verification command
+5. Confirm expected result before moving on
 
-After each batch, ask:
-- "Continuing with next 3 tasks. Proceed? (yes/skip/stop/adjust)"
-- If "skip": Skip current batch, move to next
-- If "stop": Halt execution, summarize progress
-- If "adjust": Modify batch size or plan
+## Checkpoints (every 3 tasks)
 
-## Per-Task Execution
+Ask: `"Continuing with next batch. Proceed? (yes / skip / stop / adjust)"`
 
-1. **Read** the task completely
-2. **Verify** the file exists (or will be created)
-3. **Apply** the exact change specified
-4. **Run** the verification command
-5. **Confirm** expected result
+| Response | Action |
+|----------|--------|
+| `yes` | Continue |
+| `skip` | Skip batch, move to next |
+| `stop` | Halt, summarize progress |
+| `adjust` | Modify batch size or plan |
 
 ## Error Handling
 
-| Error Type | Action |
-|------------|--------|
-| File not found | Create it or ask for clarification |
-| Test fails | Debug, fix, re-run before continuing |
-| Unexpected state | Stop, report, ask for guidance |
+| Error | Action |
+|-------|--------|
+| File not found | Create it or ask |
+| Test fails | Debug and fix before continuing |
+| Unexpected state | Stop, report, ask |
 
 ## Red Flags
 
 - Skipping verification
-- Making changes not in the plan
+- Changes not in the plan
 - Continuing after failure without fixing
-- Modifying batch size without asking

package/skill/finishing-a-development-branch/SKILL.md

@@ -1,97 +1,53 @@
 ---
 name: finishing-a-development-branch
-description: Use when completing development work on a branch. Verifies tests, presents options, executes choice with cleanup.
+description: Use when completing development work on a branch. Verify tests, present 4 options, execute choice with cleanup.
 ---
 
-# Finishing a Development Branch Skill
+# Finishing a Development Branch
 
-You are running the **finishing-a-development-branch** skill. Safe branch completion with user control.
+## Step 1 — Verify
 
-## Prerequisites
-
-- Development work complete
-- In a worktree (recommended)
-- Branch has commits
-
-## Workflow
-
-### 1. Verify Tests
 ```bash
-# Run all tests
-npm test
-
-# If tests fail:
-# - STOP
-# - Report failures
-# - Do NOT proceed to options
+npm test    # or project test command
 ```
 
-**Never merge with failing tests.**
+**If tests fail: STOP. Fix first. Never proceed with failing tests.**
 
-### 2. Present Options
+## Step 2 — Present Options
 
 ```
 Branch [branch-name] ready. Choose:
-
-1. MERGE    - Merge to main and clean up
-2. PR       - Create pull request (keep branch)
-3. KEEP     - Keep branch, continue later
-4. DISCARD  - Delete branch and all changes
-
-What would you like to do?
+  1. MERGE    — merge to main, clean up
+  2. PR       — create pull request, keep branch
+  3. KEEP     — push branch, continue later
+  4. DISCARD  — delete branch and all changes
 ```
 
-### 3. Execute Choice
+## Step 3 — Execute
 
-#### Option 1: MERGE
+**MERGE**
 ```bash
-# Switch to main
-git checkout main
-git pull origin main
-
-# Merge branch
-git merge <branch-name>
-
-# Push to remote
-git push origin main
-
-# Clean up
-git branch -d <branch-name>
-git worktree remove <worktree-path>  # if applicable
+git checkout main && git pull origin main
+git merge <branch> && git push origin main
+git branch -d <branch> && git worktree remove <path>
 ```
 
-#### Option 2: PR
+**PR**
 ```bash
-# Push branch
-git push origin <branch-name>
-
-# Create PR
-gh pr create --title "[title]" --body "[body]"
-
-# Keep worktree for iteration
+git push origin <branch>
+gh pr create --title "<title>" --body "<body>"
 ```
 
-#### Option 3: KEEP
+**KEEP**
 ```bash
-# Just ensure pushed
-git push origin <branch-name>
-
-# Leave worktree intact
-# User can return later
-```
-
-#### Option 4: DISCARD
-```
-⚠️  WARNING: This will DELETE all changes on this branch.
-
-Type "discard" to confirm:
+git push origin <branch>
+# leave worktree intact
 ```
 
+**DISCARD** — require typed confirmation: `"discard"`
 ```bash
-# After typing "discard"
 git checkout main
-git branch -D <branch-name>
-git worktree remove <worktree-path>
+git branch -D <branch> && git worktree remove <path>
 ```
 
 ## Safety Rules
@@ -99,29 +55,12 @@ git worktree remove <worktree-path>
 | Rule | Enforcement |
 |------|-------------|
 | Tests must pass | Block on failure |
-| DISCARD requires typed confirmation | Prevent accidents |
-| Never force merge | User controls flow |
-| Always clean up worktrees | After merge/discard |
-
-## Decision Matrix
-
-| Situation | Recommended |
-|-----------|-------------|
-| Feature complete, tested | MERGE |
-| Needs review | PR |
-| Work in progress | KEEP |
-| Wrong direction | DISCARD |
-
-## Post-Completion
-
-After any option:
-1. Report result
-2. Show current branch status
-3. Suggest next steps if applicable
+| DISCARD | Require typed `"discard"` to confirm |
+| Force push to main | Never |
+| Stale worktrees | Always clean up after merge/discard |
 
-## Anti-Patterns
+## Red Flags
 
 - Merging without test verification
 - Discarding without confirmation
-- Leaving stale worktrees
-- Force pushing to main
+- Leaving stale worktrees after merge

package/skill/playwright/SKILL.md

@@ -1,37 +1,42 @@
 ---
 name: playwright
-description: Use for browser automation, E2E testing, form filling, screenshots, and responsive design validation.
+description: Use for browser automation, E2E testing, form filling, screenshots, and responsive design validation via Playwright MCP.
 ---
 
-# Playwright Skill
-
-You are running the **playwright** skill. Browser automation via Playwright MCP.
+# Playwright
 
 ## Capabilities
 
-| Action | Description |
-|--------|-------------|
-| Navigate pages | Load URLs, handle redirects, wait for content |
+| Task | Action |
+|------|--------|
+| Navigate | Load URLs, handle redirects, wait for content |
 | Fill forms | Input text, select options, upload files |
-| Take screenshots | Full page, element-specific, mobile viewports |
-| Test responsive | Switch viewports, validate breakpoints |
-| Validate UX | Check interactions, accessibility, flows |
-| Test auth flows | Login sequences, session persistence |
-
-## Usage
+| Screenshots | Full page, element-specific, mobile viewport |
+| Responsive testing | Switch viewports, validate breakpoints |
+| Auth flows | Login sequences, session persistence |
+| Assertions | Text content, visibility, element state |
 
-1. Specify the URL or local dev server
-2. Define actions (navigate, click, fill, assert)
-3. Set viewport if testing responsive design
-4. Capture screenshots for verification
+## Workflow
 
-## MCP Loading
-
-This skill loads the Playwright MCP server **only when used**. Clean browser context per session.
+1. Specify URL or local dev server
+2. Define action sequence (navigate → interact → assert)
+3. Set viewport for responsive tests
+4. Capture before/after screenshots as evidence
 
 ## Best Practices
 
-- Use `await page.waitForLoadState('networkidle')` for dynamic content
+- `waitForLoadState('networkidle')` before interacting with dynamic content
 - Take before/after screenshots for visual diffs
-- Test both happy and error paths
+- Test both happy path and error path
 - Clean up sessions to prevent resource leaks
+
+## Red Flags
+
+- Assertions before content has loaded
+- Only testing happy path
+- No cleanup after session
+
+## References
+
+- [Tool reference](references/tool-reference.md) — full tool signatures and common patterns
+- MCP: `playwright` — see [mcp.json](mcp.json)

package/skill/playwright/mcp.json

@@ -0,0 +1,20 @@
+{
+  "mcpServers": {
+    "playwright": {
+      "type": "local",
+      "command": ["npx", "-y", "@playwright/mcp@latest"],
+      "description": "Browser automation — navigate, click, fill, screenshot, assert",
+      "tools": [
+        "playwright_navigate",
+        "playwright_click",
+        "playwright_fill",
+        "playwright_select",
+        "playwright_screenshot",
+        "playwright_evaluate",
+        "playwright_wait_for_selector",
+        "playwright_get_text",
+        "playwright_close"
+      ]
+    }
+  }
+}