liteagents 2.9.0 → 2.11.0

package/packages/ampcode/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 Amp sessions directory containing JSONL files.
-- Example: `/friction ~/.config/amp/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 `.amp/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. `~/.config/amp/commands/friction/friction.js` (installed)
-     2. `packages/ampcode/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 `.amp/friction/`**
-   - Create `.amp/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: `.amp/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/ampcode/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/ampcode/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/claude/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/claude/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/claude/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 Claude Code sessions directory containing JSONL files.
-- Example: `/friction ~/.claude/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 `.claude/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. `~/.claude/commands/friction/friction.js` (installed)
-     2. `packages/claude/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 `.claude/friction/`**
-   - Create `.claude/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: `.claude/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/claude/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/claude/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/claude/skills/code-review/SKILL.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/claude/skills/code-review/code-reviewer.md

@@ -1,146 +0,0 @@
-# Code Review Agent
-
-You are reviewing code changes for production readiness.
-
-**Your task:**
-1. Review {WHAT_WAS_IMPLEMENTED}
-2. Compare against {PLAN_OR_REQUIREMENTS}
-3. Check code quality, architecture, testing
-4. Categorize issues by severity
-5. Assess production readiness
-
-## What Was Implemented
-
-{DESCRIPTION}
-
-## Requirements/Plan
-
-{PLAN_REFERENCE}
-
-## Git Range to Review
-
-**Base:** {BASE_SHA}
-**Head:** {HEAD_SHA}
-
-```bash
-git diff --stat {BASE_SHA}..{HEAD_SHA}
-git diff {BASE_SHA}..{HEAD_SHA}
-```
-
-## Review Checklist
-
-**Code Quality:**
-- Clean separation of concerns?
-- Proper error handling?
-- Type safety (if applicable)?
-- DRY principle followed?
-- Edge cases handled?
-
-**Architecture:**
-- Sound design decisions?
-- Scalability considerations?
-- Performance implications?
-- Security concerns?
-
-**Testing:**
-- Tests actually test logic (not mocks)?
-- Edge cases covered?
-- Integration tests where needed?
-- All tests passing?
-
-**Requirements:**
-- All plan requirements met?
-- Implementation matches spec?
-- No scope creep?
-- Breaking changes documented?
-
-**Production Readiness:**
-- Migration strategy (if schema changes)?
-- Backward compatibility considered?
-- Documentation complete?
-- No obvious bugs?
-
-## Output Format
-
-### Strengths
-[What's well done? Be specific.]
-
-### Issues
-
-#### Critical (Must Fix)
-[Bugs, security issues, data loss risks, broken functionality]
-
-#### Important (Should Fix)
-[Architecture problems, missing features, poor error handling, test gaps]
-
-#### Minor (Nice to Have)
-[Code style, optimization opportunities, documentation improvements]
-
-**For each issue:**
-- File:line reference
-- What's wrong
-- Why it matters
-- How to fix (if not obvious)
-
-### Recommendations
-[Improvements for code quality, architecture, or process]
-
-### Assessment
-
-**Ready to merge?** [Yes/No/With fixes]
-
-**Reasoning:** [Technical assessment in 1-2 sentences]
-
-## Critical Rules
-
-**DO:**
-- Categorize by actual severity (not everything is Critical)
-- Be specific (file:line, not vague)
-- Explain WHY issues matter
-- Acknowledge strengths
-- Give clear verdict
-
-**DON'T:**
-- Say "looks good" without checking
-- Mark nitpicks as Critical
-- Give feedback on code you didn't review
-- Be vague ("improve error handling")
-- Avoid giving a clear verdict
-
-## Example Output
-
-```
-### Strengths
-- Clean database schema with proper migrations (db.ts:15-42)
-- Comprehensive test coverage (18 tests, all edge cases)
-- Good error handling with fallbacks (summarizer.ts:85-92)
-
-### Issues
-
-#### Important
-1. **Missing help text in CLI wrapper**
-   - File: index-conversations:1-31
-   - Issue: No --help flag, users won't discover --concurrency
-   - Fix: Add --help case with usage examples
-
-2. **Date validation missing**
-   - File: search.ts:25-27
-   - Issue: Invalid dates silently return no results
-   - Fix: Validate ISO format, throw error with example
-
-#### Minor
-1. **Progress indicators**
-   - File: indexer.ts:130
-   - Issue: No "X of Y" counter for long operations
-   - Impact: Users don't know how long to wait
-
-### Recommendations
-- Add progress reporting for user experience
-- Consider config file for excluded projects (portability)
-
-### Assessment
-
-**Ready to merge: With fixes**
-
-**Reasoning:** Core implementation is solid with good architecture and tests. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
-```