feat: add orch-* orchestrator skill family (#2153)

* feat: add orch-* orchestrator skill family

Lightweight wrappers that orchestrate existing ECC agents through a gated Research -> Plan -> TDD -> Review -> Commit pipeline, right-sized per task.

- orch-pipeline: shared engine (phases, size classifier, two gates, agent map)
- orch-add-feature/change-feature/fix-defect/refine-code/build-mvp: thin wrappers delegating to the engine

* chore: register orch-* family in catalog, command registry, and agent.yaml (post-rebase onto green main)

---------

Co-authored-by: ECC Test <ecc@example.test>

commands/orch-add-feature.md

@@ -0,0 +1,36 @@
+---
+description: Orchestrate building a brand-new feature end to end — research, plan, TDD, review, gated commit. Wrapper that kicks off the orch-add-feature skill.
+---
+
+# /orch-add-feature
+
+Manually launch the **orch-add-feature** orchestrator: a gated
+Research → Plan → TDD → Review → Commit pipeline for net-new capability.
+
+## Usage
+
+```
+/orch-add-feature <what to add>
+```
+
+Examples:
+
+```
+/orch-add-feature add OAuth2 login to nws-poller
+/orch-add-feature support CSV export in the dashboard
+```
+
+## What It Does
+
+Invoke the `orch-add-feature` skill with `$ARGUMENTS` as the request. The skill
+(via the shared `orch-pipeline` engine) will:
+
+1. Classify size and state the tier in one line.
+2. Research existing libraries/patterns, then plan a `task_list`. → **GATE 1** (approve plan).
+3. TDD each task (new failing tests → green), then `code-reviewer`
+   (+ `security-reviewer` if a security trigger is touched).
+4. Commit as conventional `feat:` commits. → **GATE 2** (confirm before commit).
+
+Honor both gates — do not write implementation before Gate 1, do not commit before Gate 2.
+
+If `$ARGUMENTS` is empty, ask the user what capability to add.

commands/orch-build-mvp.md

@@ -0,0 +1,36 @@
+---
+description: Orchestrate bootstrapping a working MVP from a design/spec doc — ingest, slice, scaffold, TDD, review, gated commit (reuses the GAN harness). Wrapper for the orch-build-mvp skill.
+---
+
+# /orch-build-mvp
+
+Manually launch the **orch-build-mvp** orchestrator: turn an SDD/PRD/system-design
+document into a running vertical slice.
+
+## Usage
+
+```
+/orch-build-mvp <path to design/spec doc>
+```
+
+Examples:
+
+```
+/orch-build-mvp civicpulse/docs/SDD-v0.6.md
+```
+
+## What It Does
+
+Invoke the `orch-build-mvp` skill with `$ARGUMENTS` as the doc path. The skill
+(via the shared `orch-pipeline` engine, full pipeline incl. Scaffold) will:
+
+1. Read the spec; extract scope, locked decisions, and a feature list ordered as
+   **thin vertical slices** (one end-to-end path first). → **GATE 1** (approve slice plan).
+2. Scaffold the first end-to-end slice.
+3. Reuse the GAN harness: translate the SDD into `gan-harness/spec.md` +
+   `eval-rubric.md`, then drive `/gan-build "<brief>" --skip-planner`
+   (generator → evaluator loop) until the score passes or plateaus.
+4. `code-reviewer` (+ `security-reviewer` on any security-trigger slice), then
+   commit the scaffold and each slice as separate `feat:` commits. → **GATE 2**.
+
+If `$ARGUMENTS` is empty, ask the user for the path to the design/spec doc.

commands/orch-change-feature.md

@@ -0,0 +1,38 @@
+---
+description: Orchestrate altering an existing, working feature to new desired behavior — update tests to the new spec, change impl, review, gated commit. Wrapper for the orch-change-feature skill.
+---
+
+# /orch-change-feature
+
+Manually launch the **orch-change-feature** orchestrator: change behavior that
+already works to a new desired spec, tests-first.
+
+## Usage
+
+```
+/orch-change-feature <the new desired behavior>
+```
+
+Examples:
+
+```
+/orch-change-feature make nws-poller alert at 2 warnings instead of 3
+/orch-change-feature instead of sorting by date, sort by priority
+```
+
+## What It Does
+
+Invoke the `orch-change-feature` skill with `$ARGUMENTS` as the request. The skill
+(via the shared `orch-pipeline` engine) will:
+
+1. Classify size (default floor: small) and state the tier.
+2. Light plan only if the new behavior needs research. → **GATE 1** (approve changed-test plan).
+3. **Update the existing tests** to express the new behavior, then change the
+   implementation until green. (Changing the tests first is what makes this a
+   tweak, not a fix.)
+4. `code-reviewer` (+ `security-reviewer` on a security trigger), then commit. → **GATE 2**.
+
+Use this only when the feature **works** but should behave differently — not for
+bugs (`/orch-fix-defect`) or net-new capability (`/orch-add-feature`).
+
+If `$ARGUMENTS` is empty, ask the user what behavior should change.

commands/orch-fix-defect.md

@@ -0,0 +1,38 @@
+---
+description: Orchestrate fixing a bug — reproduce it as a failing regression test, fix to green, review, gated commit. Wrapper for the orch-fix-defect skill.
+---
+
+# /orch-fix-defect
+
+Manually launch the **orch-fix-defect** orchestrator: prove the bug with a red
+test, then fix to green.
+
+## Usage
+
+```
+/orch-fix-defect <what is broken>
+```
+
+Examples:
+
+```
+/orch-fix-defect poller crashes on empty NWS response
+/orch-fix-defect login returns 500 when email has a plus sign
+```
+
+## What It Does
+
+Invoke the `orch-fix-defect` skill with `$ARGUMENTS` as the request. The skill
+(via the shared `orch-pipeline` engine) will:
+
+1. Classify size (default floor: small, often trivial); scope root cause with
+   `code-explorer` if unclear.
+2. **Write a new failing regression test** reproducing the bug, then fix until
+   it goes green. (Proving the bug first is what makes this a fix, not a tweak.)
+3. `code-reviewer` (+ `security-reviewer` if the defect sits in a sensitive path).
+4. Commit as a conventional `fix:` commit. → **GATE 2** (confirm before commit).
+
+Use this only when behavior is **broken/wrong** — not for intentional changes
+(`/orch-change-feature`) or new capability (`/orch-add-feature`).
+
+If `$ARGUMENTS` is empty, ask the user to describe the defect.

commands/orch-refine-code.md

@@ -0,0 +1,39 @@
+---
+description: Orchestrate a behavior-preserving refactor — confirm tests green, restructure without changing behavior, keep green, review, gated commit. Wrapper for the orch-refine-code skill.
+---
+
+# /orch-refine-code
+
+Manually launch the **orch-refine-code** orchestrator: improve structure while
+behavior stays identical, with the existing test suite as the safety net.
+
+## Usage
+
+```
+/orch-refine-code <what to restructure>
+```
+
+Examples:
+
+```
+/orch-refine-code extract the NWS HTTP client out of poller.py
+/orch-refine-code remove dead code and duplication in the dashboard module
+```
+
+## What It Does
+
+Invoke the `orch-refine-code` skill with `$ARGUMENTS` as the request. The skill
+(via the shared `orch-pipeline` engine) will:
+
+1. Classify size (default floor: standard — restructures touch multiple files).
+2. Confirm the relevant tests exist and are **green before** touching code; add
+   characterization tests first if coverage is thin. Plan the restructure. → **GATE 1**.
+3. Restructure in small steps, re-running tests after each (no new behavior
+   tests — the existing suite proves behavior is unchanged). Dead-code/dup sweeps
+   delegate to `refactor-cleaner`.
+4. `code-reviewer`, then commit as `refactor:` (the diff must be behavior-neutral). → **GATE 2**.
+
+Use this only when behavior must **not** change. If behavior should change at
+all, use `/orch-change-feature` or `/orch-fix-defect`.
+
+If `$ARGUMENTS` is empty, ask the user what to refine.