liteagents 2.9.0 → 2.11.0

package/packages/ampcode/commands/refactor.md

@@ -3,6 +3,7 @@ name: refactor
 description: Refactor [code]
 usage: /refactor <code-section>
 argument-hint: [file-or-function]
+allowed-tools: Read, Edit, Grep, Glob, Bash(npm test *), Bash(npx jest *), Bash(npx vitest *), Bash(pnpm test *), Bash(yarn test *), Bash(pytest *), Bash(python *), Bash(go test *), Bash(cargo test *), Bash(make test *), Bash(git diff *)
 ---
 Refactor $ARGUMENTS.
 
@@ -14,8 +15,39 @@ Refactor $ARGUMENTS.
 - Smaller functions (single responsibility)
 
 ## Constraints
-- NO behavior changes
+- **NO behavior changes**
 - Keep public API intact
 - Existing tests must pass
 
 Explain each change.
+
+## After the refactor — verify it didn't break anything
+
+"Existing tests must pass" is the load-bearing constraint, and the only
+honest way to know is to run them.
+
+1. **Detect the project's test command** (look for `package.json`
+   scripts, `pytest.ini` / `pyproject.toml`, `go.mod`, `Cargo.toml`,
+   `Makefile`). If none is found, **stop and ask** before claiming the
+   refactor is done — silent green isn't acceptable.
+2. **Run the tests.** Scope to the affected area when possible (`-t`,
+   `--testPathPattern`, `pytest path/`, `go test ./pkg`); otherwise run
+   the suite.
+3. **Report** pass / fail counts and any failure's name + `file:line`.
+
+**Stop and ask** when (HITL gates — not all the time, only here):
+- a test **fails** after the refactor. Don't auto-revert (destroys
+  work-in-progress) and don't push forward (the no-behavior-change
+  constraint is broken). Present the failure and the options:
+  **revert**, **patch the refactor**, or **update the test** (with
+  reasoning).
+- the refactor crossed a **public API boundary** that callers depend
+  on — even if tests pass, downstream consumers may break.
+- the change is **bigger than the user asked for** (scope creep —
+  unrelated cleanups, formatting, comment edits). Confirm before
+  applying.
+
+Final report:
+- **refactor done, tests N pass / 0 fail** — ready, OR
+- **refactor done, but K tests fail** — awaiting direction (revert /
+  patch / update test).

package/packages/ampcode/commands/release.md

@@ -0,0 +1,88 @@
+---
+name: release
+description: Deliver a feature end-to-end — verify, docs, merge, tag (publish stays manual)
+usage: /release [branch]
+argument-hint: [branch — new or existing; else current]
+allowed-tools: Read, Grep, Glob, Edit, Write, Bash(git *), Bash(gh *), Bash(npm *), Bash(pnpm *), Bash(yarn *), Bash(pytest *), Bash(python *), Bash(go *), Bash(cargo *), Bash(make *)
+---
+End-to-end feature-delivery **orchestrator**. It does **not** re-implement
+checks — it runs your existing gates (`/ship`, `/security`, `/diff-review`)
+under `/verify-done` discipline, then performs the release actions. Two halves
+split by a hard gate: everything **before** the gate is safe and read-only;
+everything **after** rewrites history and is confirmed step by step.
+
+**A feature branch is required — `main` is only the merge target.** `$ARGUMENTS`
+names the branch to release. Omit it only if you are already on a feature
+branch. If you are on `main` with nothing named, a branch is created for you —
+but you should be releasing a deliberately-named feature branch.
+
+## Phase 0 — Preflight (resolve a feature branch — never `main`)
+- **Resolve the release branch** — whatever gets merged into `main`:
+  - `$ARGUMENTS` given → `git switch` to it (create it if it does not exist).
+  - else not on `main` → release the **current** branch.
+  - else on `main` with no arg → **create** `feat/<slug>` (named for the
+    change) and carry your working changes onto it. **Never release `main`.**
+- **Land the feature on the branch** — if the working tree still has
+  uncommitted feature changes, commit them now; the gates must review a real
+  diff, not a dirty tree.
+- `git fetch origin`; the release diff is `origin/main...HEAD` (now guaranteed
+  to be the resolved branch). If it is empty, **stop** — nothing to release.
+- Print a one-line plan: branch · commit count · files changed.
+
+## Phase 1 — VERIFY (delegate; no hand-waving)
+**First, load the real checklists.** Locate and **read** the sibling command
+definitions so you apply their exact checks, not an approximation — glob your
+installed commands/skills for `ship.md`, `security.md`, `diff-review.md`, and
+`verify-done` (a skill or command). If one cannot be found, run that check from
+its name and **flag that its full checklist was unavailable** — never pretend
+it passed.
+
+Then run each gate and capture **fresh evidence** — the exact command, its exit
+code, and the result. Per `/verify-done`: a check you did **not** actually run
+is a **FAIL**, never an assumed pass.
+- **`/ship`** — pre-deploy gate (tests, lint, build, secrets, authz, rate
+  limit, data scope, migrations, docs-sync).
+- **`/security`** — on the changed files.
+- **`/diff-review`** — on `origin/main...HEAD`.
+
+Emit a coverage table, one row per gate: `ran? ✓/✗` · evidence · verdict. If
+any row is ✗ (could not run), the run is **Blocked 🛑** — do not continue.
+
+## 🚦 Gate
+- **Any Critical** (failing tests/build, a Critical security or diff-review
+  finding) → **stop**, report, ask how to proceed. Touch no history.
+- **Warnings, or anything you cannot confidently decide** → **stop**,
+  summarize, ask.
+- **All clean** → continue to Phase 2.
+
+## Phase 2 — DOCS (only what the feature changed)
+Update as needed, matching each file's existing format; touch nothing
+unrelated. If a doc needs no change, **say so** rather than editing for its
+own sake.
+- **CHANGELOG.md** — new entry.
+- **PRD** — the feature's PRD entry / status.
+- **context / guide** — the project's context or guide doc.
+- **README.md** — only if user-facing usage changed.
+
+## Phase 3 — RELEASE (irreversible — confirm each step)
+1. **Version bump** — pick the semver level from the change (patch / minor /
+   major; ask if ambiguous) and update `package.json`.
+2. **Commit** — `release: vX.Y.Z — <summary>`, including the docs + bump.
+3. **Push** the branch.
+4. **Open PR** — `gh pr create` into `main` (main is PR-protected: 1 approving
+   review).
+5. **Merge** — `gh pr merge --delete-branch`. If the review requirement blocks
+   it, **stop** and ask the user to approve — never force or bypass protection.
+6. **Tag** — after the merge, `git tag vX.Y.Z` on `main` and push it. Keep
+   cut→tag tight — one frozen step.
+
+## Stop here — publish is your call
+Do **not** publish. `publish.yml` is manual `workflow_dispatch` **by design**.
+Print the handoff:
+> Merged, branch deleted, tagged **vX.Y.Z**. To publish, run it yourself:
+> `gh workflow run publish.yml`
+> Then confirm the version is actually live (`npm view <pkg> versions`) and
+> validate the **installed** artifact, not the working tree.
+
+Final report: **Delivered ✅ (vX.Y.Z — publish pending)** or **Blocked 🛑**
+with the specific reason.

package/packages/ampcode/commands/remember.md

@@ -4,7 +4,7 @@ description: Consolidate stashes + friction into project memory
 usage: /remember
 ---
 
-Consolidate session stashes and friction analysis into a single project-local MEMORY.md, then inject into AGENT.md.
+Run friction analysis, then consolidate session stashes + friction antigens into a single project-local MEMORY.md, and inject into AGENT.md. Friction runs automatically (best-effort) — there is no separate `/friction` command.
 
 **Guardrails**
 - Favor straightforward, minimal implementations first and add complexity only when requested or clearly required.
@@ -17,12 +17,43 @@ Reads all raw material (`.amp/stash/*.md` + `.amp/friction/antigen_clusters.json
 
 **Steps**
 
+0. **Run friction first** (best-effort — friction analyzes ALL your usage, not just this repo)
+
+   Friction's signal is *global*: recurring corrections and frustrations across every
+   project are behavioral lessons worth keeping everywhere. So point it at the tool's
+   **global sessions root** (all projects), not a per-project directory.
+
+   - **Locate `friction.js`** — it is bundled next to this command at `friction/friction.js`
+     (the same directory as `remember.md`, whether installed or run from the package). If it
+     exists nowhere, skip to step 1 (stash-only) and tell the user friction.js is missing.
+   - **Resolve the global sessions root** — probe this list top-to-bottom, use the first that
+     exists and contains `.jsonl` files (recursively). **Never prompt the user.**
+     ```
+     # ── Add your own global sessions root at the TOP so it is checked first ──
+     ~/.claude/projects/                 # Claude Code
+     ~/.factory/projects/                # Droid / Factory
+     ~/.config/amp/projects/             # Amp
+     ~/.config/opencode/projects/        # opencode
+     ~/.codex/sessions/                  # Codex CLI  (use $CODEX_HOME/sessions/ if set)
+     ~/.gemini/antigravity-cli/brain/    # Antigravity
+     ```
+     > Note: `friction.js` parses Claude Code's session schema. The Codex/Antigravity roots
+     > will resolve but yield no signals until friction learns their formats — open an issue
+     > to request one: https://github.com/hamr0/liteagents/issues
+   - **Run** `node <friction.js> "<resolved-root>"`. friction writes its output to
+     `.amp/friction/` in the current project.
+   - **On any miss — loud, never silent.** If no root resolves, or friction errors, or it
+     finds no usable sessions, print this and continue with stash-only consolidation:
+     > ⚠️ Friction didn't run — no sessions found. To enable it, open this command file
+     > (`remember.md`) and add your tool's **global** sessions root to the TOP of the probe
+     > list in step 0, then re-run `/remember`. Consolidating stashes only this time.
+
 1. **Gather sources**
    - Read all `.amp/stash/*.md` files in the current project
-   - Check for friction output at `.amp/friction/antigen_clusters.json` (preferred) or `.amp/friction/antigen_review.md` (fallback)
+   - Read friction output written in step 0: `.amp/friction/antigen_clusters.json` (preferred) or `.amp/friction/antigen_review.md` (fallback)
    - Read existing `.amp/memory/MEMORY.md` if it exists — create dir if missing
    - Read processed manifest at `.amp/memory/.processed` — skip already-processed stashes
-   - If no unprocessed stashes AND no friction output, report "nothing to consolidate" and stop
+   - If no unprocessed stashes AND friction produced no new antigens, report "nothing to consolidate" and stop
 
 2. **Extract from unprocessed stashes** (use Task tool with sonnet model for each)
    - For each unprocessed stash, call sonnet to extract:

package/packages/ampcode/commands/security.md

@@ -3,7 +3,7 @@ name: security
 description: Scan security [target]
 usage: /security
 argument-hint: [file, directory, or leave empty for full scan]
-allowed-tools: Read, Grep, Glob, Bash(git log *), Bash(git grep *), Bash(rg *)
+allowed-tools: Read, Edit, Grep, Glob, Bash(git log *), Bash(git grep *), Bash(rg *)
 ---
 Audit $ARGUMENTS for security vulnerabilities. Adapt scope to what the target
 actually is — a library, CLI, web app, and service won't all have every
@@ -57,3 +57,30 @@ Severity-ranked findings (Critical → High → Medium → Low), each with:
 End with: which of the six classes were checked and found **clean**, and any
 marked **N/A** for this target — so the scan's coverage is auditable, not just
 its hits.
+
+## After the scan — verify, then fix
+
+Findings are claims, not facts. Validate before acting; validate again after.
+
+**Verify each claim.** Re-read the cited `file:line` in context. Confirm the
+risk actually holds here — not in the abstract. Mark each **confirmed**, **false
+positive** (with reason), or **uncertain**.
+
+**Fix what's confirmed and unambiguous** — minimal shape, one obvious way, no
+change to a public API / response / caller contract. Apply directly. After
+each edit, re-read the changed region and confirm it closes the gap without
+breaking nearby logic. A fix isn't done until you've grounded it the same way
+you grounded the claim.
+
+**Stop and ask** when any of these hold (HITL gates — not all the time, only
+here):
+- the finding is **uncertain** after grounding (you'd need info you don't have),
+- the fix has **multiple reasonable shapes** (e.g. reject-vs-sanitize,
+  index-vs-paginate) — present options with tradeoffs, not a chosen path,
+- it **affects downstream** (function signatures, response shape, DB schema,
+  any caller contract), or
+- it touches **auth / crypto / session / token** primitives — even an "obvious"
+  fix here warrants confirmation.
+
+Final report: **confirmed-and-fixed** · **confirmed-but-asking** (why + options)
+· **false-positive** (why) · **uncertain** (what's needed to decide).

package/packages/ampcode/commands/stash.md

@@ -17,6 +17,13 @@ Save session context for compaction recovery or handoffs.
 3. Stores important findings and insights
 4. Creates stash file in `.amp/stash/`
 5. Enables context restoration after compaction
+6. **Consolidation nudge** — after saving, count the unprocessed backlog:
+   `unprocessed = (files in .amp/stash/*.md) − (entries in .amp/memory/.processed)`
+   (a missing `.processed` manifest means 0 processed). If `unprocessed >= 5`, end with one line:
+   > 📝 N stashes since last consolidation — run `/remember` to fold them into memory.
+
+   No counter is stored — the count is derived each time, and running `/remember` updates
+   `.processed`, so the backlog drops on its own. Just emit the nudge; never run `/remember` automatically.
 
 **When to use**
 - Before long-running tasks that may trigger compaction

package/packages/{droid/commands/test-driven-development.md → ampcode/commands/tdd-flow.md}

@@ -1,9 +1,9 @@
 ---
-name: test-driven-development
+name: tdd-flow
 description: Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
 ---
 
-# Test-Driven Development (TDD)
+# TDD Flow
 
 ## Auto-Trigger
 

package/packages/ampcode/commands/test-generate.md

@@ -1,18 +1,67 @@
 ---
 name: test-generate
-description: Generate tests [file]
-usage: /test-generate <code-section>
-argument-hint: [file-to-test]
+description: Generate and run tests [file]
+usage: /test-generate <file>
+argument-hint: [file or symbol to test]
+allowed-tools: Read, Edit, Write, Grep, Glob, Bash(npm test *), Bash(npx jest *), Bash(npx vitest *), Bash(pnpm test *), Bash(yarn test *), Bash(pytest *), Bash(python *), Bash(go test *), Bash(cargo test *), Bash(make test *)
 ---
-Generate tests for $ARGUMENTS.
-
-## Include
-- Happy path (expected usage)
-- Edge cases (empty, null, boundaries)
-- Error scenarios (invalid input, failures)
-- Integration points (mocks for external deps)
-
-## Requirements
-- Match existing test patterns in this project
-- Use the testing framework already in use
-- Clear test names: "should [expected] when [condition]"
+Generate tests for $ARGUMENTS, then run them. This is a generate → run →
+verify loop, not just file generation.
+
+## 1. Discover
+- Detect the test framework already in use (look for `jest.config*`,
+  `vitest.config*`, `pytest.ini` / `pyproject.toml [tool.pytest]`, Go's
+  `_test.go` convention, `Cargo.toml [dev-dependencies]`, etc.). **Never
+  add a new framework or runner.**
+- Skim 1–2 existing test files near the target to mirror style, fixtures,
+  setup/teardown, assertion style, and naming convention.
+
+## 2. Generate
+Cover:
+- **Happy path** (expected usage)
+- **Edges** (empty / null / boundary / malformed)
+- **Errors** (invalid input, IO / network / DB failures)
+
+Match existing patterns:
+- Same framework, same fixture style, same naming convention.
+- Reuse existing setup/teardown helpers; do **not** add new mock libraries
+  or new test-runner config.
+- Do **not** add test-only public methods or exports to production code to
+  make a test possible — if the test wants a hook the prod code doesn't
+  expose, stop and ask (`test-traps` territory).
+
+## 3. Run
+Execute the project's real test command, scoped to just the new tests
+(`-t <name>`, `--testPathPattern`, `pytest path/to/test.py`, `go test
+./pkg`, etc.). Report:
+- Pass / fail counts.
+- Any failure with the assertion message and `file:line`.
+
+## 4. Verify the tests BITE
+A test that passes is not the same as a test that **exercises** the code.
+For each new test, confirm:
+- It would fail if the function under test returned the wrong value.
+  Mentally swap a broken impl — does the assertion actually catch it?
+- It isn't `expect(true).toBe(true)`, `expect(fn).toBeDefined()`, or a
+  mock asserting itself.
+- It isn't passing only because the setup masked the real call.
+
+Mark each new test **biting** or **superficial** (with reason).
+Superficial tests count as a failure to ship — either fix or delete.
+
+## 5. Report
+- Files added / modified.
+- Pass / fail.
+- Biting vs superficial breakdown.
+- What was deliberately **not** tested, and why (third-party shims,
+  trivial getters/setters, generated code). Documented gaps beat fake
+  coverage.
+
+**Stop and ask** when:
+- A meaningful test would require a non-obvious design change to
+  production code (don't pollute prod to make tests pass — present the
+  options instead).
+- The existing test setup has multiple reasonable patterns and it's
+  unclear which to mirror.
+- An existing dependency would need to be mocked in a way the project
+  doesn't currently do (introducing a new mock style is a design choice).

package/packages/{opencode/command/testing-anti-patterns.md → ampcode/commands/test-traps.md}

@@ -1,11 +1,11 @@
 ---
-name: testing-anti-patterns
+name: test-traps
 description: Use when writing or changing tests, adding mocks, or tempted to add test-only methods to production code - prevents testing mock behavior, production pollution with test-only methods, and mocking without understanding dependencies
-usage: /testing-anti-patterns <testing-scenario>
+usage: /test-traps <testing-scenario>
 auto_trigger: true
 ---
 
-# Testing Anti-Patterns
+# Test Traps
 
 ## Overview
 
@@ -253,6 +253,79 @@ TDD cycle:
 4. THEN claim complete
 ```
 
+## Anti-Pattern 6: Timeout-Based Waiting
+
+**The violation:**
+```typescript
+// Wait an arbitrary amount of time, then check
+await new Promise(r => setTimeout(r, 50));
+const result = getResult();
+expect(result).toBeDefined();
+```
+
+```python
+time.sleep(0.5)
+assert get_result() is not None
+```
+
+**Why this is wrong:**
+- Passes on fast machines, fails in CI under load (or vice versa).
+- Either too short (flaky) or too long (slow suite) — every value is wrong somewhere.
+- Hides the actual condition the test cares about.
+- A real bug in the async machinery looks identical to a "too-short sleep."
+
+**The fix — poll for the actual condition:**
+```typescript
+await waitFor(() => getResult() !== undefined);
+const result = getResult();
+expect(result).toBeDefined();
+```
+
+| 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)` |
+
+Minimal generic poller:
+```typescript
+async function waitFor<T>(
+  condition: () => T | undefined | null | false,
+  description = 'condition',
+  timeoutMs = 5000
+): Promise<T> {
+  const start = Date.now();
+  while (true) {
+    const result = condition();
+    if (result) return result;
+    if (Date.now() - start > timeoutMs) {
+      throw new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`);
+    }
+    await new Promise(r => setTimeout(r, 10));
+  }
+}
+```
+
+See `example.ts` for domain-specific helpers (`waitForEvent`, `waitForEventCount`, `waitForEventMatch`) drawn from a real debugging session.
+
+**Polling pitfalls:**
+- **Polling too fast** (`setTimeout(check, 1)`) wastes CPU. **Fix:** poll every ~10ms.
+- **No timeout** means a never-met condition hangs the suite forever. **Fix:** always include a timeout with a descriptive error.
+- **Stale data** — if you read state once before the loop, you'll never see updates. **Fix:** call the getter *inside* the loop.
+
+**When an arbitrary timeout IS correct:**
+```typescript
+// Tool ticks every 100ms; observe 2 ticks of partial output.
+await waitForEvent(manager, 'TOOL_STARTED'); // condition first
+await new Promise(r => setTimeout(r, 200));  // then a documented, calculated wait
+// 200ms = 2 ticks at the documented 100ms cadence
+```
+Requirements: (1) wait for the triggering condition first, (2) the delay is based on a *known* interval (not a guess), (3) a comment explains why a sleep is correct here.
+
+**Real-world impact** (debugging session, 2025-10-03): 15 flaky tests across 3 files, pass rate 60% → 100%, suite 40% faster, race conditions gone.
+
 ## When Mocks Become Too Complex
 
 **Warning signs:**
@@ -284,6 +357,7 @@ TDD cycle:
 | Mock without understanding | Understand dependencies first, mock minimally |
 | Incomplete mocks | Mirror real API completely |
 | Tests as afterthought | TDD - tests first |
+| Timeout-based waiting | Poll for the actual condition with `waitFor()` |
 | Over-complex mocks | Consider integration tests |
 
 ## Red Flags

package/packages/{droid/commands/root-cause-tracing.md → ampcode/commands/trace-back.md}

@@ -1,11 +1,11 @@
 ---
-name: root-cause-tracing
+name: trace-back
 description: Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior
-usage: /root-cause-tracing <issue-description>
+usage: /trace-back <issue-description>
 auto_trigger: false
 ---
 
-# Root Cause Tracing
+# Trace Back
 
 ## Overview
 

package/packages/ampcode/commands/{verification-before-completion.md → verify-done.md}

@@ -1,11 +1,11 @@
 ---
-name: verification-before-completion
+name: verify-done
 description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
-usage: /verification-before-completion <work-to-verify>
+usage: /verify-done <work-to-verify>
 auto_trigger: true
 ---
 
-# Verification Before Completion
+# Verify Done
 
 ## Auto-Trigger
 

package/packages/claude/CLAUDE.md

@@ -22,38 +22,33 @@ These subagents are available when using Claude Code CLI. Droid can reference th
 | system-architect | Architect | Use for system design, architecture documents, technology selection, API design, and infrastructure planning |
 | ui-designer | UX Expert | Use for UI/UX design, wireframes, prototypes, front-end specifications, and user experience optimization |
 
-### Skills (10 total)
+### Skills (9 total)
 
 | ID | Description | Usage | Auto |
 |---|---|---|---|
 | brainstorming | Refines rough ideas into fully-formed designs through collaborative questioning | /brainstorming <session-type> <topic> | false |
-| code-review | Reviews implementation against plan or requirements before proceeding | /code-review <review-scope> <focus-areas> | false |
-| condition-based-waiting | Replaces arbitrary timeouts with condition polling to wait for actual state changes | /condition-based-waiting <condition-type> <timeout-specs> | false |
 | docs-builder | Create comprehensive project documentation with structured /docs hierarchy | /docs-builder | false |
-| root-cause-tracing | Systematically traces bugs backward through call stack to identify source | /root-cause-tracing <issue-description> | false |
+| trace-back | Systematically traces bugs backward through call stack to identify source | /trace-back <issue-description> | false |
 | live-canvas | Conduct design interviews, generate UI variations, collect live click-to-annotate feedback via a browser overlay that streams into the session | /live-canvas | false |
 | skill-creator | Guide for creating effective skills and extending Claude capabilities | /skill-creator <skill-type> <skill-description> | false |
-| systematic-debugging | Four-phase debugging framework - investigate root cause before any fixes | /systematic-debugging <bug-or-error-description> | false |
-| test-driven-development | Write test first, watch it fail, write minimal code to pass | /test-driven-development <feature-or-behavior-to-test> | true |
-| testing-anti-patterns | Prevents testing mock behavior and production pollution with test-only methods | /testing-anti-patterns <testing-scenario> | true |
-| verification-before-completion | Requires running verification commands before making any success claims | /verification-before-completion <work-to-verify> | true |
+| debug-method | Four-phase debugging framework - investigate root cause before any fixes | /debug-method <bug-or-error-description> | false |
+| tdd-flow | Write test first, watch it fail, write minimal code to pass | /tdd-flow <feature-or-behavior-to-test> | true |
+| test-traps | Prevents testing mock behavior and production pollution with test-only methods | /test-traps <testing-scenario> | true |
+| verify-done | Requires running verification commands before making any success claims | /verify-done <work-to-verify> | true |
 
-### Commands (12 total)
+### Commands (9 total)
 
 | ID | Description | Usage |
 |---|---|---|
-| debug | Debug an issue systematically using structured investigation techniques | /debug <issue-description> |
-| explain | Explain code for someone new to the codebase | /explain <code-section> |
-| friction | Analyze session logs for failure patterns and behavioral signals | /friction <sessions-path> |
-| git-commit | Analyze changes and create intelligent git commits | /git-commit |
 | optimize | Analyze and optimize performance issues | /optimize <target-area> |
 | refactor | Refactor code while maintaining behavior and tests | /refactor <code-section> |
 | remember | Consolidate stashes + friction into project memory | /remember |
-| review | Comprehensive code review including quality, tests, and architecture | /review |
+| diff-review | Comprehensive code review including quality, tests, and architecture | /diff-review |
 | security | Security vulnerability scan and analysis | /security |
 | ship | Pre-deployment verification checklist | /ship |
+| release | Deliver a feature end-to-end: verify, docs, merge, tag (publish stays manual) | /release [branch] |
 | stash | Save session context for compaction recovery or handoffs | /stash ["optional-name"] |
-| test-generate | Generate comprehensive test suites for existing code | /test-generate <code-section> |
+| test-generate | Generate tests, run them, verify each one actually exercises the code | /test-generate <file> |
 
 All resources are auto-discovered from frontmatter in their respective directories:
 - **Agents**: `./agents/*.md`

package/packages/claude/agents/code-developer.md

@@ -41,7 +41,7 @@ digraph CodeDeveloper {
   context_discovery [label="Context Discovery\n(search related code,\ndeps, usages)", fillcolor=lightyellow];
 
   // Debug path
-  use_debug [label="Use /systematic-debugging\nor /root-cause-tracing"];
+  use_debug [label="Use /debug-method\nor /trace-back"];
 
   // Refactor path
   use_refactor [label="Use /refactor"];
@@ -54,12 +54,12 @@ digraph CodeDeveloper {
 
   // Conditional testing
   tdd_needed [label="TDD specified\nor tests needed?", shape=diamond];
-  use_tdd [label="Use /test-driven-development\nor /test-generate"];
+  use_tdd [label="Use /tdd-flow\nor /test-generate"];
 
   // Validation
   run_validations [label="Run validations\n(lint, build, tests)"];
   validations_pass [label="Pass?", shape=diamond];
-  fix_issues [label="Fix issues\n(use /debug if needed)"];
+  fix_issues [label="Fix issues\n(use /debug-method if needed)"];
   failure_count [label="3+ failures?", shape=diamond];
 
   // Security check
@@ -75,8 +75,8 @@ digraph CodeDeveloper {
   regression_fixable [label="Fixable?", shape=diamond];
 
   // Review and complete
-  code_review [label="Run /code-review"];
-  verification [label="Run /verification-before-completion", fillcolor=orange];
+  code_review [label="Run /diff-review"];
+  verification [label="Run /verify-done", fillcolor=orange];
 
   // Story-specific
   update_story [label="Update story\n(checkbox, changelog)"];
@@ -184,15 +184,14 @@ All require `*` prefix. Invocation commands in table above. Additional:
 
 | Situation | Delegate To |
 |-----------|-------------|
-| Bug encountered | `/systematic-debugging` first, then `/debug` |
-| Error deep in stack | `/root-cause-tracing` |
+| Bug encountered | `/debug-method` (use `/trace-back` when the error is deep in the stack) |
+| Error deep in stack | `/trace-back` |
 | Refactoring code | `/refactor` |
-| Need tests (when required) | `/test-generate` or `/test-driven-development` |
-| Writing any test | `/testing-anti-patterns` (avoid mocks, production pollution) |
-| Before completion | `/verification-before-completion` |
+| Need tests (when required) | `/test-generate` or `/tdd-flow` |
+| Writing any test | `/test-traps` (avoid mocks, production pollution) |
+| Before completion | `/verify-done` |
 | After code changes | `/security` |
-| Task complete (vs plan) | `/code-review` (checks against requirements/plan) |
-| General code review | `/review` (comprehensive quality check) |
+| Task complete / general review | `/diff-review` (diffs branch or staged changes, verifies, fixes confirmed issues, asks on ambiguous ones) |
 | Performance issues | `/optimize` |
 
 You are an autonomous implementation specialist. Execute with precision, delegate appropriately, and communicate clearly when you need guidance or encounter blockers.

package/packages/claude/agents/quality-assurance.md

@@ -65,7 +65,7 @@ Before any analysis, read (if exists):
 
 ## Slash Commands Available
 
-Use these during analysis: `/code-review`, `/security`, `/debug`, `/review`, `/verification-before-completion`
+Use these during analysis: `/diff-review`, `/security`, `/verify-done`
 
 ## Analysis Areas