@rubix0270/arboris 1.0.2 → 1.0.3

package/prisma/skills/orch-build-mvp/SKILL.md

@@ -1,49 +0,0 @@
----
-name: orch-build-mvp
-description: Orchestrate bootstrapping a working MVP from a design or spec document — ingest the doc, plan thin vertical slices, scaffold the first end-to-end slice, then TDD-implement, review, and gated commit. Use to turn an SDD/PRD into a running starting point.
-metadata:
-  origin: ECC
----
-
-# orch-build-mvp
-
-Actor · action · target: **orch · build · mvp**. Thin wrapper over the shared
-engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
-
-## When to Use
-
-- The user has a **design / spec document** (SDD, PRD, system_design) and wants a
-  working vertical slice bootstrapped from it.
-- Takes a doc path as its argument, e.g. `civicpulse/docs/SDD-v0.6.md`.
-
-## Operation settings
-
-- **Default size floor:** large — this is the full pipeline including Scaffold.
-- **Phase mask:** 0 (read the spec) → 1 → 2 (heavy) → 3 (scaffold) → 4 → 5 → 6.
-- **First move (phase 0 → 2):** read the doc; extract scope, locked decisions,
-  and the feature list; order it into **thin vertical slices** (one end-to-end
-  path first, not all-models-then-all-views). Phase 3 stands up that first slice.
-
-## How It Works
-
-1. Run the `orch-pipeline` engine with the settings above.
-2. **Reuse the existing GAN harness** instead of hand-rolling an iterate loop:
-   - Translate the SDD into `gan-harness/spec.md` + `gan-harness/eval-rubric.md`
-     (this stands in for what `gan-planner` would generate — you already have the spec).
-   - Drive the build with `/gan-build "<one-line brief>" --skip-planner`
-     (defaults: `--max-iterations 15`, `--pass-threshold 7.0`,
-     `--eval-mode playwright`; use `--eval-mode code-only` for non-UI slices).
-   - That command runs the `gan-generator` → `gan-evaluator` loop and writes
-     `gan-harness/feedback/feedback-NNN.md` until the score passes or plateaus.
-3. Stop at **Gate 1** (slice plan) and **Gate 2** (pre-commit). Commit the
-   scaffold and each slice as separate `feat:` commits.
-4. Add `security-reviewer` for any slice touching a security trigger.
-
-## Example
-
-```
-orch-build-mvp: civicpulse/docs/SDD-v0.6.md
-→ read SDD → slice list (vertical) → scaffold slice 1  [GATE 1: approve]
-→ /gan-build --skip-planner (generator → evaluator loop) scores vs spec → review
-→ commit feat:  [GATE 2: confirm] → next slice
-```

package/prisma/skills/orch-change-feature/SKILL.md

@@ -1,43 +0,0 @@
----
-name: orch-change-feature
-description: Orchestrate altering an existing, working feature to new desired behavior — update its tests to the new spec, change the implementation to match, review, and gated commit. Use when behavior is not broken but should be different.
-metadata:
-  origin: ECC
----
-
-# orch-change-feature
-
-Actor · action · target: **orch · change · feature**. Thin wrapper over the
-shared engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
-
-## When to Use
-
-- An existing feature **works**, but the desired behavior is different ("change",
-  "adjust", "make it also …", "instead of X do Y").
-- Distinguish from siblings:
-  - **not** broken → not `orch-fix-defect` (no bug to reproduce).
-  - **not** new → not `orch-add-feature` (the capability already exists).
-
-## Operation settings
-
-- **Default size floor:** small — most tweaks are a function or two.
-- **Phase mask:** 0 → (1 only if the new behavior needs research) → light 2 →
-  4 → 5 → 6.
-- **First move (phase 4):** update the *existing* tests to express the new
-  desired behavior, then change the implementation until they pass. Changing the
-  tests first is what separates a tweak from a fix.
-
-## How It Works
-
-1. Run the `orch-pipeline` engine with the settings above.
-2. Keep the plan light — only `standard`+ size warrants the full `planner` pass.
-3. Stop at **Gate 1** (plan / changed-test approval) and **Gate 2** (pre-commit).
-4. Add `security-reviewer` if the change touches a security trigger.
-
-## Example
-
-```
-orch-change-feature: make nws-poller alert at 2 warnings instead of 3
-→ update threshold tests to new spec → change impl to green
-→ code-review → commit  [GATE 2: confirm]
-```

package/prisma/skills/orch-fix-defect/SKILL.md

@@ -1,43 +0,0 @@
----
-name: orch-fix-defect
-description: Orchestrate fixing a bug — reproduce it as a failing regression test, fix to green, review, and gated commit — by delegating each phase to the matching ECC agent. Use when existing behavior is broken or wrong.
-metadata:
-  origin: ECC
----
-
-# orch-fix-defect
-
-Actor · action · target: **orch · fix · defect**. Thin wrapper over the shared
-engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
-
-## When to Use
-
-- Something is **broken**: wrong output, an error, a crash, a regression.
-- Distinguish from siblings:
-  - behavior is correct but you want it different → `orch-change-feature`.
-  - the capability does not exist yet → `orch-add-feature`.
-
-## Operation settings
-
-- **Default size floor:** small (often trivial).
-- **Phase mask:** 0 → (light 2 only if root cause is non-obvious or standard+) →
-  4 → 5 → 6. Research (1) is usually skipped.
-- **First move (phase 4):** reproduce the bug as a **new failing** test
-  (regression test), then fix until it goes green. Proving the bug exists first
-  is what separates a fix from a tweak.
-
-## How It Works
-
-1. Run the `orch-pipeline` engine with the settings above.
-2. If the root cause is unclear, scope it with `code-explorer` before the red
-   test; escalate build breaks to `build-error-resolver` / `/build-fix`.
-3. Stop at **Gate 1** (only if a plan was produced) and **Gate 2** (pre-commit).
-4. Add `security-reviewer` if the defect sits in a security-sensitive path.
-
-## Example
-
-```
-orch-fix-defect: poller crashes on empty NWS response
-→ write failing test reproducing the crash → fix to green
-→ code-review → commit  [GATE 2: confirm]   (commit: fix:)
-```

package/prisma/skills/orch-pipeline/SKILL.md

@@ -1,121 +0,0 @@
----
-name: orch-pipeline
-description: Shared orchestration engine for the orch-* skill family. Defines the gated Research-Plan-TDD-Review-Commit pipeline, the size classifier, the agent map, and the two human gates that the orch-* operation skills delegate to. Not usually invoked directly.
-metadata:
-  origin: ECC
----
-
-# Orchestrator Pipeline (shared engine)
-
-The `orch-*` skills are thin wrappers. They do not re-implement any work — they
-classify the request, choose which phases of *this* pipeline run, and delegate
-each phase to an existing ECC agent or command. This file is that pipeline.
-
-> Invoke an operation skill (`orch-add-feature`, `orch-fix-defect`, …) rather
-> than this engine directly. This file is the reference they point at.
-
-## When to Use
-
-- Loaded indirectly whenever an `orch-*` operation skill runs.
-- Read directly only when adding a new operation to the family or tuning the
-  shared phases, gates, or agent map.
-
-## The operation family
-
-| Skill | Operation | Trigger | First move |
-|-------|-----------|---------|------------|
-| `orch-add-feature` | feature | capability does not exist yet | research + plan a new slice |
-| `orch-change-feature` | tweak | works, but desired behavior differs | amend existing behavior *and its tests* |
-| `orch-fix-defect` | fix | broken; behavior is wrong | reproduce as a failing test, then fix |
-| `orch-refine-code` | refactor | behavior stays, structure improves | restructure while keeping tests green |
-| `orch-build-mvp` | mvp | bootstrap from a design/spec doc | ingest doc → vertical slices |
-
-> These wrappers **compose** existing ECC commands rather than replace them:
-> `/feature-dev`, `/plan`, `/code-review`, `/build-fix`, `/refactor-clean`, and
-> `/gan-build`, plus the `tdd-workflow` skill. The orch-* family adds the shared
-> size classifier and the two gates
-> on top of them, so one umbrella covers all five operations consistently.
-
-## Step 0 — Classify size (right-sizing)
-
-Ceremony scales to blast radius. Score the request on three signals, take the
-**highest** tier any signal reaches, and state the result in one line so the user
-can override:
-
-| Tier | Files touched | New dependency / contract | Design ambiguity | Phases that run |
-|------|---------------|---------------------------|------------------|-----------------|
-| trivial | 1, a few lines | none | none — the change is obvious | 4 → 5 → 6 |
-| small | 1 file / 1 function | none | clear once you read the code | (1 light) → 4 → 5 → 6 |
-| standard | 2–5 files | maybe a new internal module | one real choice to make | 1 → 2 → 4 → 5 → 6 |
-| large | many / cross-cutting | new external dep, public API, or a spec doc | multiple open questions | 1 → 2 → (3) → 4 → 5 → 6 |
-
-Phase 0 (Intake) always runs and is omitted from the mask column above. The
-tie-breaker: anything touching a security trigger (below) or a public API /
-contract is **at least** standard, regardless of file count.
-
-## The phases
-
-Each phase delegates — it does not do the work inline.
-
-- **0. Intake** — restate the request. For `orch-build-mvp`, read the spec/design
-  doc and extract scope, locked decisions, and a feature list.
-- **1. Research & Reuse** — per `rules/common/development-workflow.md`: `gh search repos` /
-  `gh search code`, then Context7 / vendor docs, then package registries, then
-  Exa. Prefer adopting a proven implementation over net-new code.
-- **2. Plan** — delegate to the `planner` agent (or `architect` /
-  `code-architect` for structural decisions). Output a `task_list` ordered as
-  thin vertical slices. → **GATE 1.**
-- **3. Scaffold** — `orch-build-mvp` only: stand up the first end-to-end slice.
-- **4. Implement (TDD)** — drive each task through the `tdd-guide` agent (or the `tdd-workflow` skill):
-  red → green → refactor. Honor the operation's first-move rule.
-- **5. Review** — `code-reviewer` agent / `/code-review`. Add `security-reviewer`
-  whenever the diff touches a security trigger (below).
-- **6. Commit** — conventional commits (`feat:` / `fix:` / `refactor:` / …), one
-  per logical chunk. → **GATE 2.**
-
-## The two gates
-
-This family is **gated, not autonomous**:
-
-1. **GATE 1 — after Plan.** Present the `task_list`; do not write implementation
-   code until the user approves.
-2. **GATE 2 — before Commit.** Present the diff summary and proposed messages;
-   do not commit until the user confirms.
-
-Everything between the gates flows without stopping.
-
-## Agent / command map
-
-| Phase | Primary | Fallback / escalation |
-|-------|---------|----------------------|
-| Intake / understand | `code-explorer` | trace existing paths before a tweak, fix, or refactor |
-| Plan | `planner` | `architect`, `code-architect` for structural calls |
-| Implement | `tdd-guide` (or `tdd-workflow` skill) | `build-error-resolver` / `/build-fix` on build breaks |
-| Review | `code-reviewer` / `/code-review` | language reviewer (`python-reviewer`, `typescript-reviewer`, …) |
-| Security | `security-reviewer` | — |
-| MVP inner loop | `/gan-build "<brief>" --skip-planner` | drives `gan-generator` → `gan-evaluator`; tune `--max-iterations` / `--pass-threshold` |
-
-Match the language reviewer to the repo (see the repo's own `CLAUDE.md`).
-
-## Security-review trigger
-
-Pull in `security-reviewer` when the diff touches any of: authentication or
-authorization, user-input handling, database queries, file-system paths,
-external API calls, cryptography, or secrets / credentials. (Per `rules/common/security.md`.)
-
-## Handoff artifacts
-
-The pipeline carries no hidden state — the planning docs *are* the handoff:
-
-- `task_list` (from Plan) drives the Implement loop.
-- Larger work may also emit PRD / architecture / system_design under the repo's
-  `docs/` per `rules/common/development-workflow.md`.
-- Review findings (CRITICAL / HIGH) must be resolved before Gate 2.
-
-## Verification
-
-- size tier was stated and matched the work
-- Gate 1 (plan) and Gate 2 (commit) were both honored
-- `security-reviewer` ran iff a security trigger was touched
-- commits are conventional and scoped to one logical change
-- new / changed behavior has tests; coverage ≥ 80% per `rules/common/testing.md`

package/prisma/skills/orch-refine-code/SKILL.md

@@ -1,44 +0,0 @@
----
-name: orch-refine-code
-description: Orchestrate a behavior-preserving refactor — confirm tests are green, restructure without changing behavior, keep tests green, review, and gated commit. Use when the structure should improve but behavior must not change.
-metadata:
-  origin: ECC
----
-
-# orch-refine-code
-
-Actor · action · target: **orch · refine · code**. Thin wrapper over the shared
-engine in [`orch-pipeline`](../orch-pipeline/SKILL.md).
-
-## When to Use
-
-- Same behavior, **better structure**: extract modules, remove duplication, kill
-  dead code, reduce nesting, rename for clarity.
-- Distinguish from siblings: if behavior is meant to change at all, this is the
-  wrong skill (`orch-change-feature` / `orch-fix-defect`).
-
-## Operation settings
-
-- **Default size floor:** standard — restructures touch multiple files.
-- **Phase mask:** 0 → 2 (plan the restructure) → 4 (keep green) → 5 → 6. No new
-  behavior tests are written — the existing suite is the safety net.
-- **First move (phase 4):** confirm the relevant tests exist and are **green
-  before** touching code; if coverage is thin, add characterization tests first.
-  Then restructure in small steps, re-running tests after each.
-
-## How It Works
-
-1. Run the `orch-pipeline` engine with the settings above.
-2. For dead-code / duplication sweeps, delegate to the `refactor-cleaner` agent
-   (it runs knip / depcheck / ts-prune and removes safely).
-3. Stop at **Gate 1** (restructure plan) and **Gate 2** (pre-commit).
-4. Commit as `refactor:` — the diff must be behavior-neutral.
-
-## Example
-
-```
-orch-refine-code: extract the NWS HTTP client out of poller.py
-→ confirm tests green → plan extraction  [GATE 1: approve]
-→ move in small steps, tests green throughout → code-review
-→ commit refactor:  [GATE 2: confirm]
-```

package/prisma/skills/parallel-execution-optimizer/SKILL.md

@@ -1,73 +0,0 @@
----
-name: parallel-execution-optimizer
-description: Use when the user wants a task done much faster through parallel work, concurrent agents, batched tool calls, isolated worktrees, or many independent verification lanes without losing correctness.
-metadata:
-  origin: ECC
-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# Parallel Execution Optimizer
-
-Use this skill when speed comes from doing independent work at the same time:
-repo inspection, file reads, API checks, browser checks, build/test lanes,
-deploy readbacks, or multi-worktree implementation passes.
-
-## Core Pattern
-
-Turn urgency into a dependency graph before acting.
-
-1. Define the objective and done signal.
-2. Split work into lanes.
-3. Mark each lane as parallel, sequential, or gated.
-4. Run independent reads/checks together.
-5. Keep writes isolated by file, worktree, branch, service, or dataset.
-6. Merge only after evidence shows the lanes are compatible.
-7. End with a verification table, not a vague speed claim.
-
-## Lane Matrix
-
-Before a large push, write a compact matrix:
-
-```text
-Lane | Can run in parallel? | Write surface | Risk | Verification
-Repo scan | yes | none | low | rg/git status outputs
-Backend patch | maybe | src/api | medium | unit tests
-Frontend patch | maybe | app/components | medium | browser screenshot
-Deploy readback | after build | remote service | high | live URL + logs
-```
-
-Only run lanes in parallel when their write surfaces do not collide.
-
-## Execution Rules
-
-- Batch file reads, searches, status checks, and metadata queries.
-- Use isolated worktrees for large unrelated implementation lanes.
-- Start long-running tests, builds, backfills, and deploys in separate sessions,
-  then poll them deliberately.
-- If a lane discovers a blocker that changes the plan, pause dependent lanes
-  and update the matrix.
-- Never let a background process outlive the turn unless the user explicitly
-  asked for a continuing service.
-- Do not parallelize destructive commands, migrations, writes to the same table,
-  or live customer-impacting deploys without an explicit gate.
-
-## Output Shape
-
-Use this when reporting:
-
-```text
-Parallel execution result:
-- Lanes run: 5
-- Lanes completed: 4
-- Blocked lane: deploy readback, waiting on DNS propagation
-- Fast path found: batched repo scan + focused tests
-- Verification: lint pass, unit pass, live smoke pass
-```
-
-## Failure Modes
-
-- More concurrency that creates conflicting edits.
-- Benchmarking the tool instead of the task.
-- Treating "fast" as done before correctness is proven.
-- Forgetting to poll running sessions.
-- Hiding skipped checks behind a success summary.