claudecode-omc 5.6.4 → 5.6.6

package/bundled/upstream/ecc/commands/orchestrate.md

@@ -1,135 +0,0 @@
----
-description: Legacy slash-entry shim for dmux-workflows and autonomous-agent-harness. Prefer the skills directly.
----
-
-# Orchestrate Command (Legacy Shim)
-
-Use this only if you still invoke `/orchestrate`. The maintained orchestration guidance lives in `skills/dmux-workflows/SKILL.md` and `skills/autonomous-agent-harness/SKILL.md`.
-
-## Canonical Surface
-
-- Prefer `dmux-workflows` for parallel panes, worktrees, and multi-agent splits.
-- Prefer `autonomous-agent-harness` for longer-running loops, governance, scheduling, and control-plane style execution.
-- Keep this file only as a compatibility entry point.
-
-## Arguments
-
-`$ARGUMENTS`
-
-## Delegation
-
-Apply the orchestration skills instead of maintaining a second workflow spec here.
-- Start with `dmux-workflows` for split/parallel execution.
-- Pull in `autonomous-agent-harness` when the user is really asking for persistent loops, governance, or operator-layer behavior.
-- Keep handoffs structured, but let the skills define the maintained sequencing rules.
-Security Reviewer: [summary]
-
-### FILES CHANGED
-
-[List all files modified]
-
-### TEST RESULTS
-
-[Test pass/fail summary]
-
-### SECURITY STATUS
-
-[Security findings]
-
-### RECOMMENDATION
-
-[SHIP / NEEDS WORK / BLOCKED]
-```
-
-## Parallel Execution
-
-For independent checks, run agents in parallel:
-
-```markdown
-### Parallel Phase
-Run simultaneously:
-- code-reviewer (quality)
-- security-reviewer (security)
-- architect (design)
-
-### Merge Results
-Combine outputs into single report
-```
-
-For external tmux-pane workers with separate git worktrees, use `node scripts/orchestrate-worktrees.js plan.json --execute`. The built-in orchestration pattern stays in-process; the helper is for long-running or cross-harness sessions.
-
-When workers need to see dirty or untracked local files from the main checkout, add `seedPaths` to the plan file. ECC overlays only those selected paths into each worker worktree after `git worktree add`, which keeps the branch isolated while still exposing in-flight local scripts, plans, or docs.
-
-```json
-{
-  "sessionName": "workflow-e2e",
-  "seedPaths": [
-    "scripts/orchestrate-worktrees.js",
-    "scripts/lib/tmux-worktree-orchestrator.js",
-    ".claude/plan/workflow-e2e-test.json"
-  ],
-  "workers": [
-    { "name": "docs", "task": "Update orchestration docs." }
-  ]
-}
-```
-
-To export a control-plane snapshot for a live tmux/worktree session, run:
-
-```bash
-node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json
-```
-
-The snapshot includes session activity, tmux pane metadata, worker states, objectives, seeded overlays, and recent handoff summaries in JSON form.
-
-## Operator Command-Center Handoff
-
-When the workflow spans multiple sessions, worktrees, or tmux panes, append a control-plane block to the final handoff:
-
-```markdown
-CONTROL PLANE
--------------
-Sessions:
-- active session ID or alias
-- branch + worktree path for each active worker
-- tmux pane or detached session name when applicable
-
-Diffs:
-- git status summary
-- git diff --stat for touched files
-- merge/conflict risk notes
-
-Approvals:
-- pending user approvals
-- blocked steps awaiting confirmation
-
-Telemetry:
-- last activity timestamp or idle signal
-- estimated token or cost drift
-- policy events raised by hooks or reviewers
-```
-
-This keeps planner, implementer, reviewer, and loop workers legible from the operator surface.
-
-## Workflow Arguments
-
-$ARGUMENTS:
-- `feature <description>` - Full feature workflow
-- `bugfix <description>` - Bug fix workflow
-- `refactor <description>` - Refactoring workflow
-- `security <description>` - Security review workflow
-- `custom <agents> <description>` - Custom agent sequence
-
-## Custom Workflow Example
-
-```
-/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer"
-```
-
-## Tips
-
-1. **Start with planner** for complex features
-2. **Always include code-reviewer** before merge
-3. **Use security-reviewer** for auth/payment/PII
-4. **Keep handoffs concise** - focus on what next agent needs
-5. **Run verification** between agents if needed

package/bundled/upstream/ecc/commands/prompt-optimize.md

@@ -1,23 +0,0 @@
----
-description: Legacy slash-entry shim for the prompt-optimizer skill. Prefer the skill directly.
----
-
-# Prompt Optimize (Legacy Shim)
-
-Use this only if you still invoke `/prompt-optimize`. The maintained workflow lives in `skills/prompt-optimizer/SKILL.md`.
-
-## Canonical Surface
-
-- Prefer the `prompt-optimizer` skill directly.
-- Keep this file only as a compatibility entry point.
-
-## Arguments
-
-`$ARGUMENTS`
-
-## Delegation
-
-Apply the `prompt-optimizer` skill.
-- Keep it advisory-only: optimize the prompt, do not execute the task.
-- Return the recommended ECC components plus a ready-to-run prompt.
-- If the user actually wants direct execution, say so and tell them to make a normal task request instead of staying inside the shim.

package/bundled/upstream/ecc/commands/rules-distill.md

@@ -1,20 +0,0 @@
----
-description: Legacy slash-entry shim for the rules-distill skill. Prefer the skill directly.
----
-
-# Rules Distill (Legacy Shim)
-
-Use this only if you still invoke `/rules-distill`. The maintained workflow lives in `skills/rules-distill/SKILL.md`.
-
-## Canonical Surface
-
-- Prefer the `rules-distill` skill directly.
-- Keep this file only as a compatibility entry point.
-
-## Arguments
-
-`$ARGUMENTS`
-
-## Delegation
-
-Apply the `rules-distill` skill and follow its inventory, cross-read, and verdict workflow instead of duplicating that logic here.

package/bundled/upstream/ecc/commands/tdd.md

@@ -1,231 +0,0 @@
----
-description: Legacy slash-entry shim for the tdd-workflow skill. Prefer the skill directly.
----
-
-# TDD Command (Legacy Shim)
-
-Use this only if you still invoke `/tdd`. The maintained workflow lives in `skills/tdd-workflow/SKILL.md`.
-
-## Canonical Surface
-
-- Prefer the `tdd-workflow` skill directly.
-- Keep this file only as a compatibility entry point.
-
-## Arguments
-
-`$ARGUMENTS`
-
-## Delegation
-
-Apply the `tdd-workflow` skill.
-- Stay strict on RED -> GREEN -> REFACTOR.
-- Keep tests first, coverage explicit, and checkpoint evidence clear.
-- Use the skill as the maintained TDD body instead of duplicating the playbook here.
-})
-```
-
-## Step 3: Run Tests - Verify FAIL
-
-```bash
-npm test lib/liquidity.test.ts
-
-FAIL lib/liquidity.test.ts
-  ✕ should return high score for liquid market (2 ms)
-    Error: Not implemented
-
-1 test failed, 0 passed
-```
-
-PASS: Tests fail as expected. Ready to implement.
-
-## Step 4: Implement Minimal Code (GREEN)
-
-```typescript
-// lib/liquidity.ts
-export function calculateLiquidityScore(market: MarketData): number {
-  // Handle zero volume edge case
-  if (market.totalVolume === 0) {
-    return 0
-  }
-
-  // Calculate component scores (0-100 scale)
-  const volumeScore = Math.min(market.totalVolume / 1000, 100)
-  const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0)
-  const traderScore = Math.min(market.activeTraders / 10, 100)
-
-  // Recent activity bonus
-  const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
-  const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0)
-
-  // Weighted average
-  const score = (
-    volumeScore * 0.4 +
-    spreadScore * 0.3 +
-    traderScore * 0.2 +
-    recencyScore * 0.1
-  )
-
-  return Math.min(Math.max(score, 0), 100) // Clamp to 0-100
-}
-```
-
-## Step 5: Run Tests - Verify PASS
-
-```bash
-npm test lib/liquidity.test.ts
-
-PASS lib/liquidity.test.ts
-  ✓ should return high score for liquid market (3 ms)
-  ✓ should return low score for illiquid market (2 ms)
-  ✓ should handle edge case: zero volume (1 ms)
-
-3 tests passed
-```
-
-PASS: All tests passing!
-
-## Step 6: Refactor (IMPROVE)
-
-```typescript
-// lib/liquidity.ts - Refactored with constants and better readability
-const WEIGHTS = {
-  VOLUME: 0.4,
-  SPREAD: 0.3,
-  TRADERS: 0.2,
-  RECENCY: 0.1,
-} as const
-
-const SCALE_FACTORS = {
-  VOLUME: 1000,
-  SPREAD: 1000,
-  TRADERS: 10,
-  RECENCY_PENALTY: 10,
-} as const
-
-function clamp(value: number, min: number, max: number): number {
-  return Math.min(Math.max(value, min), max)
-}
-
-export function calculateLiquidityScore(market: MarketData): number {
-  if (market.totalVolume === 0) return 0
-
-  const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100)
-  const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100)
-  const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100)
-
-  const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
-  const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100)
-
-  const weightedScore =
-    volumeScore * WEIGHTS.VOLUME +
-    spreadScore * WEIGHTS.SPREAD +
-    traderScore * WEIGHTS.TRADERS +
-    recencyScore * WEIGHTS.RECENCY
-
-  return clamp(weightedScore, 0, 100)
-}
-```
-
-## Step 7: Verify Tests Still Pass
-
-```bash
-npm test lib/liquidity.test.ts
-
-PASS lib/liquidity.test.ts
-  ✓ should return high score for liquid market (3 ms)
-  ✓ should return low score for illiquid market (2 ms)
-  ✓ should handle edge case: zero volume (1 ms)
-
-3 tests passed
-```
-
-PASS: Refactoring complete, tests still passing!
-
-## Step 8: Check Coverage
-
-```bash
-npm test -- --coverage lib/liquidity.test.ts
-
-File           | % Stmts | % Branch | % Funcs | % Lines
----------------|---------|----------|---------|--------
-liquidity.ts   |   100   |   100    |   100   |   100
-
-Coverage: 100% PASS: (Target: 80%)
-```
-
-PASS: TDD session complete!
-```
-
-## TDD Best Practices
-
-**DO:**
-- PASS: Write the test FIRST, before any implementation
-- PASS: Run tests and verify they FAIL before implementing
-- PASS: Write minimal code to make tests pass
-- PASS: Refactor only after tests are green
-- PASS: Add edge cases and error scenarios
-- PASS: Aim for 80%+ coverage (100% for critical code)
-
-**DON'T:**
-- FAIL: Write implementation before tests
-- FAIL: Skip running tests after each change
-- FAIL: Write too much code at once
-- FAIL: Ignore failing tests
-- FAIL: Test implementation details (test behavior)
-- FAIL: Mock everything (prefer integration tests)
-
-## Test Types to Include
-
-**Unit Tests** (Function-level):
-- Happy path scenarios
-- Edge cases (empty, null, max values)
-- Error conditions
-- Boundary values
-
-**Integration Tests** (Component-level):
-- API endpoints
-- Database operations
-- External service calls
-- React components with hooks
-
-**E2E Tests** (use `/e2e` command):
-- Critical user flows
-- Multi-step processes
-- Full stack integration
-
-## Coverage Requirements
-
-- **80% minimum** for all code
-- **100% required** for:
-  - Financial calculations
-  - Authentication logic
-  - Security-critical code
-  - Core business logic
-
-## Important Notes
-
-**MANDATORY**: Tests must be written BEFORE implementation. The TDD cycle is:
-
-1. **RED** - Write failing test
-2. **GREEN** - Implement to pass
-3. **REFACTOR** - Improve code
-
-Never skip the RED phase. Never write code before tests.
-
-## Integration with Other Commands
-
-- Use `/plan` first to understand what to build
-- Use `/tdd` to implement with tests
-- Use `/build-fix` if build errors occur
-- Use `/code-review` to review implementation
-- Use `/test-coverage` to verify coverage
-
-## Related Agents
-
-This command invokes the `tdd-guide` agent provided by ECC.
-
-The related `tdd-workflow` skill is also bundled with ECC.
-
-For manual installs, the source files live at:
-- `agents/tdd-guide.md`
-- `skills/tdd-workflow/SKILL.md`

package/bundled/upstream/ecc/commands/verify.md

@@ -1,23 +0,0 @@
----
-description: Legacy slash-entry shim for the verification-loop skill. Prefer the skill directly.
----
-
-# Verification Command (Legacy Shim)
-
-Use this only if you still invoke `/verify`. The maintained workflow lives in `skills/verification-loop/SKILL.md`.
-
-## Canonical Surface
-
-- Prefer the `verification-loop` skill directly.
-- Keep this file only as a compatibility entry point.
-
-## Arguments
-
-`$ARGUMENTS`
-
-## Delegation
-
-Apply the `verification-loop` skill.
-- Choose the right verification depth for the user's requested mode.
-- Run build, types, lint, tests, security/log checks, and diff review in the right order for the current repo.
-- Report only the verdicts and blockers instead of maintaining a second verification checklist here.