liteagents 3.0.0 → 3.6.0

package/packages/opencode/command/debug-method.md

@@ -1,297 +0,0 @@
----
-name: debug-method
-description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions
-usage: /debug-method <bug-or-error-description>
-auto_trigger: false
----
-
-# Debug Method
-
-## Overview
-
-Random fixes waste time and create new bugs. Quick patches mask underlying issues.
-
-**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
-
-**Violating the letter of this process is violating the spirit of debugging.**
-
-## The Iron Law
-
-```
-NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
-```
-
-If you haven't completed Phase 1, you cannot propose fixes.
-
-## When to Use
-
-Use for ANY technical issue:
-- Test failures
-- Bugs in production
-- Unexpected behavior
-- Performance problems
-- Build failures
-- Integration issues
-
-**Use this ESPECIALLY when:**
-- Under time pressure (emergencies make guessing tempting)
-- "Just one quick fix" seems obvious
-- You've already tried multiple fixes
-- Previous fix didn't work
-- You don't fully understand the issue
-
-**Don't skip when:**
-- Issue seems simple (simple bugs have root causes too)
-- You're in a hurry (rushing guarantees rework)
-- Manager wants it fixed NOW (systematic is faster than thrashing)
-
-## The Four Phases
-
-You MUST complete each phase before proceeding to the next.
-
-### Phase 1: Root Cause Investigation
-
-**BEFORE attempting ANY fix:**
-
-1. **Read Error Messages Carefully**
-   - Don't skip past errors or warnings
-   - They often contain the exact solution
-   - Read stack traces completely
-   - Note line numbers, file paths, error codes
-
-2. **Reproduce Consistently**
-   - Can you trigger it reliably?
-   - What are the exact steps?
-   - Does it happen every time?
-   - If not reproducible → gather more data, don't guess
-
-3. **Check Recent Changes**
-   - What changed that could cause this?
-   - Git diff, recent commits
-   - New dependencies, config changes
-   - Environmental differences
-
-4. **Gather Evidence in Multi-Component Systems**
-
-   **WHEN system has multiple components (CI → build → signing, API → service → database):**
-
-   **BEFORE proposing fixes, add diagnostic instrumentation:**
-   ```
-   For EACH component boundary:
-     - Log what data enters component
-     - Log what data exits component
-     - Verify environment/config propagation
-     - Check state at each layer
-
-   Run once to gather evidence showing WHERE it breaks
-   THEN analyze evidence to identify failing component
-   THEN investigate that specific component
-   ```
-
-   **Example (multi-layer system):**
-   ```bash
-   # Layer 1: Workflow
-   echo "=== Secrets available in workflow: ==="
-   echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
-
-   # Layer 2: Build script
-   echo "=== Env vars in build script: ==="
-   env | grep IDENTITY || echo "IDENTITY not in environment"
-
-   # Layer 3: Signing script
-   echo "=== Keychain state: ==="
-   security list-keychains
-   security find-identity -v
-
-   # Layer 4: Actual signing
-   codesign --sign "$IDENTITY" --verbose=4 "$APP"
-   ```
-
-   **This reveals:** Which layer fails (secrets → workflow ✓, workflow → build ✗)
-
-5. **Trace Data Flow**
-
-   **WHEN error is deep in call stack:**
-
-   **REQUIRED SUB-SKILL:** Use trace-back for backward tracing technique
-
-   **Quick version:**
-   - Where does bad value originate?
-   - What called this with bad value?
-   - Keep tracing up until you find the source
-   - Fix at source, not at symptom
-
-### Phase 2: Pattern Analysis
-
-**Find the pattern before fixing:**
-
-1. **Find Working Examples**
-   - Locate similar working code in same codebase
-   - What works that's similar to what's broken?
-
-2. **Compare Against References**
-   - If implementing pattern, read reference implementation COMPLETELY
-   - Don't skim - read every line
-   - Understand the pattern fully before applying
-
-3. **Identify Differences**
-   - What's different between working and broken?
-   - List every difference, however small
-   - Don't assume "that can't matter"
-
-4. **Understand Dependencies**
-   - What other components does this need?
-   - What settings, config, environment?
-   - What assumptions does it make?
-
-### Phase 3: Hypothesis and Testing
-
-**Scientific method:**
-
-1. **Form Single Hypothesis**
-   - State clearly: "I think X is the root cause because Y"
-   - Write it down
-   - Be specific, not vague
-
-2. **Test Minimally**
-   - Make the SMALLEST possible change to test hypothesis
-   - One variable at a time
-   - Don't fix multiple things at once
-
-3. **Verify Before Continuing**
-   - Did it work? Yes → Phase 4
-   - Didn't work? Form NEW hypothesis
-   - DON'T add more fixes on top
-
-4. **When You Don't Know**
-   - Say "I don't understand X"
-   - Don't pretend to know
-   - Ask for help
-   - Research more
-
-### Phase 4: Implementation
-
-**Fix the root cause, not the symptom:**
-
-1. **Create Failing Test Case**
-   - Simplest possible reproduction
-   - Automated test if possible
-   - One-off test script if no framework
-   - MUST have before fixing
-   - **REQUIRED SUB-SKILL:** Use tdd-flow for writing proper failing tests
-
-2. **Implement Single Fix**
-   - Address the root cause identified
-   - ONE change at a time
-   - No "while I'm here" improvements
-   - No bundled refactoring
-
-3. **Verify Fix**
-   - Test passes now?
-   - No other tests broken?
-   - Issue actually resolved?
-
-4. **If Fix Doesn't Work**
-   - STOP
-   - Count: How many fixes have you tried?
-   - If < 3: Return to Phase 1, re-analyze with new information
-   - **If ≥ 3: STOP and question the architecture (step 5 below)**
-   - DON'T attempt Fix #4 without architectural discussion
-
-5. **If 3+ Fixes Failed: Question Architecture**
-
-   **Pattern indicating architectural problem:**
-   - Each fix reveals new shared state/coupling/problem in different place
-   - Fixes require "massive refactoring" to implement
-   - Each fix creates new symptoms elsewhere
-
-   **STOP and question fundamentals:**
-   - Is this pattern fundamentally sound?
-   - Are we "sticking with it through sheer inertia"?
-   - Should we refactor architecture vs. continue fixing symptoms?
-
-   **Discuss with your human partner before attempting more fixes**
-
-   This is NOT a failed hypothesis - this is a wrong architecture.
-
-## Red Flags - STOP and Follow Process
-
-If you catch yourself thinking:
-- "Quick fix for now, investigate later"
-- "Just try changing X and see if it works"
-- "Add multiple changes, run tests"
-- "Skip the test, I'll manually verify"
-- "It's probably X, let me fix that"
-- "I don't fully understand but this might work"
-- "Pattern says X but I'll adapt it differently"
-- "Here are the main problems: [lists fixes without investigation]"
-- Proposing solutions before tracing data flow
-- **"One more fix attempt" (when already tried 2+)**
-- **Each fix reveals new problem in different place**
-
-**ALL of these mean: STOP. Return to Phase 1.**
-
-**If 3+ fixes failed:** Question the architecture (see Phase 4.5)
-
-## your human partner's Signals You're Doing It Wrong
-
-**Watch for these redirections:**
-- "Is that not happening?" - You assumed without verifying
-- "Will it show us...?" - You should have added evidence gathering
-- "Stop guessing" - You're proposing fixes without understanding
-- "Ultrathink this" - Question fundamentals, not just symptoms
-- "We're stuck?" (frustrated) - Your approach isn't working
-
-**When you see these:** STOP. Return to Phase 1.
-
-## Common Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs. |
-| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing. |
-| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. |
-| "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. |
-| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. |
-| "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. |
-| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. |
-| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question pattern, don't fix again. |
-
-## Quick Reference
-
-| Phase | Key Activities | Success Criteria |
-|-------|---------------|------------------|
-| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
-| **2. Pattern** | Find working examples, compare | Identify differences |
-| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |
-| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass |
-
-## When Process Reveals "No Root Cause"
-
-If systematic investigation reveals issue is truly environmental, timing-dependent, or external:
-
-1. You've completed the process
-2. Document what you investigated
-3. Implement appropriate handling (retry, timeout, error message)
-4. Add monitoring/logging for future investigation
-
-**But:** 95% of "no root cause" cases are incomplete investigation.
-
-## Integration with Other Skills
-
-**This skill requires using:**
-- **trace-back** - REQUIRED when error is deep in call stack (see Phase 1, Step 5)
-- **tdd-flow** - REQUIRED for creating failing test case (see Phase 4, Step 1)
-
-**Complementary skills:**
-- **defense-in-depth** - Add validation at multiple layers after finding root cause
-- **test-traps** (Anti-Pattern 6) - Replace arbitrary timeouts identified in Phase 2
-- **verify-done** - Verify fix worked before claiming success
-
-## Real-World Impact
-
-From debugging sessions:
-- Systematic approach: 15-30 minutes to fix
-- Random fixes approach: 2-3 hours of thrashing
-- First-time fix rate: 95% vs 40%
-- New bugs introduced: Near zero vs common

package/packages/opencode/command/live-canvas/README.md

@@ -1,264 +0,0 @@
-# Live Canvas
-
-Click-to-annotate UI design tool for Claude Code. Renders N variants of a component or page in your browser, you click an element and type what to change, and Claude edits the variant file while you watch in the browser. No window switching, no pasted JSON.
-
-Ships as a Claude Code skill plus an MCP channel plugin. Works in every tool liteagents supports (Claude, Droid, Amp, Opencode), but **Live mode only works in Claude Code** — other tools run in JSON mode only (see modes below).
-
----
-
-## How it works
-
-```
- ┌──────────────────────┐      POST /feedback        ┌─────────────────────┐
- │ Overlay in browser   │ ─────────────────────────► │ live-canvas-channel │
- │ (vanilla JS, ~500 lines)│                            │ (Node MCP server)   │
- └──────────────────────┘                            └──────────┬──────────┘
-           ▲                                                     │
-           │ dev server hot-reloads the page                     │ notifications/
-           │ after Claude edits the variant                      │ claude/channel
-           │                                                     ▼
- ┌──────────────────────┐                            ┌─────────────────────┐
- │ Dev server (yours)   │ ◄──── Claude edits ─────── │ Claude Code session │
- │ e.g. pnpm dev :3000  │        variant file        │ (with --dangerously-│
- └──────────────────────┘                            │ load-development-   │
-                                                     │ channels flag)      │
-                                                     └─────────────────────┘
-```
-
-Each Save in the overlay streams into the Claude session as a `<channel>` tag with the variant, element selector, and user comment. Claude edits the corresponding `.claude-design/lab/variants/Variant<X>.tsx` file. Your dev server hot-reloads. You never leave the browser.
-
----
-
-## Modes
-
-The skill asks you which mode you want every time `/live-canvas` runs.
-
-| Mode | Use when | What happens per Save |
-|---|---|---|
-| **Live** | You launched the session with `live-claude` and the channel is up | Comment streams into Claude's context; Claude edits the file; dev server hot-reloads. Toast: "Pushed to Claude ✨". |
-| **JSON** | Any session, any tool (Claude, Droid, Amp, Opencode) | Comment stays local. On Finish/Submit it writes JSONL (or downloads the file if no endpoint). User pastes or says "check" in the CLI to have the assistant act on the whole batch. |
-
-If you pick Live but the channel doesn't answer, the skill stops and tells you to relaunch with `live-claude` (or fall back to JSON). It doesn't silently downgrade — the user always gets to choose.
-
----
-
-## One-time setup (Live mode, Claude Code only)
-
-Run this once per machine. Without it, the skill still works in JSON mode.
-
-### 1. Run the installer
-
-```bash
-bash packages/claude/plugins/live-canvas-marketplace/setup.sh
-```
-
-The installer:
-- copies the marketplace into `~/.claude/plugins/live-canvas-marketplace/` (overwrites any prior install)
-- runs `npm install` inside the channel plugin
-- adds a `live-claude` shell function to `~/.zshrc` and `~/.bashrc` (idempotent — re-runs replace in place)
-
-### 2. Register the marketplace in Claude Code
-
-```
-/plugin marketplace add ~/.claude/plugins/live-canvas-marketplace
-```
-
-### 3. Install the plugin
-
-```
-/plugin install live-canvas-channel@live-canvas-marketplace
-```
-
-### 4. Open a fresh shell
-
-`live-claude` is now available. Use plain `claude` for everything else; use `live-claude` when you want Live mode for this skill.
-
----
-
-## Everyday use
-
-### Start a session
-
-Either `claude` (JSON only) or `live-claude` (Live available).
-
-### Invoke the skill in a project
-
-```
-/live-canvas
-```
-
-Phase 0 always asks which mode you want — Live channel or JSON file — then probes the channel if you picked Live:
-
-| Choice | Channel up? | Skill behavior |
-|---|---|---|
-| Live | yes | Announces Live mode, starts the interview |
-| Live | no | Tells you to relaunch with `live-claude` (or fall back to JSON) |
-| JSON | n/a | Announces JSON mode, starts the interview |
-
-### Interview & generation
-
-Skill asks 5 short questions (scope, pain points, inspiration, persona, constraints). Then generates 5 variants in `.claude-design/lab/variants/` and wires a route at `/__live_canvas` in your app.
-
-### Iterate in the browser
-
-Open `http://localhost:<dev-port>/__live_canvas`. Click **Add Feedback** (bottom right), click any element in any variant, type a one-liner, Save.
-
-- Live mode: toast says "Pushed to Claude ✨", Claude acknowledges and edits the file, dev server hot-reloads.
-- JSON mode: toast says "Saved — submit when ready", pin stays on the element, counter in the Submit button ticks up.
-
-Need the page back? The overlay has a "−" button next to **Add Feedback** that collapses everything to a small circle in the corner — tap to expand again. Useful on mobile where the bar can cover what's underneath.
-
-Keep clicking until a winner emerges.
-
-### Finish
-
-Click the pink **Finish** (Live) or **Submit** (JSON) button:
-
-1. Type the overall direction: e.g. *"Go with B's layout, A's button styling"*
-2. Click Finish
-
-Skill then:
-- Generates `DESIGN_PLAN.md` in project root (winner, files to change, component API, states, a11y checklist)
-- Updates or creates `DESIGN_MEMORY.md` with the patterns it learned
-- Deletes `.claude-design/` and the `/__live_canvas` route
-
-Done.
-
----
-
-## Files and where they live
-
-### In this repo (source)
-
-```
-packages/claude/
-├── skills/live-canvas/
-│   ├── SKILL.md                           # Skill instructions (phases, flow)
-│   ├── DESIGN_PRINCIPLES.md               # UX/a11y/motion reference
-│   ├── README.md                          # This file
-│   ├── dev/post-variants.html             # Standalone demo for local QA of the overlay
-│   └── templates/
-│       ├── overlay-vanilla.js             # Framework-agnostic overlay (~500 lines)
-│       └── lab-banner.html                # "This is a temp lab" notice snippet
-└── plugins/
-    └── live-canvas-marketplace/
-        ├── .claude-plugin/marketplace.json
-        ├── setup.sh                       # Runs npm install and prints manual steps
-        └── plugins/live-canvas-channel/
-            ├── .claude-plugin/plugin.json
-            ├── server.js                  # MCP server + HTTP listener on :8788
-            ├── schema.json                # Feedback payload schema (v1.0)
-            ├── package.json               # @modelcontextprotocol/sdk dep
-            └── README.md                  # Plugin-specific docs (protocol, debug)
-```
-
-### On the user's disk after liteagents install
-
-```
-~/.claude/
-├── skills/live-canvas/                    # Copied from packages/claude/skills/
-└── plugins/live-canvas-marketplace/       # Copied from packages/claude/plugins/
-```
-
-`node_modules/` is NOT copied — `setup.sh` creates it locally via `npm install`.
-
-### After `/plugin install` (Claude Code's own register step)
-
-```
-~/.claude/plugins/cache/live-canvas-marketplace/  # Claude Code's registered copy
-```
-
-Two different dirs:
-- `~/.claude/plugins/live-canvas-marketplace/` — where liteagents puts the source
-- `~/.claude/plugins/cache/live-canvas-marketplace/` — where Claude Code puts its own registered copy after `/plugin install`
-
-The skill checks the cache dir to tell first-time vs returning users apart.
-
-### Per-project, during a session
-
-```
-<project-root>/
-└── .claude-design/
-    ├── lab/variants/VariantA.tsx … VariantE.tsx
-    ├── overlay-vanilla.js (copied into the project's public/static dir)
-    ├── design-brief.json                  # Structured output from the interview
-    └── feedback.jsonl                     # JSON mode only; deleted on Finish
-```
-
-Plus a temporary route (e.g. `app/__live_canvas/page.tsx` for Next.js App Router). Everything under `.claude-design/` and the temporary route is deleted on Finish or Abort.
-
-### What survives after Finish
-
-```
-<project-root>/
-├── DESIGN_PLAN.md         # Winner + implementation steps
-└── DESIGN_MEMORY.md       # Accumulated design-system patterns
-```
-
----
-
-## The install pipeline, end to end
-
-1. **Liteagents installer** copies the skill:
-   - `packages/claude/skills/live-canvas/` → `~/.claude/skills/live-canvas/`
-2. **User, once:** runs `bash packages/claude/plugins/live-canvas-marketplace/setup.sh` → copies marketplace to `~/.claude/plugins/`, runs `npm install`, adds `live-claude` function to `~/.zshrc` and `~/.bashrc`
-3. **User, once:** in a Claude session, runs `/plugin marketplace add ~/.claude/plugins/live-canvas-marketplace` + `/plugin install live-canvas-channel@live-canvas-marketplace`
-4. **User, every session that wants Live mode:** runs `live-claude` (function installed by step 2)
-5. **User, whenever:** `/live-canvas` in any project
-
-Steps 1, 2, 3 are truly one-time. Step 4 is per-session. Step 5 is per-project-use.
-
----
-
-## Troubleshooting
-
-### Channel server starts but skill still routes to JSON
-
-Port 8788 is stuck from an earlier session's server process. Kill it:
-
-```bash
-lsof -i :8788
-kill <pid>
-```
-
-Then `/reload-plugins` in the new session.
-
-### Skill says "No response on :8788" even though I set everything up
-
-Three common causes, in order of likelihood:
-
-1. You didn't start this session with the dev flag. Close it, reopen with `live-claude`.
-2. The plugin subprocess died on startup. In the session, run `/mcp` — look for `live-canvas` with its status. "Failed to connect" means a node/dep error: check `~/.claude/debug/<session-id>.txt` for the stderr.
-3. You never ran step 2 of setup. Re-run `bash ~/.claude/plugins/live-canvas-marketplace/setup.sh`.
-
-### Overlay loads in the browser but no pills appear
-
-The overlay script didn't load. Most common cause: you started the Python server inside the wrong directory so the relative `../templates/overlay-vanilla.js` path couldn't resolve. Start the server one level up and navigate with the `/dev/` prefix.
-
-### "Pushed to Claude ✨" toast appears but nothing happens in the terminal
-
-Either (a) you're not in a dev-flag session, or (b) an older channel server process is answering on 8788 and is stdio-connected to a dead session. See the two troubleshooting items above.
-
-### I want to uninstall
-
-1. Remove the plugin from Claude Code: `/plugin uninstall live-canvas-channel`
-2. Delete the marketplace: `/plugin marketplace remove live-canvas-marketplace`
-3. Remove the dev flag from your alias/shortcut
-4. Rerun liteagents installer in remove mode (or delete `~/.claude/skills/live-canvas/` and `~/.claude/plugins/live-canvas-marketplace/` by hand)
-
----
-
-## Why the multi-step setup can't be hidden
-
-The `--dangerously-load-development-channels` flag is a per-session startup argument of Claude Code itself. A running session can't promote itself to channel-enabled mid-flight; only the next session launched with the flag gets it. Same reason a skill can't silently do `/plugin install` on your behalf — the plugin system needs explicit user consent for research-preview plugins.
-
-Until channels leave research preview and custom channels are allowlisted, step 4 is the irreducible friction. The alias removes the retyping cost.
-
----
-
-## Pointers
-
-- Plugin details: [`~/.claude/plugins/live-canvas-marketplace/plugins/live-canvas-channel/README.md`](../../plugins/live-canvas-marketplace/plugins/live-canvas-channel/README.md)
-- Skill flow: [`SKILL.md`](./SKILL.md)
-- Design principles reference: [`DESIGN_PRINCIPLES.md`](./DESIGN_PRINCIPLES.md)
-- Channels reference (upstream): <https://code.claude.com/docs/en/channels-reference>

package/packages/opencode/command/optimize.md

@@ -1,61 +0,0 @@
----
-name: optimize
-description: Optimize performance [target]
-usage: /optimize <target-area>
-argument-hint: [file-or-function]
-allowed-tools: Read, Edit, Grep, Glob, Bash(git diff *), Bash(git log *), Bash(git grep *), Bash(rg *)
----
-Analyze $ARGUMENTS for performance.
-
-## Examine
-- Time complexity (Big O)
-- Space complexity
-- I/O operations
-- Database queries (N+1?)
-- Unnecessary allocations
-
-## Output
-Per bottleneck:
-- **Location** (`file:line`)
-- **Cost** — what's slow and by how much. Concrete ("N+1 over ~1k rows on
-  every page load"), not vague ("could be faster").
-- **Optimization** — specific change.
-- **Expected improvement** — order-of-magnitude estimate.
-- **Trade-offs** — readability / memory / consistency cost.
-
-## After the analysis — verify, then fix
-
-Performance claims are easy to invent. Validate before acting.
-
-**Verify each bottleneck.** Re-read the cited `file:line` in context.
-Confirm the path is **actually hot** — look for at least one of:
-- a profile / benchmark / log line showing call frequency or duration,
-- the path sits on an obvious hot loop / per-request handler with real
-  volume,
-- the user provided evidence in the request.
-
-Without one of those, the claim is **uncertain — don't optimize on
-speculation.** Mark each finding **confirmed**, **false positive** (with
-reason), or **uncertain (needs profiling data)**.
-
-**Fix what's confirmed and unambiguous** — minimal change, one obvious
-shape, **no behavior change**, no API change. Apply directly. After
-each edit, re-read the changed region and confirm it still computes the
-same answer (perf optimizations that quietly change semantics are the
-worst kind).
-
-**Stop and ask** when (HITL gates — not all the time, only here):
-- the bottleneck is **uncertain** after grounding (no profile / log and
-  not obviously hot),
-- the fix has **multiple reasonable shapes** (cache vs precompute vs
-  batch vs paginate vs index) — present options with tradeoffs, not a
-  chosen path,
-- it changes **public API / response shape / DB schema / caller contract**,
-- it trades **correctness for speed** (lossy approximation, weaker
-  consistency, eventual-vs-strict) — even when "obviously" faster, or
-- it touches **concurrency primitives** (locks, atomics, ordering) —
-  easy to introduce races.
-
-Final report: **confirmed-and-fixed** · **confirmed-but-asking** (why +
-options) · **false-positive** (why) · **uncertain** (what profiling /
-data is needed to decide).