clikit-plugin 0.2.45 → 0.2.47

package/skill/cass-village/SKILL.md

@@ -1,217 +0,0 @@
----
-name: cass-village
-description: Use when delegating multi-agent tasks with persistent memory. Combines CASS procedural memory with beads-village coordination so agents learn from every delegation cycle.
----
-
-# CASS Village Skill
-
-You are running the **cass-village** skill. Memory-informed multi-agent delegation with learning feedback loops.
-
-## How It Works
-
-CliKit integrates with the real [CASS Memory System](https://github.com/Dicklesworthstone/cass_memory_system) (`cm` CLI) when available. If `cm` is not installed, it falls back to an embedded SQLite-based implementation with reduced capabilities.
-
-**With `cm` installed** (recommended): Full playbook management, Bayesian rule scoring, real reflection that distills sessions into rules, outcome tracking, and cross-agent memory sharing.
-
-**Without `cm`** (embedded fallback): Basic context retrieval via FTS5 search, feedback recording, and anti-pattern promotion. Reflection is a stub.
-
-## The Problem
-
-Without shared memory, subagents repeat the same mistakes across sessions. Knowledge dies when a session ends. Tasks get assigned without context about what worked or failed before. This skill closes the loop: memory informs delegation, outcomes feed back into memory.
-
-## Core Loop
-
-```
-PLAN    cm context per task     Hydrate tasks with relevant rules
-  |                                |
-  v                                v
-ENRICH  beads-village_add       Tasks carry CASS context in description
-  |                                |
-  v                                v
-EXECUTE subagents claim         Follow rules, leave inline feedback
-  |                                |
-  v                                v
-LEARN   cm outcome + reflect    Session knowledge becomes persistent rules
-```
-
-## Phase 1: Plan with Memory
-
-Before creating tasks, query CASS for relevant knowledge.
-
-```bash
-# For each task you're about to delegate:
-cm context "<task description>" --json
-```
-
-This returns:
-- **Playbook rules** scored against the task (with rule IDs like `b-8f3a2c`)
-- **History snippets** from past sessions where similar work was done
-- **Anti-patterns** to avoid (rules previously marked harmful)
-
-Extract the top 3-5 rules. These go into the task description.
-
-## Phase 2: Enrich and Delegate
-
-When creating beads-village tasks, embed CASS context directly in the task description.
-
-**Task description template:**
-
-```
-## Task
-<what needs to be done>
-
-## Memory Context
-Following rules from CASS playbook:
-- b-8f3a2c: <rule content> (score: 8.2, proven)
-- b-def456: <rule content> (score: 6.1, established)
-
-Avoid anti-patterns:
-- b-xyz789: PITFALL: <what not to do>
-
-## Prior History
-<relevant snippet from cm context output, if any>
-
-## Feedback Protocol
-When following a rule, comment: // [cass: helpful b-XXXX] - reason
-When a rule causes problems, comment: // [cass: harmful b-XXXX] - reason
-```
-
-**Delegation commands:**
-
-```
-beads-village_add   title, desc (with CASS context), tags, deps
-beads-village_assign  id, role
-```
-
-Tag tasks with roles (`fe`, `be`, `qa`, `devops`, `mobile`) so the right subagent picks them up.
-
-## Phase 3: Subagent Execution
-
-Subagents follow the standard beads cycle with one addition -- inline CASS feedback:
-
-```
-1. beads-village_claim          Pick up the task
-2. Read the Memory Context      Note which rules apply
-3. beads-village_reserve        Lock files
-4. Work                         Follow the rules, write code
-5. Leave inline feedback        // [cass: helpful b-XXX] or // [cass: harmful b-XXX]
-6. beads-village_done           Complete the task
-```
-
-### Inline Feedback Rules
-
-- Reference rule IDs when following them: `"Following b-8f3a2c, using retry with backoff"`
-- Mark rules helpful when they prevent a mistake or speed up work
-- Mark rules harmful when they cause a regression, waste time, or are wrong
-- Be specific in the reason -- vague feedback is discarded during reflection
-
-## Phase 4: Learn from Outcomes
-
-After a batch of tasks completes, the leader records outcomes and triggers reflection.
-
-### Record Task Outcomes
-
-For each completed task, record whether it succeeded or failed and which rules were used:
-
-```bash
-# Successful task that followed specific rules
-cm outcome success b-8f3a2c,b-def456 --json
-
-# Failed task where a rule caused problems
-cm outcome failure b-xyz789 --text "Rate limiter approach caused deadlock" --json
-
-# Mixed results
-cm outcome mixed b-8f3a2c,b-def456 --json
-```
-
-### End-of-Session Reflection
-
-At session end, trigger reflection to distill new rules from the work done:
-
-```bash
-cm reflect --days 1 --json
-```
-
-This processes all session activity (including inline feedback) into:
-- New candidate rules from patterns detected
-- Score updates for existing rules (helpful/harmful counts)
-- Anti-pattern inversions for consistently harmful rules
-- Maturity promotions for consistently helpful rules
-
-### Review Playbook Health
-
-```bash
-# Top performing rules
-cm top 10
-
-# Find stale rules without recent feedback
-cm stale --days 60
-
-# Understand why a rule exists
-cm why b-8f3a2c
-
-# Overall playbook health metrics
-cm stats --json
-```
-
-## Decision Matrix
-
-| Situation | Action |
-|-----------|--------|
-| Creating a new task | Run `cm context` first, embed top rules |
-| Task similar to past failure | Include anti-patterns prominently in description |
-| Subagent following a rule successfully | Leave `// [cass: helpful b-XXX]` inline |
-| Rule caused a problem during execution | Leave `// [cass: harmful b-XXX]` inline |
-| Batch of tasks completed | Run `cm outcome` for each, then `cm reflect` |
-| Starting a new session | `cm context` for the overall goal to prime memory |
-
-## Configuration
-
-In `clikit.config.json`:
-
-```json
-{
-  "hooks": {
-    "cass_memory": {
-      "enabled": true,
-      "cm_path": "/path/to/cm",
-      "context_on_session_created": true,
-      "reflect_on_session_idle": true,
-      "context_limit": 5,
-      "reflect_days": 7,
-      "log": true
-    }
-  }
-}
-```
-
-The `cm_path` option lets you specify a custom path to the `cm` binary. If omitted, it looks for `cm` on your PATH.
-
-## Graceful Degradation
-
-| Component Missing | Behavior |
-|-------------------|----------|
-| `cm` not installed | Falls back to embedded SQLite mode (basic context, no real reflection) |
-| No playbook rules match | Delegate without memory context |
-| `cm context` returns empty | Proceed -- the task is novel, learning starts now |
-| `cm reflect` fails | Outcomes are still recorded, retry later |
-| `cm outcome` without `cm` | Skipped (requires real cm CLI) |
-
-## Leader Checklist
-
-```
-[ ] Run cm context before creating tasks
-[ ] Embed top rules + anti-patterns in task descriptions
-[ ] Include feedback protocol instructions in each task
-[ ] After batch completion, run cm outcome for each task
-[ ] At session end, run cm reflect --days 1
-[ ] Review new/updated rules: cm top 10
-```
-
-## Anti-Patterns
-
-- Dumping the entire playbook into a task description (token waste, noise)
-- Skipping inline feedback (the learning loop breaks)
-- Never running reflection (knowledge stays ephemeral)
-- Assigning tasks without checking CASS first (repeating past mistakes)
-- Ignoring anti-patterns in task descriptions (same failures recur)

package/skill/cloudflare/SKILL.md

@@ -1,96 +0,0 @@
----
-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/design-system-audit/SKILL.md

@@ -1,136 +0,0 @@
----
-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

@@ -1,58 +0,0 @@
----
-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

package/skill/dispatching-parallel-agents/SKILL.md

@@ -1,94 +0,0 @@
----
-name: dispatching-parallel-agents
-description: Use when facing 3+ independent failures. Dispatches concurrent subagent workflows, one agent per problem domain.
----
-
-# Dispatching Parallel Agents Skill
-
-You are running the **dispatching-parallel-agents** skill. Solve multiple independent problems concurrently.
-
-## When to Use
-
-**Use when:**
-- 3+ independent failures detected
-- Problems are in different domains/files
-- Each issue can be solved independently
-- Results can be merged after completion
-
-**Do NOT use when:**
-- Failures are related/dependent
-- Agents would edit the same files
-- Order of fixes matters
-- One fix might break another
-
-## Dispatch Protocol
-
-### 1. Problem Analysis
-```
-For each failure:
-  - Identify problem domain
-  - Determine affected files
-  - Check for file overlap with other problems
-  - Estimate complexity
-```
-
-### 2. Agent Assignment
-```
-Map problems to domains:
-  - Frontend issues → @build with fe context
-  - Backend issues → @build with be context
-  - Test issues → @build with qa context
-  - Config issues → @build with devops context
-```
-
-### 3. Parallel Execution
-- Launch all agents simultaneously
-- Each agent works in isolation
-- No cross-agent communication during work
-- Track progress independently
-
-### 4. Result Merging
-```
-After all agents complete:
-  1. Collect all changes
-  2. Verify no conflicts
-  3. Run integration tests
-  4. Merge results
-```
-
-## Example Scenario
-
-```
-Failures detected:
-1. Login button not rendering (frontend) → Agent A
-2. API timeout on /users (backend) → Agent B
-3. E2E test flaky (testing) → Agent C
-
-Dispatch 3 agents in parallel.
-Each fixes their domain.
-Merge after completion.
-```
-
-## Conflict Detection
-
-Before dispatching, verify:
-- No file overlap between assignments
-- No shared state modifications
-- No ordering dependencies
-
-## Rules
-
-| Rule | Why |
-|------|-----|
-| Minimum 3 problems | Overhead worth it at scale |
-| Independent only | Avoid conflicts |
-| Different files | Safe parallel edits |
-| Merge verification | Catch integration issues |
-
-## Failure Handling
-
-If any agent fails:
-1. Report failure immediately
-2. Other agents continue
-3. Address failed agent's issue separately
-4. Do not block successful completions

package/skill/figma/SKILL.md

@@ -1,34 +0,0 @@
----
-name: figma
-description: Use when you need to access Figma design data, layouts, or assets for implementation.
----
-
-# Figma Skill
-
-You are running the **figma** skill. Access Figma design data via Framelink MCP.
-
-## Capabilities
-
-| Action | Description |
-|--------|-------------|
-| Fetch layout | Get component hierarchy, spacing, dimensions |
-| Get styles | Colors, typography, shadows, borders |
-| Get components | Extract reusable component definitions |
-| Download assets | SVG/PNG export for icons, images |
-
-## Usage
-
-1. Provide Figma file URL or frame ID
-2. Specify what you need (layout, styles, assets)
-3. Skill fetches via Framelink MCP (on-demand)
-4. Convert to code matching your tech stack
-
-## MCP Loading
-
-This skill loads the Framelink MCP server **only when used**. No persistent connection overhead.
-
-## Best Practices
-
-- Request specific frames, not entire files
-- Export assets at appropriate resolutions
-- Match design tokens to your CSS variables

package/skill/frontend-aesthetics/SKILL.md

@@ -1,63 +0,0 @@
----
-name: frontend-aesthetics
-description: Use when building UI components or pages. Prevents AI slop aesthetic with distinctive design direction.
----
-
-# Frontend Aesthetics Skill
-
-You are running the **frontend-aesthetics** skill. No generic AI designs. No purple gradients.
-
-## Core Principle
-
-Pick ONE aesthetic direction. Commit fully. No hybrid compromises.
-
-## Aesthetic Directions
-
-| Direction | Typography | Colors | Motion |
-|-----------|------------|--------|--------|
-| Neo-Brutalist | Bold sans-serif, high contrast | Black/white + 1 accent | Sharp, instant |
-| Glass Morphism | Light, geometric | Translucent overlays | Smooth blur transitions |
-| Swiss Design | Grid-aligned, minimal | Primary + neutrals | Subtle, functional |
-| Retro-Future | Geometric, display | Warm gradients | Smooth, nostalgic |
-| Dark Industrial | Monospace, condensed | Dark + neon accent | Glitch, scan effects |
-| Organic Minimal | Rounded, friendly | Earth tones | Gentle, springy |
-
-## Typography Rules
-
-- NEVER: Inter, Roboto, Arial, Helvetica, system-ui
-- PICK: Space Grotesk, JetBrains Mono, Instrument Sans, Clash Display, Satoshi, DM Sans, Outfit, Plus Jakarta Sans
-- Pair: 1 display font (headlines) + 1 UI font (body)
-- Scale: Use typographic scale (1.25 or 1.333 ratio), not arbitrary sizes
-
-## Color Rules
-
-- Maximum 3 colors: Primary, Secondary, Accent
-- No purple gradients (the hallmark of AI-generated design)
-- Define semantic colors: success, warning, error, info
-- Use CSS variables - no hardcoded hex values in components
-
-## Motion Rules
-
-- Motion must be meaningful: state change, attention, feedback
-- Duration: 150-300ms for micro, 300-500ms for transitions
-- Easing: Use custom easings, not just ease-in-out
-- Reduce motion: Respect prefers-reduced-motion
-
-## Checklist
-
-- [ ] One aesthetic direction chosen and documented
-- [ ] Typography: Display + UI font selected (not Inter/Roboto)
-- [ ] Color palette: Max 3 colors + semantics defined
-- [ ] Motion tokens: Duration, easing, reduction defined
-- [ ] No purple gradients anywhere
-- [ ] No centered hero with 3-column cards layout
-
-## Red Flags
-
-- Make it look modern without direction
-- Inter or Roboto in font stack
-- Purple-to-pink gradients
-- Centered hero + 3-column feature cards
-- Generic placeholder images (stock photos)
-- Inconsistent spacing (use 4px or 8px grid)
-- Multiple competing aesthetic styles