claudecode-omc 5.6.5 → 5.6.6

package/bundled/upstream/ecc/commands/fastapi-review.md

@@ -0,0 +1,39 @@
+---
+description: Review a FastAPI application for architecture, async correctness, dependency injection, Pydantic schemas, security, performance, and testability.
+---
+
+# FastAPI Review
+
+Invoke the `fastapi-reviewer` agent for a focused FastAPI review.
+
+## Usage
+
+```text
+/fastapi-review [file-or-directory]
+```
+
+## Review Areas
+
+- App factory, router boundaries, middleware, and exception handlers.
+- Pydantic request and response schema separation.
+- Dependency injection for database sessions, auth, pagination, and settings.
+- Async database and external HTTP patterns.
+- CORS, auth, rate limits, logging, and secret handling.
+- OpenAPI metadata and documented response models.
+- Test client setup and dependency overrides.
+
+## Expected Output
+
+```text
+[SEVERITY] Short issue title
+File: path/to/file.py:42
+Issue: What is wrong and why it matters.
+Fix: Concrete change to make.
+```
+
+## Related
+
+- Agent: `fastapi-reviewer`
+- Skill: `fastapi-patterns`
+- Command: `/python-review`
+- Skill: `security-scan`

package/bundled/upstream/ecc/commands/flutter-build.md

@@ -156,7 +156,7 @@ The agent will stop and report if:
 
 - `/flutter-test` — Run tests after build succeeds
 - `/flutter-review` — Review code quality
-- `/verify` — Full verification loop
+- `verification-loop` skill — Full verification loop
 
 ## Related
 

package/bundled/upstream/ecc/commands/flutter-test.md

@@ -134,7 +134,7 @@ Test Status: PASS ✓
 
 - `/flutter-build` — Fix build errors before running tests
 - `/flutter-review` — Review code after tests pass
-- `/tdd` — Test-driven development workflow
+- `tdd-workflow` skill — Test-driven development workflow
 
 ## Related
 

package/bundled/upstream/ecc/commands/gan-build.md

@@ -1,3 +1,7 @@
+---
+description: Run a generator/evaluator build loop for implementation tasks with bounded iterations and scoring.
+---
+
 Parse the following from $ARGUMENTS:
 1. `brief` — the user's one-line description of what to build
 2. `--max-iterations N` — (optional, default 15) maximum generator-evaluator cycles

package/bundled/upstream/ecc/commands/gan-design.md

@@ -1,3 +1,7 @@
+---
+description: Run a generator/evaluator design loop for frontend or visual work with bounded iterations and scoring.
+---
+
 Parse the following from $ARGUMENTS:
 1. `brief` — the user's description of the design to create
 2. `--max-iterations N` — (optional, default 10) maximum design-evaluate cycles

package/bundled/upstream/ecc/commands/go-build.md

@@ -175,7 +175,7 @@ The agent will stop and report if:
 
 - `/go-test` - Run tests after build succeeds
 - `/go-review` - Review code quality
-- `/verify` - Full verification loop
+- `verification-loop` skill - Full verification loop
 
 ## Related
 

package/bundled/upstream/ecc/commands/go-test.md

@@ -260,7 +260,7 @@ go test -race -cover ./...
 
 - `/go-build` - Fix build errors
 - `/go-review` - Review code after implementation
-- `/verify` - Run full verification loop
+- `verification-loop` skill - Run full verification loop
 
 ## Related
 

package/bundled/upstream/ecc/commands/harness-audit.md

@@ -1,3 +1,7 @@
+---
+description: Run a deterministic repository harness audit and return a prioritized scorecard.
+---
+
 # Harness Audit Command
 
 Run a deterministic repository harness audit and return a prioritized scorecard.

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

@@ -55,7 +55,7 @@ Dependencies:
 
 Recommended Next Steps:
 - /plan to create implementation plan
-- /tdd to implement with tests first
+- `tdd-workflow` skill to implement with tests first
 ```
 
 ### `/jira comment <TICKET-KEY>`
@@ -95,7 +95,7 @@ If credentials are missing, stop and direct the user to set them up.
 
 After analyzing a ticket:
 - Use `/plan` to create an implementation plan from the requirements
-- Use `/tdd` to implement with test-driven development
+- Use the `tdd-workflow` skill to implement with test-driven development
 - Use `/code-review` after implementation
 - Use `/jira comment` to post progress back to the ticket
 - Use `/jira transition` to move the ticket when work is complete

package/bundled/upstream/ecc/commands/kotlin-build.md

@@ -166,7 +166,7 @@ The agent will stop and report if:
 
 - `/kotlin-test` - Run tests after build succeeds
 - `/kotlin-review` - Review code quality
-- `/verify` - Full verification loop
+- `verification-loop` skill - Full verification loop
 
 ## Related
 

package/bundled/upstream/ecc/commands/kotlin-test.md

@@ -304,7 +304,7 @@ open build/reports/kover/html/index.html
 
 - `/kotlin-build` - Fix build errors
 - `/kotlin-review` - Review code after implementation
-- `/verify` - Run full verification loop
+- `verification-loop` skill - Run full verification loop
 
 ## Related
 

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

@@ -1,3 +1,7 @@
+---
+description: Extract reusable patterns from the current session and save them as candidate skills or guidance.
+---
+
 # /learn - Extract Reusable Patterns
 
 Analyze the current session and extract any patterns worth saving as skills.

package/bundled/upstream/ecc/commands/loop-start.md

@@ -1,3 +1,7 @@
+---
+description: Start a managed autonomous loop pattern with safety defaults and explicit stop conditions.
+---
+
 # Loop Start Command
 
 Start a managed autonomous loop pattern with safety defaults.

package/bundled/upstream/ecc/commands/loop-status.md

@@ -1,7 +1,23 @@
+---
+description: Inspect active loop state, progress, failure signals, and recommended intervention.
+---
+
 # Loop Status Command
 
 Inspect active loop state, progress, and failure signals.
 
+This slash command can only run after the current session dequeues it. If you
+need to inspect a wedged or sibling session, run the packaged CLI from another
+terminal:
+
+```bash
+npx --package ecc-universal ecc loop-status --json
+```
+
+The CLI scans local Claude transcript JSONL files under
+`~/.claude/projects/**` and reports stale `ScheduleWakeup` calls or `Bash`
+tool calls that have no matching `tool_result`.
+
 ## Usage
 
 `/loop-status [--watch]`
@@ -14,9 +30,46 @@ Inspect active loop state, progress, and failure signals.
 - estimated time/cost drift
 - recommended intervention (continue/pause/stop)
 
+## Cross-Session CLI
+
+- `ecc loop-status --json` emits machine-readable status for recent local
+  Claude transcripts.
+- `ecc loop-status --home <dir>` scans a different home directory when
+  inspecting another local profile or mounted workspace.
+- `ecc loop-status --transcript <session.jsonl>` inspects one transcript
+  directly.
+- `ecc loop-status --bash-timeout-seconds 1800` adjusts the stale Bash
+  threshold.
+- `ecc loop-status --exit-code` exits `2` when stale loop or tool signals are
+  found, or `1` when transcripts cannot be scanned.
+- `--exit-code` with `--watch` requires `--watch-count` so watchdog scripts do
+  not wait forever for a process exit.
+- `ecc loop-status --watch` refreshes status until interrupted.
+- `ecc loop-status --watch --watch-count 3 --exit-code` refreshes a bounded
+  number of times, then exits with the highest status seen.
+- `ecc loop-status --watch --watch-count 3` emits a bounded watch stream for
+  scripts and handoffs.
+- `ecc loop-status --watch --write-dir ~/.claude/loops` maintains
+  `index.json` and per-session JSON snapshots for sibling terminals or
+  watchdog scripts.
+
 ## Watch Mode
 
-When `--watch` is present, refresh status periodically and surface state changes.
+When `--watch` is present, refresh status periodically. With `--json`, each
+refresh is emitted as one JSON object per line so another terminal or script can
+consume the stream.
+
+## Snapshot Files
+
+Use `--write-dir <dir>` when a separate process needs to inspect loop state
+without waiting for the current Claude session to dequeue `/loop-status`. The
+CLI writes:
+
+- `index.json` with one row per inspected session.
+- `<session-id>.json` with the full status payload for that session.
+
+These files are snapshots of local transcript analysis. They do not control or
+timeout Claude Code runtime tool calls.
 
 ## Arguments
 

package/bundled/upstream/ecc/commands/model-route.md

@@ -1,3 +1,7 @@
+---
+description: Recommend the best model tier for the current task based on complexity, risk, and budget.
+---
+
 # Model Route Command
 
 Recommend the best model tier for the current task by complexity and budget.

package/bundled/upstream/ecc/commands/multi-backend.md

@@ -1,3 +1,7 @@
+---
+description: Run a backend-focused multi-model workflow for APIs, algorithms, data, and business logic.
+---
+
 # Backend - Backend-Focused Development
 
 Backend-focused workflow (Research → Ideation → Plan → Execute → Optimize → Review), Codex-led.

package/bundled/upstream/ecc/commands/multi-execute.md

@@ -1,3 +1,7 @@
+---
+description: Execute a multi-model implementation plan while preserving Claude as the only filesystem writer.
+---
+
 # Execute - Multi-Model Collaborative Execution
 
 Multi-model collaborative execution - Get prototype from plan → Claude refactors and implements → Multi-model audit and delivery.

package/bundled/upstream/ecc/commands/multi-frontend.md

@@ -1,3 +1,7 @@
+---
+description: Run a frontend-focused multi-model workflow for components, layouts, animation, and UI polish.
+---
+
 # Frontend - Frontend-Focused Development
 
 Frontend-focused workflow (Research → Ideation → Plan → Execute → Optimize → Review), Gemini-led.

package/bundled/upstream/ecc/commands/multi-plan.md

@@ -1,3 +1,7 @@
+---
+description: Create a multi-model implementation plan without modifying production code.
+---
+
 # Plan - Multi-Model Collaborative Planning
 
 Multi-model collaborative planning - Context retrieval + Dual-model analysis → Generate step-by-step implementation plan.

package/bundled/upstream/ecc/commands/multi-workflow.md

@@ -1,3 +1,7 @@
+---
+description: Run a full multi-model development workflow with research, planning, execution, optimization, and review.
+---
+
 # Workflow - Multi-Model Collaborative Development
 
 Multi-model collaborative development workflow (Research → Ideation → Plan → Execute → Optimize → Review), with intelligent routing: Frontend → Gemini, Backend → Codex.

package/bundled/upstream/ecc/commands/plan-prd.md

@@ -0,0 +1,160 @@
+---
+description: "Generate a lean, problem-first PRD and hand off to /plan for implementation planning."
+argument-hint: "[product/feature idea] (blank = start with questions)"
+---
+
+# PRD Command
+
+Produces a **Product Requirements Document** — the requirements-phase artifact of the SDLC. Captures *what* must be true for success and *why*, and stops before *how*. Implementation decomposition is delegated to `/plan`.
+
+**Input**: `$ARGUMENTS`
+
+## Scope of this command
+
+| This command does | This command does NOT do |
+|---|---|
+| Frame the problem and users | Design the architecture |
+| Capture success criteria and scope | Pick files or write patterns |
+| List open questions and risks | Enumerate implementation tasks |
+| Write `.claude/prds/{name}.prd.md` | Produce an implementation plan — that's `/plan` |
+
+If you find yourself writing implementation detail, stop and cut it. It belongs in `/plan`.
+
+**Anti-fluff rule**: When information is missing, write `TBD — needs validation via {method}`. Never invent plausible-sounding requirements.
+
+## Workflow
+
+Four phases. Each phase is a single gate — ask the questions, wait for the user, then move on. No nested loops, no parallel research ceremony.
+
+### Phase 1 — FRAME
+
+If `$ARGUMENTS` is empty, ask:
+
+> What do you want to build? One or two sentences.
+
+If provided, restate in one sentence and ask:
+
+> I understand: *{restated}*. Correct, or should I adjust?
+
+Then ask the framing questions in a single set:
+
+> 1. **Who** has this problem? (specific role or segment)
+> 2. **What** is the observable pain? (describe behavior, not assumed needs)
+> 3. **Why** can't they solve it with what exists today?
+> 4. **Why now?** — what changed that makes this worth doing?
+
+Wait for the user. Do not proceed without answers (or explicit "skip").
+
+### Phase 2 — GROUND
+
+Ask for evidence. This is the shortest phase and the most load-bearing:
+
+> What evidence do you have that this problem is real and worth solving? (user quotes, support tickets, metrics, observed behavior, failed workarounds — anything concrete)
+
+If the user has none, record the PRD's Evidence section as `Assumption — needs validation via {user research | analytics | prototype}`. This keeps the PRD honest.
+
+### Phase 3 — DECIDE
+
+Scope and hypothesis in a single set:
+
+> 1. **Hypothesis** — Complete: *We believe **{capability}** will **{solve problem}** for **{users}**. We'll know we're right when **{measurable outcome}**.*
+> 2. **MVP** — The minimum needed to test the hypothesis?
+> 3. **Out of scope** — What are you explicitly **not** building (even if users ask)?
+> 4. **Open questions** — Uncertainties that could change the approach?
+
+Wait for responses.
+
+### Phase 4 — GENERATE & HAND OFF
+
+Create the directory if needed, write the PRD, and report.
+
+```bash
+mkdir -p .claude/prds
+```
+
+**Output path**: `.claude/prds/{kebab-case-name}.prd.md`
+
+#### PRD Template
+
+```markdown
+# {Product / Feature Name}
+
+## Problem
+{2–3 sentences: who has what problem, and what's the cost of leaving it unsolved?}
+
+## Evidence
+- {User quote, data point, or observation}
+- {OR: "Assumption — needs validation via {method}"}
+
+## Users
+- **Primary**: {role, context, what triggers the need}
+- **Not for**: {who this explicitly excludes}
+
+## Hypothesis
+We believe **{capability}** will **{solve problem}** for **{users}**.
+We'll know we're right when **{measurable outcome}**.
+
+## Success Metrics
+| Metric | Target | How measured |
+|---|---|---|
+| {primary} | {number} | {method} |
+
+## Scope
+**MVP** — {the minimum to test the hypothesis}
+
+**Out of scope**
+- {item} — {why deferred}
+
+## Delivery Milestones
+<!-- Business outcomes, not engineering tasks. /plan turns each into a plan. -->
+<!-- Status: pending | in-progress | complete -->
+
+| # | Milestone | Outcome | Status | Plan |
+|---|---|---|---|---|
+| 1 | {name} | {user-visible change} | pending | — |
+| 2 | {name} | {user-visible change} | pending | — |
+
+## Open Questions
+- [ ] {question that could change scope or approach}
+
+## Risks
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+
+---
+*Status: DRAFT — requirements only. Implementation planning pending via /plan.*
+```
+
+#### Report to user
+
+```
+PRD created: .claude/prds/{name}.prd.md
+
+Problem:    {one line}
+Hypothesis: {one line}
+MVP:        {one line}
+
+Validation status:
+  Problem  {validated | assumption}
+  Users    {concrete | generic — refine}
+  Metrics  {defined | TBD}
+
+Open questions: {count}
+
+Next step: /plan .claude/prds/{name}.prd.md
+  → /plan will pick the next pending milestone and produce an implementation plan.
+```
+
+## Integration
+
+- `/plan <prd-path>` — consume the PRD and produce an implementation plan for the next pending milestone.
+- `tdd-workflow` skill — implement the plan test-first.
+- `/pr` — open a PR that references the PRD and plan.
+
+## Success criteria
+
+- **PROBLEM_CLEAR**: problem is specific and evidenced (or flagged as assumption).
+- **USER_CONCRETE**: primary user is a specific role, not "users".
+- **HYPOTHESIS_TESTABLE**: measurable outcome included.
+- **SCOPE_BOUNDED**: explicit MVP and explicit out-of-scope.
+- **NO_IMPLEMENTATION_DETAIL**: file paths, libraries, or task breakdowns are absent — if they appeared, move them to the `/plan` step.

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

@@ -1,10 +1,13 @@
 ---
 description: Restate requirements, assess risks, and create step-by-step implementation plan. WAIT for user CONFIRM before touching any code.
+argument-hint: "[feature description | path/to/*.prd.md]"
 ---
 
 # Plan Command
 
-This command invokes the **planner** agent to create a comprehensive implementation plan before writing any code.
+This command creates a comprehensive implementation plan before writing any code. It accepts either free-form requirements or a PRD markdown file.
+
+Run inline by default. Do not call the Task tool or any subagent by default. This keeps `/plan` usable from plugin installs that ship commands without agent files.
 
 ## What This Command Does
 
@@ -24,21 +27,96 @@ Use `/plan` when:
 
 ## How It Works
 
-The planner agent will:
+The assistant will:
 
 1. **Analyze the request** and restate requirements in clear terms
-2. **Break down into phases** with specific, actionable steps
-3. **Identify dependencies** between components
-4. **Assess risks** and potential blockers
-5. **Estimate complexity** (High/Medium/Low)
-6. **Present the plan** and WAIT for your explicit confirmation
+2. **Ground the plan** in relevant codebase patterns when the repo is available
+3. **Break down into phases** with specific, actionable steps
+4. **Identify dependencies** between components
+5. **Assess risks** and potential blockers
+6. **Estimate complexity** (High/Medium/Low)
+7. **Present the plan** and WAIT for your explicit confirmation
+
+## Input Modes
+
+| Input | Mode | Behavior |
+|---|---|---|
+| `path/to/name.prd.md` | PRD artifact mode | Read the PRD, pick the next pending delivery milestone or implementation phase, and write `.claude/plans/{name}.plan.md` |
+| Any other markdown path | Reference mode | Read the file as context and produce an inline plan |
+| Free-form text | Conversational mode | Produce an inline plan |
+| Empty input | Clarification mode | Ask what should be planned |
+
+In PRD artifact mode, create `.claude/plans/` if needed. If the PRD contains a `Delivery Milestones` table, update only the selected row from `pending` to `in-progress` and set its `Plan` cell to the generated plan path. If the PRD uses the legacy `.claude/PRPs/prds/` format with `Implementation Phases`, read it without migrating paths.
+
+## Pattern Grounding
+
+Before writing the plan, search the codebase for conventions the implementation should mirror. Capture the top example for each relevant category with file references:
+
+| Category | What to capture |
+|---|---|
+| Naming | File, function, type, command, or script naming in the affected area |
+| Error handling | How failures are raised, returned, logged, or handled gracefully |
+| Logging | Levels, format, and what gets logged |
+| Data access | Repository, service, query, or filesystem patterns |
+| Tests | Test file location, framework, fixtures, and assertion style |
+
+If no similar code exists, state that explicitly. Do not invent a pattern.
+
+## PRD Artifact Output
+
+When called with a `.prd.md` file, write the plan to `.claude/plans/{kebab-case-name}.plan.md` using this structure:
+
+````markdown
+# Plan: {Feature Name}
+
+**Source PRD**: {path}
+**Selected Milestone**: {milestone or phase name}
+**Complexity**: {Small | Medium | Large}
+
+## Summary
+{2-3 sentences}
+
+## Patterns to Mirror
+| Category | Source | Pattern |
+|---|---|---|
+| Naming | `path:line` | {short description} |
+| Errors | `path:line` | {short description} |
+| Tests | `path:line` | {short description} |
+
+## Files to Change
+| File | Action | Why |
+|---|---|---|
+| `path` | CREATE / UPDATE / DELETE | {reason} |
+
+## Tasks
+### Task 1: {name}
+- **Action**: {what to do}
+- **Mirror**: {pattern to follow}
+- **Validate**: {command that proves correctness}
+
+## Validation
+```bash
+{project-specific validation commands}
+```
+
+## Risks
+| Risk | Likelihood | Mitigation |
+|---|---|---|
+
+## Acceptance
+- [ ] All tasks complete
+- [ ] Validation passes
+- [ ] Patterns mirrored, not reinvented
+````
+
+After writing the artifact, report its path and WAIT for confirmation before writing code.
 
 ## Example Usage
 
 ```
 User: /plan I need to add real-time notifications when markets resolve
 
-Agent (planner):
+Assistant:
 # Implementation Plan: Real-Time Market Resolution Notifications
 
 ## Requirements Restatement
@@ -93,7 +171,7 @@ Agent (planner):
 
 ## Important Notes
 
-**CRITICAL**: The planner agent will **NOT** write any code until you explicitly confirm the plan with "yes" or "proceed" or similar affirmative response.
+**CRITICAL**: This command will **NOT** write any code until you explicitly confirm the plan with "yes" or "proceed" or similar affirmative response.
 
 If you want changes, respond with:
 - "modify: [your changes]"
@@ -103,15 +181,20 @@ If you want changes, respond with:
 ## Integration with Other Commands
 
 After planning:
-- Use `/tdd` to implement with test-driven development
+- Use the `tdd-workflow` skill to implement with test-driven development
 - Use `/build-fix` if build errors occur
 - Use `/code-review` to review completed implementation
+- Use `/pr` or `/prp-pr` to open a pull request
+
+> **Need requirements first?** Use `/plan-prd` for a lean PRD at `.claude/prds/{name}.prd.md`.
+>
+> **Need the legacy PRP flow?** Use `/prp-plan` for deep PRP planning with `.claude/PRPs/` artifacts. Use `/prp-implement` to execute those plans with rigorous validation loops.
 
-> **Need deeper planning?** Use `/prp-plan` for artifact-producing planning with PRD integration, codebase analysis, and pattern extraction. Use `/prp-implement` to execute those plans with rigorous validation loops.
+## Optional Planner Agent
 
-## Related Agents
+ECC also provides a `planner` agent for manual installs that include agent files. Use it only when the local runtime already exposes that subagent and the user explicitly asks you to delegate planning.
 
-This command invokes the `planner` agent provided by ECC.
+If the `planner` subagent is unavailable, continue planning inline instead of surfacing an "Agent type 'planner' not found" error.
 
 For manual installs, the source file lives at:
 `agents/planner.md`

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

@@ -1,3 +1,7 @@
+---
+description: Analyze a project and generate PM2 service commands for detected frontend, backend, or database services.
+---
+
 # PM2 Init
 
 Auto-analyze project and generate PM2 service commands.