liteagents 2.9.0 → 2.11.0

package/packages/claude/skills/condition-based-waiting/SKILL.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/droid/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/droid/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/droid/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/droid/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.
-

package/packages/droid/commands/friction.md

@@ -1,139 +0,0 @@
----
-name: friction
-description: Analyze session behavior patterns
-usage: /friction <sessions-path>
-argument-hint: <sessions-path>
----
-
-Analyze Claude Code session logs for friction signals, behavioral patterns, and failure antigens.
-
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-
-**Argument: sessions-path (required)**
-
-Path to the Droid sessions directory containing JSONL files.
-- Example: `/friction ~/.factory/projects/-home-hamr-PycharmProjects-aurora/`
-- If no argument provided, ask the user for the path. Do NOT guess.
-
-**What it does**
-
-Runs friction analysis on session JSONL files and writes results to `.factory/friction/` in the current project.
-
-**Steps**
-
-1. **Validate path**
-   - The argument `$ARGUMENTS` is the sessions path
-   - Verify the path exists and contains `.jsonl` files
-   - If path doesn't exist or has no JSONL files, tell the user and stop
-   - Count total session files found
-
-2. **Run friction.js** (bundled at `commands/friction/friction.js`)
-   - Look for friction.js in order:
-     1. `~/.factory/commands/friction/friction.js` (installed)
-     2. `packages/droid/commands/friction/friction.js` (package development)
-   - If found, run: `node <path-to-friction.js> "$ARGUMENTS"`
-   - If it does NOT exist anywhere, fall back to running the analysis manually (step 3)
-   - If friction.js succeeds, skip to step 7
-
-3. **Manual analysis fallback** (only if friction.js not available)
-   - For each `.jsonl` session file in the path:
-     - Read the file
-     - Extract signals using these patterns:
-
-   | Signal | Weight | How to detect |
-   |---|---|---|
-   | `user_intervention` | 10 | User message contains `/stash` |
-   | `session_abandoned` | 10 | Last 3 turns have friction > 15 and no `exit_success` |
-   | `false_success` | 8 | LLM text contains "done"/"complete"/"fixed" AND next tool result has error |
-   | `no_resolution` | 8 | Session has `exit_error` signals but no `exit_success` after them |
-   | `tool_loop` | 6 | Same tool called 3+ times with identical arguments |
-   | `rapid_exit` | 6 | <3 turns AND ends with error |
-   | `interrupt_cascade` | 5 | Multiple `request_interrupted` within 60 seconds |
-   | `user_curse` | 5 | User message matches profanity patterns |
-   | `request_interrupted` | 2.5 | Turn has `is_interrupted: true` or ESC/Ctrl+C signal |
-   | `exit_error` | 1 | Tool result has non-zero exit code |
-   | `repeated_question` | 1 | User asks same question twice (fuzzy match) |
-   | `long_silence` | 0.5 | >10 minute gap between turns |
-   | `user_negation` | 0.5 | User message starts with "no", "wrong", "didn't work" |
-   | `compaction` | 0.5 | System message indicates context compaction |
-
-4. **Score each session**
-   - Accumulate weighted signal scores (no subtraction, only accumulation)
-   - Track peak friction score
-   - Classify session quality:
-     - **BAD**: has `user_intervention` or `session_abandoned`
-     - **FRICTION**: has `user_curse` or `false_success`
-     - **ROUGH**: peak friction >= 15, no intervention
-     - **OK**: low friction, completed normally
-     - **ONE-SHOT**: single turn, not interactive (filter out)
-
-5. **Aggregate stats**
-   - Count sessions by quality
-   - Calculate BAD rate
-   - Identify worst and best sessions
-   - Daily trend if sessions span multiple days
-
-6. **Extract antigen candidates from BAD sessions**
-   - For each BAD session, extract:
-     - Anchor signal (what triggered BAD classification)
-     - Tool sequence around the failure
-     - Error messages
-     - Pattern description
-   - Write as antigen candidates
-
-7. **Write output to `.factory/friction/`**
-   - Create `.factory/friction/` directory if it doesn't exist
-   - Write these files:
-     - `friction_analysis.json` — per-session breakdown (quality, peak, signals)
-     - `friction_summary.json` — aggregate stats, verdict, daily trend
-     - `friction_raw.jsonl` — all raw signals with timestamps
-     - `antigen_candidates.json` — raw extracted failure patterns
-     - `antigen_clusters.json` — clustered patterns (primary artifact for /remember)
-     - `antigen_review.md` — human-readable clustered review
-
-8. **Report to user**
-   - Sessions analyzed count
-   - BAD / FRICTION / ROUGH / OK counts
-   - BAD rate percentage
-   - Worst session ID and peak friction
-   - Path to `antigen_review.md` for review
-   - Remind: run `/remember` to consolidate into project memory
-
-**Output format for antigen_review.md**
-
-```markdown
-# Friction Antigen Clusters
-
-Generated: [date]
-BAD sessions: [count] | Raw candidates: [count] | Clusters: [count]
-
-## Cluster Summary
-
-| # | Signal | Tool Pattern | Count | Sessions | Score | Median Peak |
-|---|--------|-------------|-------|----------|-------|-------------|
-| 1 | false_success | Bash,Bash | 35 | 23 | 280 | 73 |
-| 2 | user_intervention | (none) | 34 | 24 | 340 | 65 |
-
-## Cluster 1: false_success | Bash,Bash
-
-**Occurrences:** 35 across 23 sessions | **Score:** 280
-
-### User Context (what the user said)
-> [actual user quote from session]
-
-### Errors
-[error messages if any]
-
-### Files involved
-- [file paths]
-```
-
-**File locations**
-- Design doc: `docs/02-features/memory/LONG_TERM_MEMORY.md`
-- Input: JSONL session files from `$ARGUMENTS` path
-- Output: `.factory/friction/` (project-local)
-- JS script: `commands/friction/friction.js` (bundled alongside this command)
-- Python equivalent: `scripts/friction.py` (aurora users, same logic)
-- Manual fallback: built into this command if friction.js unavailable

package/packages/droid/commands/git-commit.md

@@ -1,14 +0,0 @@
----
-name: git-commit
-description: Analyze changes and commit
-usage: /git-commit
-allowed-tools: Bash(git *)
----
-1. Run `git diff --staged` to see changes
-2. Analyze what was changed and why
-3. Create a commit message:
-   - Format: type(scope): description
-   - Types: feat, fix, refactor, docs, test, chore
-   - Under 72 chars
-   - Body explains WHY if non-obvious
-4. Execute the commit

package/packages/droid/commands/review.md

@@ -1,18 +0,0 @@
----
-name: review
-description: Review code [file]
-usage: /review
-argument-hint: [file or leave empty for staged changes]
----
-Review $ARGUMENTS (or staged changes if not specified).
-
-## Check For
-- Security: OWASP Top 10, auth issues, data exposure
-- Performance: N+1 queries, memory leaks, blocking calls
-- Correctness: Edge cases, error handling, type safety
-- Maintainability: Complexity, naming, duplication
-
-## Output Format
-### 🚨 Critical (blocks merge)
-### ⚠️ Warnings (should fix)
-### 💡 Suggestions (nice to have)

package/packages/opencode/command/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