liteagents 2.9.0 → 2.11.0

package/packages/opencode/opencode.jsonc

@@ -113,58 +113,38 @@
     }
   },
   "command": {
-    "systematic-debugging": {
-      "template": "{file:./command/systematic-debugging.md}",
+    "debug-method": {
+      "template": "{file:./command/debug-method.md}",
       "description": "Systematic four-phase debugging framework - investigate root cause before any fixes"
     },
-    "verification-before-completion": {
-      "template": "{file:./command/verification-before-completion.md}",
+    "verify-done": {
+      "template": "{file:./command/verify-done.md}",
       "description": "Verify work meets requirements before marking complete - prevents incomplete deliverables"
     },
     "skill-creator": {
       "template": "{file:./command/skill-creator.md}",
       "description": "Create reusable skills with proper structure, validation, and documentation"
     },
-    "test-driven-development": {
-      "template": "{file:./command/test-driven-development.md}",
+    "tdd-flow": {
+      "template": "{file:./command/tdd-flow.md}",
       "description": "Write test first, watch it fail, write minimal code to pass - ensures tests actually verify behavior"
     },
-    "testing-anti-patterns": {
-      "template": "{file:./command/testing-anti-patterns.md}",
+    "test-traps": {
+      "template": "{file:./command/test-traps.md}",
       "description": "Identify and avoid common testing anti-patterns that create fragile, useless tests"
     },
-    "root-cause-tracing": {
-      "template": "{file:./command/root-cause-tracing.md}",
+    "trace-back": {
+      "template": "{file:./command/trace-back.md}",
       "description": "Trace issues to their root cause using systematic investigation techniques"
     },
-    "condition-based-waiting": {
-      "template": "{file:./command/condition-based-waiting.md}",
-      "description": "Implement robust waiting mechanisms based on conditions rather than fixed delays"
-    },
     "brainstorming": {
       "template": "{file:./command/brainstorming.md}",
       "description": "Facilitate structured brainstorming sessions with proven techniques and frameworks"
     },
-    "code-review": {
-      "template": "{file:./command/code-review.md}",
-      "description": "Conduct thorough code reviews with focus on quality, security, and maintainability"
-    },
     "docs-builder": {
       "template": "{file:./command/docs-builder/SKILL.md}",
       "description": "Create comprehensive project documentation with structured /docs hierarchy"
     },
-    "debug": {
-      "template": "{file:./command/debug.md}",
-      "description": "Debug an issue systematically using structured investigation techniques"
-    },
-    "explain": {
-      "template": "{file:./command/explain.md}",
-      "description": "Explain code for someone new to the codebase"
-    },
-    "git-commit": {
-      "template": "{file:./command/git-commit.md}",
-      "description": "Analyze changes and create intelligent git commits"
-    },
     "live-canvas": {
       "template": "{file:./command/live-canvas.md}",
       "description": "Design UI variations and collect click-to-annotate feedback from the browser (batch mode only on Opencode)"
@@ -177,8 +157,8 @@
       "template": "{file:./command/refactor.md}",
       "description": "Refactor code while maintaining behavior and tests"
     },
-    "review": {
-      "template": "{file:./command/review.md}",
+    "diff-review": {
+      "template": "{file:./command/diff-review.md}",
       "description": "Comprehensive code review including quality, tests, and architecture"
     },
     "security": {
@@ -189,9 +169,9 @@
       "template": "{file:./command/ship.md}",
       "description": "Pre-deployment verification checklist"
     },
-    "friction": {
-      "template": "{file:./command/friction.md}",
-      "description": "Analyze session logs for failure patterns and behavioral signals"
+    "release": {
+      "template": "{file:./command/release.md}",
+      "description": "Deliver a feature end-to-end: verify, docs, merge, tag (publish stays manual)"
     },
     "remember": {
       "template": "{file:./command/remember.md}",
@@ -203,7 +183,7 @@
     },
     "test-generate": {
       "template": "{file:./command/test-generate.md}",
-      "description": "Generate comprehensive test suites for existing code"
+      "description": "Generate tests, run them, and verify each test actually exercises the code (not just passes)"
     },
     "subagent-spawning": {
       "template": "{file:./command/subagent-spawning.md}",

package/packages/subagentic-manual.md

@@ -31,10 +31,10 @@ Install for your platform:
 
 | Platform | Installation | What's Included |
 |----------|--------------|-----------------|
-| **Claude Code** | `cp -r claude/* ~/.claude/` | 11 subagents + 11 skills + 12 commands + live-canvas-channel plugin |
-| **Droid** | `cp -r droid/* ~/.factory/` | 23 commands (subagent references) |
-| **Ampcode** | `cp -r ampcode/* ~/.config/amp/` | 11 subagents + 11 skills + 12 commands |
-| **OpenCode** | `cp -r opencode/* ~/.config/opencode/` | 23 commands (subagent references) |
+| **Claude Code** | `cp -r claude/* ~/.claude/` | 11 subagents + 9 skills + 8 commands + live-canvas-channel plugin |
+| **Droid** | `cp -r droid/* ~/.factory/` | 17 commands (subagent references) |
+| **Ampcode** | `cp -r ampcode/* ~/.config/amp/` | 11 subagents + 9 skills + 8 commands |
+| **OpenCode** | `cp -r opencode/* ~/.config/opencode/` | 17 commands (subagent references) |
 
 **Key Difference**:
 - **Claude Code / Ampcode** implement full subagent system with orchestrator
@@ -50,12 +50,12 @@ Install for your platform:
 - 3 Workflow Agents (PRD, Tasks, Implementation)
 - 8 Specialist Agents (UX, QA, Architecture, Product, Development, etc.)
 
-**11 Skills** - Auto-triggering + manual workflow components
-- test-driven-development, testing-anti-patterns, verification-before-completion (auto-trigger)
-- brainstorming, code-review, systematic-debugging, docs-builder, live-canvas, etc.
+**10 Skills** - Auto-triggering + manual workflow components
+- tdd-flow, test-traps, verify-done (auto-trigger)
+- brainstorming, debug-method, docs-builder, live-canvas, etc.
 
-**12 Commands** - Simple workflow helpers
-- debug, explain, friction, git-commit, optimize, refactor, remember, review, security, ship, stash, test-generate
+**9 Commands** - Simple workflow helpers
+- optimize, refactor, remember, diff-review, security, ship, release, stash, test-generate
 
 **Orchestration System**
 - Automatic intent matching to 9 workflow patterns
@@ -64,7 +64,7 @@ Install for your platform:
 
 ### Droid/OpenCode (Commands Only)
 
-**23 Commands** - All workflow capabilities in command form
+**18 Commands** - All workflow capabilities in command form
 - Combines skills + commands into unified command set
 - Same functionality, different invocation model (no auto-triggering)
 - Includes reference documentation for subagents
@@ -102,38 +102,33 @@ Install for your platform:
 
 ## Commands Reference
 
-### Claude Code / Ampcode: 23 Total (11 Skills + 12 Commands)
+### Claude Code / Ampcode: 18 Total (9 Skills + 9 Commands)
 
 **Auto-Triggering Skills (3)**
-- `test-driven-development` - Write test first, watch fail, minimal passing code
-- `testing-anti-patterns` - Prevent mocking anti-patterns and test pollution
-- `verification-before-completion` - Run verification before claiming done
+- `tdd-flow` - Write test first, watch fail, minimal passing code
+- `test-traps` - Prevent mocking anti-patterns and test pollution
+- `verify-done` - Run verification before claiming done
 
-**Manual Skills (8)**
+**Manual Skills (6)**
 - `brainstorming` - Refine rough ideas through collaborative questioning
-- `code-review` - Review implementation against requirements
-- `condition-based-waiting` - Replace timeouts with condition polling
 - `docs-builder` - Create structured /docs hierarchy
 - `live-canvas` - Design UI variations with click-to-annotate browser feedback. **Claude Code ships a companion MCP channel plugin (`live-canvas-channel`) that enables live mode — each overlay Save streams into the session in real time.** Other tools run in batch mode only. One-time setup required: see `packages/claude/skills/live-canvas/README.md`.
-- `root-cause-tracing` - Trace bugs backward through call stack
+- `trace-back` - Trace bugs backward through call stack
 - `skill-creator` - Guide for creating new skills
-- `systematic-debugging` - Four-phase debugging framework
+- `debug-method` - Four-phase debugging framework
 
-**Simple Commands (12)**
-- `debug` - Systematic investigation techniques
-- `explain` - Explain code for newcomers
-- `friction` - Analyze session logs for failure patterns and behavioral signals
-- `git-commit` - Intelligent commit creation
+**Simple Commands (9)**
 - `optimize` - Performance analysis
 - `refactor` - Maintain behavior while improving code
 - `remember` - Consolidate stashes + friction into project memory
-- `review` - Comprehensive code review
+- `diff-review` - Review a file, branch, or range; verifies findings before fixing
 - `security` - Vulnerability scanning
 - `ship` - Pre-deployment checklist
+- `release` - Deliver a feature end-to-end: verify → docs → merge → tag (publish stays manual)
 - `stash` - Save session context for compaction recovery or handoffs
 - `test-generate` - Test suite generation
 
-### Droid/OpenCode: 23 Commands
+### Droid/OpenCode: 18 Commands
 
 Same functionality as skills+commands, but:
 - All invoked as commands (no auto-triggering)
@@ -142,24 +137,34 @@ Same functionality as skills+commands, but:
 - `live-canvas` runs in batch mode only (no channel plugin — that's Claude Code specific)
 
 **Command Categories**:
-- **Development & Testing (9)**: test-driven-development, testing-anti-patterns, test-generate, code-review, systematic-debugging, root-cause-tracing, debug, condition-based-waiting, verification-before-completion
-- **Code Operations (6)**: refactor, optimize, explain, review, security, ship
-- **Session & Memory (7)**: brainstorming, skill-creator, docs-builder, git-commit, stash, friction, remember
+- **Development & Testing (6)**: tdd-flow, test-traps, test-generate, debug-method, trace-back, verify-done
+- **Code Operations (6)**: refactor, optimize, diff-review, security, ship, release
+- **Session & Memory (5)**: brainstorming, skill-creator, docs-builder, stash, remember
 - **Design (1)**: live-canvas
 
 ---
 
 ## Hot Memory
 
-Lightweight session memory that learns from your usage patterns across sessions.
+Lightweight session memory that learns from your usage patterns across sessions. **`/stash` is
+the only command you actively run — it drives the whole pipeline.** Once a few stashes pile up
+it nudges you to run `/remember`, which does everything else: friction analysis, consolidation,
+and wiring the memory into your agent config file.
 
 ```
-/stash → /friction → /remember
+/stash → (nudge at 5+ unprocessed) → /remember
 ```
 
-1. **`/stash`** - Snapshot current session context to `.claude/stash/`. Use before compaction, handoffs, or ending complex work.
-2. **`/friction`** - Analyze session logs for failure patterns. Scores sessions, clusters failures by signal and tool sequence, outputs actionable antigens to `.claude/friction/`.
-3. **`/remember`** - Consolidate stashes + friction into `.claude/memory/MEMORY.md`. Extracts facts, episodes, and behavioral preferences. References into CLAUDE.md via `@MEMORY.md`.
+1. **`/stash`** - Snapshot current session context to the tool's `…/stash/`. Use before
+   compaction, handoffs, or ending complex work. After saving it counts the unprocessed backlog
+   (`stash files − .processed entries`) and, at 5+, nudges you to run `/remember`. No counter is
+   stored; running `/remember` clears the backlog.
+2. **`/remember`** - Runs friction analysis first (best-effort — scores sessions across *all* your
+   projects from the tool's global sessions root, clusters failures into antigens), then
+   consolidates stashes + antigens into `…/memory/MEMORY.md` and injects `@MEMORY.md` into the
+   **per-tool agent config — `CLAUDE.md` (Claude Code), `AGENTS.md` (Droid / OpenCode), or
+   `AGENT.md` (Ampcode)** — so every future session loads it. Each package writes to its own
+   tool's config file; the global probe list only governs which logs friction *reads*.
 
 **Result:** Project-local memory that accumulates across sessions — no external dependencies, no databases, just markdown.
 
@@ -201,7 +206,7 @@ Orchestrator: "Start systematic implementation?" [Yes/No]
 **Bypass Options**:
 - Direct agent: `@quality-assurance review this code`
 - Role syntax: `As system-architect, design the API layer`
-- Skills: `/test-driven-development login-feature`
+- Skills: `/tdd-flow login-feature`
 
 ### 9 Pre-Defined Workflow Patterns
 
@@ -220,9 +225,9 @@ Each pattern includes conditional decision points requiring user approval.
 ### Droid/OpenCode: Direct Command Invocation
 
 No orchestrator - invoke commands directly:
-- `/debug <issue>`
+- `/diff-review <file-or-branch>`
 - `/refactor <code-section>`
-- `/test-driven-development <feature>`
+- `/tdd-flow <feature>`
 
 Subagent workflows require manual coordination.
 
@@ -257,8 +262,8 @@ Subagent workflows require manual coordination.
 ~/.claude/
 ├── CLAUDE.md           # Registry + orchestrator workflows
 ├── agents/             # 11 subagent implementations (*.md)
-├── skills/             # 11 skills (subdirectories with SKILL.md)
-└── commands/           # 12 commands (*.md)
+├── skills/             # 9 skills (subdirectories with SKILL.md)
+└── commands/           # 8 commands (*.md)
 ```
 
 **Features**:
@@ -272,8 +277,8 @@ Subagent workflows require manual coordination.
 ~/.config/amp/
 ├── AGENT.md            # Reference doc (subagents + commands)
 ├── agents/             # 11 subagent implementations (*.md)
-├── skills/             # 11 skills (subdirectories with SKILL.md)
-└── commands/           # 12 commands (*.md)
+├── skills/             # 9 skills (subdirectories with SKILL.md)
+└── commands/           # 8 commands (*.md)
 ```
 
 **Features**:
@@ -285,7 +290,7 @@ Subagent workflows require manual coordination.
 ```
 ~/.factory/
 ├── AGENTS.md           # Reference doc (subagents + commands)
-└── commands/           # 23 commands (*.md)
+└── commands/           # 17 commands (*.md)
 ```
 
 **Features**:
@@ -297,7 +302,7 @@ Subagent workflows require manual coordination.
 ```
 ~/.config/opencode/
 ├── AGENTS.md           # Reference doc (subagents + commands)
-└── command/            # 23 commands (*.md)
+└── command/            # 17 commands (*.md)
 ```
 
 **Features**:
@@ -326,10 +331,10 @@ color: purple
 **Skills** (`skills/*/SKILL.md`):
 ```yaml
 ---
-id: test-driven-development
-name: test-driven-development
+id: tdd-flow
+name: tdd-flow
 description: Write test first, watch it fail, write minimal code to pass
-usage: /test-driven-development <feature-or-behavior-to-test>
+usage: /tdd-flow <feature-or-behavior-to-test>
 auto_trigger: true
 ---
 ```
@@ -337,11 +342,11 @@ auto_trigger: true
 **Commands** (`commands/*.md`):
 ```yaml
 ---
-id: debug
-name: debug
-description: Debug an issue systematically using structured investigation techniques
-usage: /debug <issue-description>
-argument-hint: [description of the problem]
+id: refactor
+name: refactor
+description: Refactor code while maintaining behavior and tests
+usage: /refactor <code-section>
+argument-hint: [file-or-function]
 ---
 ```
 

package/packages/ampcode/commands/code-review.md

@@ -1,107 +0,0 @@
----
-name: code-review
-description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - reviews implementation against plan or requirements before proceeding
-usage: /code-review <review-scope> <focus-areas>
-auto_trigger: false
----
-
-# Requesting Code Review
-
-Review code thoroughly to catch issues before they cascade.
-
-**Core principle:** Review early, review often.
-
-## When to Request Review
-
-**Mandatory:**
-- After each task in subagent-driven development
-- After completing major feature
-- Before merge to main
-
-**Optional but valuable:**
-- When stuck (fresh perspective)
-- Before refactoring (baseline check)
-- After fixing complex bug
-
-## How to Request
-
-**1. Get git SHAs:**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. Conduct code review:**
-
-Review implementation against requirements and plan
-
-**Placeholders:**
-- `{WHAT_WAS_IMPLEMENTED}` - What you just built
-- `{PLAN_OR_REQUIREMENTS}` - What it should do
-- `{BASE_SHA}` - Starting commit
-- `{HEAD_SHA}` - Ending commit
-- `{DESCRIPTION}` - Brief summary
-
-**3. Act on feedback:**
-- Fix Critical issues immediately
-- Fix Important issues before proceeding
-- Note Minor issues for later
-- Push back if reviewer is wrong (with reasoning)
-
-## Example
-
-```
-[Just completed Task 2: Add verification function]
-
-You: Let me request code review before proceeding.
-
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
-
-[Conduct code review]
-  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
-  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
-  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
-
-[Subagent returns]:
-  Strengths: Clean architecture, real tests
-  Issues:
-    Important: Missing progress indicators
-    Minor: Magic number (100) for reporting interval
-  Assessment: Ready to proceed
-
-You: [Fix progress indicators]
-[Continue to Task 3]
-```
-
-## Integration with Workflows
-
-**Subagent-Driven Development:**
-- Review after EACH task
-- Catch issues before they compound
-- Fix before moving to next task
-
-**Executing Plans:**
-- Review after each batch (3 tasks)
-- Get feedback, apply, continue
-
-**Ad-Hoc Development:**
-- Review before merge
-- Review when stuck
-
-## Red Flags
-
-**Never:**
-- Skip review because "it's simple"
-- Ignore Critical issues
-- Proceed with unfixed Important issues
-- Argue with valid technical feedback
-
-**If reviewer wrong:**
-- Push back with technical reasoning
-- Show code/tests that prove it works
-- Request clarification
-
-See template at: requesting-code-review/code-reviewer.md

package/packages/ampcode/commands/condition-based-waiting.md

@@ -1,122 +0,0 @@
----
-name: condition-based-waiting
-description: Use when tests have race conditions, timing dependencies, or inconsistent pass/fail behavior - replaces arbitrary timeouts with condition polling to wait for actual state changes, eliminating flaky tests from timing guesses
-usage: /condition-based-waiting <condition-type> <timeout-specs>
-auto_trigger: false
----
-
-# Condition-Based Waiting
-
-## Overview
-
-Flaky tests often guess at timing with arbitrary delays. This creates race conditions where tests pass on fast machines but fail under load or in CI.
-
-**Core principle:** Wait for the actual condition you care about, not a guess about how long it takes.
-
-## When to Use
-
-```dot
-digraph when_to_use {
-    "Test uses setTimeout/sleep?" [shape=diamond];
-    "Testing timing behavior?" [shape=diamond];
-    "Document WHY timeout needed" [shape=box];
-    "Use condition-based waiting" [shape=box];
-
-    "Test uses setTimeout/sleep?" -> "Testing timing behavior?" [label="yes"];
-    "Testing timing behavior?" -> "Document WHY timeout needed" [label="yes"];
-    "Testing timing behavior?" -> "Use condition-based waiting" [label="no"];
-}
-```
-
-**Use when:**
-- Tests have arbitrary delays (`setTimeout`, `sleep`, `time.sleep()`)
-- Tests are flaky (pass sometimes, fail under load)
-- Tests timeout when run in parallel
-- Waiting for async operations to complete
-
-**Don't use when:**
-- Testing actual timing behavior (debounce, throttle intervals)
-- Always document WHY if using arbitrary timeout
-
-## Core Pattern
-
-```typescript
-// ❌ BEFORE: Guessing at timing
-await new Promise(r => setTimeout(r, 50));
-const result = getResult();
-expect(result).toBeDefined();
-
-// ✅ AFTER: Waiting for condition
-await waitFor(() => getResult() !== undefined);
-const result = getResult();
-expect(result).toBeDefined();
-```
-
-## Quick Patterns
-
-| Scenario | Pattern |
-|----------|---------|
-| Wait for event | `waitFor(() => events.find(e => e.type === 'DONE'))` |
-| Wait for state | `waitFor(() => machine.state === 'ready')` |
-| Wait for count | `waitFor(() => items.length >= 5)` |
-| Wait for file | `waitFor(() => fs.existsSync(path))` |
-| Complex condition | `waitFor(() => obj.ready && obj.value > 10)` |
-
-## Implementation
-
-Generic polling function:
-```typescript
-async function waitFor<T>(
-  condition: () => T | undefined | null | false,
-  description: string,
-  timeoutMs = 5000
-): Promise<T> {
-  const startTime = Date.now();
-
-  while (true) {
-    const result = condition();
-    if (result) return result;
-
-    if (Date.now() - startTime > timeoutMs) {
-      throw new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`);
-    }
-
-    await new Promise(r => setTimeout(r, 10)); // Poll every 10ms
-  }
-}
-```
-
-See @example.ts for complete implementation with domain-specific helpers (`waitForEvent`, `waitForEventCount`, `waitForEventMatch`) from actual debugging session.
-
-## Common Mistakes
-
-**❌ Polling too fast:** `setTimeout(check, 1)` - wastes CPU
-**✅ Fix:** Poll every 10ms
-
-**❌ No timeout:** Loop forever if condition never met
-**✅ Fix:** Always include timeout with clear error
-
-**❌ Stale data:** Cache state before loop
-**✅ Fix:** Call getter inside loop for fresh data
-
-## When Arbitrary Timeout IS Correct
-
-```typescript
-// Tool ticks every 100ms - need 2 ticks to verify partial output
-await waitForEvent(manager, 'TOOL_STARTED'); // First: wait for condition
-await new Promise(r => setTimeout(r, 200));   // Then: wait for timed behavior
-// 200ms = 2 ticks at 100ms intervals - documented and justified
-```
-
-**Requirements:**
-1. First wait for triggering condition
-2. Based on known timing (not guessing)
-3. Comment explaining WHY
-
-## Real-World Impact
-
-From debugging session (2025-10-03):
-- Fixed 15 flaky tests across 3 files
-- Pass rate: 60% → 100%
-- Execution time: 40% faster
-- No more race conditions

package/packages/ampcode/commands/debug.md

@@ -1,20 +0,0 @@
----
-name: debug
-description: Debug issue [issue]
-usage: /debug <issue-description>
-argument-hint: [description of the problem]
----
-Debug: $ARGUMENTS
-
-## Process
-1. Clarify: What's expected vs actual behavior?
-2. Reproduce: What triggers the issue?
-3. Isolate: Which component/function is responsible?
-4. Trace: Follow the data flow
-5. Fix: Implement and verify the solution
-
-## Output
-- Root cause
-- Affected code paths
-- Fix with explanation
-- Prevention strategy

package/packages/ampcode/commands/explain.md

@@ -1,18 +0,0 @@
----
-name: explain
-description: Explain [code]
-usage: /explain <code-section>
-argument-hint: [file, function, or concept]
-model: claude-3-5-haiku-20241022
----
-Explain $ARGUMENTS.
-
-## Cover
-- What it does (purpose)
-- How it works (step by step)
-- Why it's designed this way
-- Dependencies and side effects
-- Potential gotchas
-
-Assume reader knows the language but not this codebase.
-