clikit-plugin 0.1.0

package/skill/chrome-devtools/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: chrome-devtools
+description: Use for web debugging, performance analysis, network inspection, and runtime diagnostics.
+---
+
+# Chrome DevTools Skill
+
+You are running the **chrome-devtools** skill. Deep debugging via embedded Chrome DevTools MCP.
+
+## Capabilities
+
+| Action | Description |
+|--------|-------------|
+| Inspect network | Request/response headers, timing, payloads |
+| Debug web apps | Breakpoints, call stacks, variable inspection |
+| Analyze performance | Lighthouse audits, Core Web Vitals, profiling |
+| Console access | Execute JS, log analysis, error tracing |
+| DOM inspection | Element selection, computed styles, layout |
+
+## Usage
+
+1. Connect to target page (URL or local dev server)
+2. Select tool: Network, Performance, Console, Elements
+3. Perform inspection or profiling
+4. Export results for analysis
+
+## MCP Loading
+
+This skill uses an embedded Chrome DevTools protocol connection. No external MCP server required.
+
+## Best Practices
+
+- Profile before optimizing to identify real bottlenecks
+- Use network throttling to test slow connections
+- Check both desktop and mobile viewports
+- Export HAR files for network analysis

package/skill/cloudflare/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: cloudflare
+description: Use when deploying to Cloudflare Workers, managing Pages projects, using storage (KV, D1, R2), or configuring Cloudflare infrastructure.
+---
+
+# Cloudflare Skill
+
+Comprehensive Cloudflare platform skill covering Workers, Pages, storage services (KV, D1, R2), AI services (Workers AI, Vectorize), and infrastructure-as-code management.
+
+## Capabilities
+
+- **Workers**: Deploy, manage, debug serverless functions
+- **Pages**: Static site deployment with functions
+- **KV Storage**: Key-value data operations
+- **D1 Database**: SQLite at the edge
+- **R2 Storage**: Object storage (S3-compatible)
+- **Workers AI**: Run ML models at the edge
+- **Vectorize**: Vector database for embeddings
+- **Infrastructure-as-Code**: Wrangler configuration
+
+## When to Use
+
+- Deploying serverless functions to the edge
+- Setting up static sites with edge functions
+- Managing edge storage (KV, D1, R2)
+- Running AI models at the edge
+- Building real-time applications
+- Configuring Cloudflare infrastructure
+
+## Key Tools
+
+- `worker_deploy`: Deploy Worker script
+- `pages_deploy`: Deploy Pages project
+- `kv_get/set/delete`: KV namespace operations
+- `d1_query`: Execute D1 SQL queries
+- `r2_upload/download`: R2 object operations
+- `ai_run`: Execute Workers AI models
+- `vectorize_query`: Vector similarity search
+
+## Example Usage
+
+```
+// Deploy worker
+worker_deploy({
+  name: "api-proxy",
+  script: "./workers/proxy.ts",
+  compatibility_date: "2024-01-01"
+})
+
+// KV operations
+kv_set({
+  namespace: "cache",
+  key: "user:123",
+  value: { name: "Alice", role: "admin" }
+})
+
+// D1 query
+d1_query({
+  database: "app-db",
+  sql: "SELECT * FROM products WHERE category = ?",
+  params: ["electronics"]
+})
+
+// Workers AI
+ai_run({
+  model: "@cf/meta/llama-2-7b-chat-int8",
+  prompt: "Explain edge computing"
+})
+```
+
+## Wrangler Configuration
+
+```toml
+# wrangler.toml
+name = "my-worker"
+main = "src/index.ts"
+compatibility_date = "2024-01-01"
+
+[[kv_namespaces]]
+binding = "CACHE"
+id = "abc123"
+
+[[d1_databases]]
+binding = "DB"
+database_name = "app-db"
+
+[ai]
+binding = "AI"
+```
+
+## Notes
+
+- Requires Cloudflare API token
+- Supports wrangler CLI integration
+- Free tier available for most services
+- Global edge network deployment

package/skill/condition-based-waiting/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: condition-based-waiting
+description: Replace arbitrary timeouts with condition polling. Wait for actual state changes. Eliminates flaky tests from race conditions.
+---
+
+# Condition-Based Waiting Skill
+
+You are running the **condition-based-waiting** skill. Never use arbitrary sleeps. Always wait for conditions.
+
+## The Problem
+
+```javascript
+// BAD: Arbitrary timeout
+await sleep(2000);
+expect(element.isVisible).toBe(true);
+
+// Why it fails:
+// - Too short: Flaky on slow CI
+// - Too long: Wastes time on fast machines
+// - Never correct: Race condition waiting to happen
+```
+
+## The Solution
+
+```javascript
+// GOOD: Wait for condition
+await waitFor(() => expect(element.isVisible).toBe(true), { timeout: 5000 });
+
+// Why it works:
+// - Passes immediately when ready
+// - Fails fast with clear error
+// - No wasted time
+```
+
+## Patterns
+
+### UI Waiting
+```javascript
+// Wait for element
+await page.waitForSelector('.loaded');
+
+// Wait for text
+await waitFor(() => page.textContent('.status') === 'Ready');
+
+// Wait for visibility
+await waitFor(() => element.isVisible());
+```
+
+### API Waiting
+```javascript
+// Wait for response
+await waitFor(async () => {
+  const res = await fetch('/status');
+  const data = await res.json();
+  return data.ready === true;
+});
+
+// Wait for state
+await waitFor(() => store.getState().loaded === true);
+```
+
+### Database Waiting
+```javascript
+// Wait for record
+await waitFor(async () => {
+  const record = await db.find(id);
+  return record !== null;
+});
+```
+
+## Rules
+
+| Pattern | Verdict |
+|---------|---------|
+| `sleep(n)` or `wait(n)` | DELETE. Replace with condition. |
+| `setTimeout` in tests | DELETE. Use polling. |
+| "It works on my machine" | Race condition. Fix with condition. |
+| Fixed delay "to be safe" | Not safe. Use condition. |
+
+## Timeout Strategy
+
+1. Set reasonable timeout (default: 5000ms)
+2. Poll frequently (default: 50ms intervals)
+3. Include state in error message
+4. Consider exponential backoff for external services
+
+## Red Flags
+
+- Any hardcoded delay in test code
+- Comments explaining why timeout is needed
+- Tests that pass locally but fail in CI
+- "Flaky" test label without investigation

package/skill/deep-research/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: deep-research
+description: Use when exploring unfamiliar code or implementing complex features. Structured LSP exploration with memory-first protocol.
+---
+
+# Deep Research Skill
+
+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/`:
+
+```
+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
+```
+
+## 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 |
+
+## Output Format
+
+```markdown
+# [Topic] Research Findings
+
+## Summary
+[Brief overview]
+
+## Key Findings
+
+### Finding 1: [Title]
+- **Confidence**: 8/10
+- **Evidence**: [Code references]
+- **Notes**: [Additional context]
+
+## Architecture
+[Diagram or description]
+
+## Open Questions
+[What needs more investigation]
+
+## Recommendations
+[Based on findings]
+```
+
+## Anti-Patterns
+
+- Skipping LSP operations
+- Not saving to memory
+- Low confidence assertions
+- Missing evidence for claims

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

@@ -0,0 +1,89 @@
+---
+name: defense-in-depth
+description: Validate at every layer. Makes bugs structurally impossible through layered guards.
+---
+
+# Defense in Depth Skill
+
+You are running the **defense-in-depth** skill. Trust nothing. Validate everything.
+
+## Core Principle
+
+Bugs slip through single validation. Multiple validation layers catch what one misses.
+
+## Validation Layers
+
+### 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 3: Environment Guards
+```javascript
+// Runtime environment checks
+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);
+}
+```
+
+## 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 |
+
+## Red Flags
+
+- Assuming caller provides 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.**

package/skill/design-system-audit/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: design-system-audit
+description: Use when auditing design systems for consistency, documenting tokens, or identifying design debt.
+---
+
+# Design System Audit Skill
+
+You are running the **design-system-audit** skill. Consistency is currency.
+
+## Audit Scope
+
+| Area | What to Check |
+|------|---------------|
+| Tokens | Definition, usage, gaps |
+| Components | Documentation, variants, states |
+| Patterns | Consistency, duplication |
+| Documentation | Completeness, accuracy |
+
+## Process
+
+### 1. Token Audit
+
+```bash
+# Extract tokens from codebase
+grep -r "var(--" src/ --include="*.css" | sort | uniq
+
+# Compare with documented tokens
+diff <(grep "export" tokens.ts) <(cat tokens.md)
+```
+
+Check:
+- [ ] All tokens documented
+- [ ] No hardcoded values bypassing tokens
+- [ ] Semantic tokens exist (not just primitive)
+- [ ] Token naming follows convention
+
+### 2. Component Audit
+
+For each component:
+```markdown
+## [Component Name]
+- File: [path]
+- Props: [documented?] [types?]
+- Variants: [list] [documented?]
+- States: [default, hover, focus, disabled, error, loading]
+- Accessibility: [attributes] [tested?]
+- Usage examples: [present?]
+```
+
+Red flags:
+- Undocumented props
+- Missing states
+- No accessibility attributes
+- Hardcoded colors/spacing
+- Duplicate patterns
+
+### 3. Pattern Inventory
+
+```bash
+# Find repeated patterns
+gemini -p "Identify duplicate or inconsistent UI patterns in these components: $(cat components/*.tsx)"
+```
+
+Look for:
+- Multiple button implementations
+- Inconsistent spacing patterns
+- Different shadow definitions
+- Duplicate utility classes
+
+### 4. Design Debt Score
+
+| Category | Weight | Scoring |
+|----------|--------|---------|
+| Undocumented tokens | High | Count × 2 |
+| Missing component states | Medium | Count × 1 |
+| Hardcoded values | High | Count × 3 |
+| Duplicate patterns | Medium | Count × 2 |
+| Outdated docs | Low | Count × 1 |
+
+## Comparison: Implementation vs Design Specs
+
+```bash
+# Compare Figma export with implementation
+gemini -p "Compare this design spec with the implemented component: Spec: $(cat spec.png) Code: $(cat component.tsx)"
+```
+
+Check:
+- [ ] Colors match tokens
+- [ ] Spacing matches grid
+- [ ] Typography matches scale
+- [ ] Components match variants
+- [ ] States match specifications
+
+## Output Template
+
+```markdown
+## Design System Audit Report
+
+### Summary
+- Total components: [N]
+- Documented: [N] ([%])
+- Design debt score: [N]
+
+### Token Gaps
+| Token | Used | Documented | Action |
+|-------|------|------------|--------|
+| --color-primary | Yes | No | Document |
+
+### Component Issues
+| Component | Issue | Priority | Fix |
+|-----------|-------|----------|-----|
+| Button | Missing disabled state | High | Add state |
+
+### Design Debt Items
+1. [Item] - [Location] - [Recommended fix]
+```
+
+## Checklist
+
+- [ ] All tokens inventoried
+- [ ] Token documentation gaps identified
+- [ ] Components catalogued with states
+- [ ] Hardcoded values flagged
+- [ ] Duplicate patterns found
+- [ ] Design debt scored
+- [ ] Report saved to `.opencode/memory/reviews/`
+
+## Red Flags
+
+- Tokens defined but never used
+- Components without documentation
+- Multiple implementations of same pattern
+- Hardcoded values overriding tokens
+- Outdated documentation
+- Missing accessibility documentation
+- No contribution guidelines

package/skill/development-lifecycle/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: development-lifecycle
+description: Use when building a complete feature from scratch. Orchestrates full lifecycle from ideation to verification.
+---
+
+# Development Lifecycle Skill
+
+You are running the **development-lifecycle** skill. Guide features from idea to production.
+
+## Phases
+
+```
+IDEATION → DESIGN → SPECIFICATION → PLANNING → IMPLEMENTATION → VERIFICATION
+```
+
+### Phase 1: Ideation
+- Load: brainstorming skill
+- Goal: Understand the "why" and "what"
+- Output: Clear problem statement, success criteria
+
+### Phase 2: Design
+- Explore architecture options
+- Consider constraints (time, resources, tech stack)
+- Output: Chosen approach, key decisions documented
+
+### Phase 3: Specification
+- Define exact requirements
+- List acceptance criteria
+- Output: spec.md in `.opencode/memory/specs/`
+
+### Phase 4: Planning
+- Load: writing-plans skill
+- Break into 2-5 min tasks
+- Output: plan.md in `.opencode/memory/plans/`
+
+### Phase 5: Implementation
+- Load: executing-plans skill
+- Execute batch by batch
+- Checkpoint after each batch
+
+### Phase 6: Verification
+- Run all tests
+- Type check
+- Lint
+- Build
+- Output: Verification report
+
+## Phase Transitions
+
+Always confirm before moving to next phase:
+- "I've completed [phase]. Ready to move to [next phase]?"
+
+## Rollback
+
+If issues found in later phases:
+1. Document the issue
+2. Roll back to relevant phase
+3. Fix and re-verify downstream