@rubix0270/arboris 1.0.2 → 1.0.4

package/prisma/skills/uncloud/SKILL.md

@@ -1,344 +0,0 @@
----
-name: uncloud
-description: Use when managing an Uncloud cluster — deploying services, configuring Caddy ingress, adding static proxy routes for non-cluster devices, publishing ports, scaling, inspecting logs, or managing machines and volumes with the `uc` CLI.
-metadata:
-  origin: ECC
----
-
-# Uncloud Cluster Management
-
-Reference for the `uc` CLI — a decentralised self-hosting platform using Docker containers, WireGuard mesh networking, and Caddy reverse proxy.
-
-## When to Activate
-
-Use this skill when working with Uncloud clusters, especially when:
-- Bootstrapping or joining machines with `uc machine`
-- Deploying services from Compose files with `uc deploy`
-- Publishing HTTP, HTTPS, TCP, or UDP ports through Uncloud
-- Configuring Caddy ingress with `x-caddy`, `x-ports`, or `--caddyfile`
-- Routing external LAN devices through the cluster proxy
-- Inspecting logs, service state, volumes, DNS, or machine placement
-
-## How It Works
-
-Uncloud runs Docker services across peer machines connected by a WireGuard mesh. Each machine is an equal cluster member; services communicate on the overlay network and Caddy runs globally to terminate public HTTP/HTTPS traffic. Compose files can use Uncloud extensions for ingress, placement, and generated Caddy configuration, while the `uc` CLI handles image distribution, scheduling, scaling, logs, and cluster state.
-
-## Examples
-
-```bash
-uc machine init user@host --name machine-1
-uc service run --name web -p app.example.com:8080/https nginx:latest
-uc deploy
-```
-
-## Core Concepts
-
-- **No central control plane** — all machines are equal peers connected by WireGuard
-- **Caddy** runs as a global service on every machine; auto-obtains TLS from Let's Encrypt
-- **Overlay network** — services communicate via `10.210.0.0/16` by default; DNS provided inside the mesh
-- **Caddyfile is autogenerated** — never edit it directly; use `x-caddy` / `--caddyfile` instead
-
----
-
-## CLI Quick Reference
-
-### Machines
-
-| Command | Purpose |
-|---------|---------|
-| `uc machine init user@host` | Bootstrap first machine / new cluster |
-| `uc machine add user@host` | Join machine to existing cluster |
-| `uc machine ls` | List machines |
-| `uc machine update NAME --public-ip IP` | Update public IP for ingress |
-| `uc machine rm NAME` | Remove machine |
-
-Key `init` flags: `--name`, `--network 10.210.0.0/16`, `--no-caddy`, `--no-dns`, `--public-ip auto\|IP\|none`
-
-### Services
-
-| Command | Purpose |
-|---------|---------|
-| `uc service ls` / `uc ls` | List services |
-| `uc service run IMAGE` | Run a single container service |
-| `uc deploy` | Deploy from `compose.yaml` |
-| `uc deploy --no-build` | Deploy already-pushed images without rebuilding |
-| `uc deploy --recreate` | Force service recreation |
-| `uc scale SERVICE N` | Set replica count |
-| `uc service logs SERVICE` | View logs |
-| `uc service exec SERVICE` | Shell into container |
-| `uc service inspect SERVICE` | Detailed info |
-| `uc service rm SERVICE` | Remove service (keeps named volumes) |
-| `uc ps` | All containers across cluster |
-
-### Images
-
-```bash
-uc image push myapp:latest                    # Push local image to all machines
-uc image push myapp:latest -m machine1,machine2  # Push to specific machines
-uc images                                     # List images in cluster
-```
-
-### Volumes
-
-```bash
-uc volume ls                  # All volumes
-uc volume ls -m machine1      # On specific machine
-uc volume create NAME -m MACHINE
-uc volume rm NAME
-```
-
-### Caddy
-
-```bash
-uc caddy config    # Show current generated Caddyfile (read-only)
-uc caddy deploy    # Deploy/upgrade Caddy across cluster
-```
-
-### DNS & Context
-
-```bash
-uc dns show        # Show reserved *.uncld.dev domain
-uc dns reserve     # Reserve a new domain
-uc ctx ls          # List cluster contexts
-uc ctx use prod    # Switch context
-```
-
----
-
-## Port Publishing
-
-### HTTP/HTTPS (via Caddy reverse proxy)
-
-```
--p [hostname:]container_port[/protocol]
-```
-
-| Example | Meaning |
-|---------|---------|
-| `-p 8080/https` | HTTPS with auto `service-name.cluster-domain` hostname |
-| `-p app.example.com:8080/https` | HTTPS with custom hostname |
-| `-p 8080/http` | HTTP only, no TLS |
-
-### TCP/UDP (host-bound, bypasses Caddy)
-
-```
--p [host_ip:]host_port:container_port[/protocol]@host
-```
-
-| Example | Meaning |
-|---------|---------|
-| `-p 5432:5432@host` | TCP 5432 on all interfaces |
-| `-p 127.0.0.1:5432:5432@host` | TCP 5432 loopback only |
-| `-p 53:5353/udp@host` | UDP |
-
----
-
-## Compose File Extensions
-
-Uncloud adds these extensions on top of Docker Compose:
-
-### `x-ports` — publish ports with domains
-
-```yaml
-services:
-  app:
-    image: app:latest
-    x-ports:
-      - example.com:8000/https
-      - www.example.com:8000/https
-      - api.example.com:9000/https
-```
-
-### `x-caddy` — custom Caddy config for service
-
-```yaml
-services:
-  app:
-    image: app:latest
-    x-caddy: |
-      example.com {
-        redir https://www.example.com{uri} permanent
-      }
-      www.example.com {
-        reverse_proxy {{upstreams 8000}} {
-          import common_proxy
-        }
-        basic_auth /admin/* {
-          admin $2a$14$...
-        }
-      }
-```
-
-Template functions available inside `x-caddy`:
-- `{{upstreams [service] [port]}}` — healthy container IPs
-- `{{.Name}}` — service name
-- `{{.Upstreams}}` — map of all services → IPs
-
-### `x-machines` — placement constraints
-
-```yaml
-services:
-  db:
-    image: postgres:18
-    x-machines: db-machine          # Single machine name
-  app:
-    image: app:latest
-    x-machines:
-      - machine-1
-      - machine-2
-```
-
-### Full multi-service example
-
-```yaml
-services:
-  api:
-    build: ./api
-    x-ports:
-      - api.example.com:3000/https
-    environment:
-      DATABASE_URL: postgres://db:5432/mydb
-
-  web:
-    build: ./web
-    x-ports:
-      - example.com:8000/https
-      - www.example.com:8000/https
-    environment:
-      API_URL: http://api:3000
-
-  db:
-    image: postgres:18
-    environment:
-      POSTGRES_PASSWORD: ${DB_PASSWORD}
-    volumes:
-      - db-data:/var/lib/postgresql/data
-    x-machines: db-machine
-
-volumes:
-  db-data:
-```
-
----
-
-## Routing to External (Non-Cluster) Devices
-
-To expose an external device (e.g. BMC, NAS, router UI) via Caddy without running a real container:
-
-**1. Create a Caddyfile snippet** (e.g. `~/device.caddyfile`):
-
-```caddyfile
-https://device.example.com {
-    reverse_proxy https://192.168.1.x {
-        transport http {
-            tls_insecure_skip_verify   # needed for self-signed BMC certs
-        }
-    }
-    log
-}
-```
-
-For plaintext upstream: `reverse_proxy http://192.168.1.x:port`
-
-**2. Register as a named service with no-op container:**
-
-```bash
-uc service run \
-  --name device-bmc \
-  --caddyfile ~/device.caddyfile \
-  registry.k8s.io/pause:3.9
-```
-
-`pause` is a minimal no-op container — it does nothing, but gives Uncloud a service entry to attach the Caddyfile to.
-
-**3. Verify:**
-
-```bash
-uc caddy config   # device.example.com block should appear
-```
-
-> `--caddyfile` cannot be combined with non-`@host` published ports.
-
-**DNS tip:** A wildcard record (`*.yourdomain.com → cluster-public-ip`) means any new subdomain works immediately — no DNS change needed per service.
-
----
-
-## Service DNS (Internal)
-
-Services inside the cluster resolve each other by name:
-
-| DNS name | Resolves to |
-|----------|------------|
-| `service-name` | Any healthy container |
-| `service-name.internal` | Same |
-| `rr.service-name.internal` | Round-robin |
-| `nearest.service-name.internal` | Machine-local first |
-
----
-
-## Scaling & Global Services
-
-```bash
-uc scale web 5    # 5 replicas (spread across machines)
-uc scale web 1    # Scale down
-```
-
-```yaml
-services:
-  caddy:
-    deploy:
-      mode: global   # One container on every machine
-```
-
----
-
-## Image Tag Templates (in compose.yaml)
-
-```yaml
-image: myapp:{{gitdate "20060102"}}.{{gitsha 7}}
-image: myapp:{{gitsha 7}}.${GITHUB_RUN_ID:-local}
-```
-
-| Function | Output |
-|----------|--------|
-| `{{gitsha N}}` | First N chars of commit SHA |
-| `{{gitdate "format"}}` | Git commit date in Go format |
-| `{{date "format"}}` | Current date |
-
----
-
-## Common Workflows
-
-**Deploy from source:**
-```bash
-uc deploy                          # Build + push + deploy
-uc build --push && uc deploy --no-build   # Separate steps
-```
-
-**Inspect a service:**
-```bash
-uc inspect web
-uc logs -f web
-uc logs --since 1h web
-uc exec web                        # Opens shell
-uc exec web /bin/sh -c "env"       # Run specific command
-```
-
-**Zero-downtime deploys** happen automatically; Uncloud waits for health checks before terminating old containers.
-
-**Force recreate:**
-```bash
-uc deploy --recreate
-```
-
----
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---------|-----|
-| Editing the Caddyfile directly | Use `x-caddy` in compose or `--caddyfile` on `uc service run` |
-| Proxying an HTTPS upstream with self-signed cert | Add `transport http { tls_insecure_skip_verify }` |
-| `uc caddy config` shows no user-defined blocks | Caddy admin socket unreachable — check `uc inspect caddy` and `uc logs caddy` |
-| Service can't reach external LAN IP from container | Verify Caddy container's host can route to target network |
-| Volumes lost after `uc service rm` | Named volumes persist; only anonymous volumes are auto-removed |

package/prisma/skills/unified-notifications-ops/SKILL.md

@@ -1,188 +0,0 @@
----
-name: unified-notifications-ops
-description: Operate notifications as one ECC-native workflow across GitHub, Linear, desktop alerts, hooks, and connected communication surfaces. Use when the real problem is alert routing, deduplication, escalation, or inbox collapse.
-metadata:
-  origin: ECC
----
-
-# Unified Notifications Ops
-
-Use this skill when the real problem is not a missing ping. The real problem is a fragmented notification system.
-
-The job is to turn scattered events into one operator surface with:
-- clear severity
-- clear ownership
-- clear routing
-- clear follow-up action
-
-## When to Use
-
-- the user wants a unified notification lane across GitHub, Linear, local hooks, desktop alerts, chat, or email
-- CI failures, review requests, issue updates, and operator events are arriving in disconnected places
-- the current setup creates noise instead of action
-- the user wants to consolidate overlapping notification branches or backlog proposals into one ECC-native lane
-- the workspace already has hooks, MCPs, or connected tools, but no coherent notification policy
-
-## Preferred Surface
-
-Start from what already exists:
-- GitHub issues, PRs, reviews, comments, and CI
-- Linear issue/project movement
-- local hook events and session lifecycle signals
-- desktop notification primitives
-- connected email/chat surfaces when they actually exist
-
-Prefer ECC-native orchestration over telling the user to adopt a separate notification product.
-
-## Non-Negotiable Rules
-
-- never expose tokens, secrets, webhook secrets, or internal identifiers
-- separate:
-  - event source
-  - severity
-  - routing channel
-  - operator action
-- default to digest-first when interruption cost is unclear
-- do not fan out every event to every channel
-- if the real fix is better issue triage, hook policy, or project flow, say so explicitly
-
-## Event Pipeline
-
-Treat the lane as:
-
-1. **Capture** the event
-2. **Classify** urgency and owner
-3. **Route** to the correct channel
-4. **Collapse** duplicates and low-signal churn
-5. **Attach** the next operator action
-
-The goal is fewer, better notifications.
-
-## Default Severity Model
-
-| Class | Examples | Default handling |
-| --- | --- | --- |
-| Critical | broken default-branch CI, security issue, blocked release, failed deploy | interrupt now |
-| High | review requested, failing PR, owner-blocking handoff | same-day alert |
-| Medium | issue state changes, notable comments, backlog movement | digest or queue |
-| Low | repeat successes, routine churn, redundant lifecycle markers | suppress or fold |
-
-If the workspace has no severity model, build one before proposing automation.
-
-## Workflow
-
-### 1. Inventory the current surface
-
-List:
-- event sources
-- current channels
-- existing hooks/scripts that emit alerts
-- duplicate paths for the same event
-- silent failure cases where important things are not being surfaced
-
-Call out what ECC already owns.
-
-### 2. Decide what deserves interruption
-
-For each event family, answer:
-- who needs to know?
-- how fast do they need to know?
-- should this interrupt, batch, or just log?
-
-Use these defaults:
-- interrupt for release, CI, security, and owner-blocking events
-- digest for medium-signal updates
-- log-only for telemetry and low-signal lifecycle markers
-
-### 3. Collapse duplicates before adding channels
-
-Look for:
-- the same PR event appearing in GitHub, Linear, and local logs
-- repeated hook notifications for the same failure
-- comments or status churn that should be summarized instead of forwarded raw
-- channels that duplicate each other without adding a better action path
-
-Prefer:
-- one canonical summary
-- one owner
-- one primary channel
-- one fallback path
-
-### 4. Design the ECC-native workflow
-
-For each real notification need, define:
-- **source**
-- **gate**
-- **shape**: immediate alert, digest, queue, or dashboard-only
-- **channel**
-- **action**
-
-If ECC already has the primitive, prefer:
-- a skill for operator triage
-- a hook for automatic emission/enforcement
-- an agent for delegated classification
-- an MCP/connector only when a real bridge is missing
-
-### 5. Return an action-biased design
-
-End with:
-- what to keep
-- what to suppress
-- what to merge
-- what ECC should wrap next
-
-## Output Format
-
-```text
-CURRENT SURFACE
-- sources
-- channels
-- duplicates
-- gaps
-
-EVENT MODEL
-- critical
-- high
-- medium
-- low
-
-ROUTING PLAN
-- source -> channel
-- why
-- operator owner
-
-CONSOLIDATION
-- suppress
-- merge
-- canonical summaries
-
-NEXT ECC MOVE
-- skill / hook / agent / MCP
-- exact workflow to build next
-```
-
-## Recommendation Rules
-
-- prefer one strong lane over many weak ones
-- prefer digests for medium and low-signal updates
-- prefer hooks when the signal should emit automatically
-- prefer operator skills when the work is triage, routing, and review-first decision-making
-- prefer `project-flow-ops` when the root cause is backlog / PR coordination rather than alerts
-- prefer `workspace-surface-audit` when the user first needs a source inventory
-- if desktop notifications are enough, do not invent an unnecessary external bridge
-
-## Good Use Cases
-
-- "We have GitHub, Linear, and local hook alerts, but no single operator flow"
-- "Our CI failures are noisy and people ignore them"
-- "I want one notification policy across Claude, OpenCode, and Codex surfaces"
-- "Figure out what should interrupt versus land in a digest"
-- "Collapse overlapping notification PR ideas into one canonical ECC lane"
-
-## Related Skills
-
-- `workspace-surface-audit`
-- `project-flow-ops`
-- `github-ops`
-- `knowledge-ops`
-- `customer-billing-ops` when the notification pain is billing/customer operations rather than engineering

package/prisma/skills/verification-loop/SKILL.md

@@ -1,127 +0,0 @@
----
-name: verification-loop
-description: "A comprehensive verification system for Claude Code sessions."
-metadata:
-  origin: ECC
----
-
-# Verification Loop Skill
-
-A comprehensive verification system for Claude Code sessions.
-
-## When to Use
-
-Invoke this skill:
-- After completing a feature or significant code change
-- Before creating a PR
-- When you want to ensure quality gates pass
-- After refactoring
-
-## Verification Phases
-
-### Phase 1: Build Verification
-```bash
-# Check if project builds
-npm run build 2>&1 | tail -20
-# OR
-pnpm build 2>&1 | tail -20
-```
-
-If build fails, STOP and fix before continuing.
-
-### Phase 2: Type Check
-```bash
-# TypeScript projects
-npx tsc --noEmit 2>&1 | head -30
-
-# Python projects
-pyright . 2>&1 | head -30
-```
-
-Report all type errors. Fix critical ones before continuing.
-
-### Phase 3: Lint Check
-```bash
-# JavaScript/TypeScript
-npm run lint 2>&1 | head -30
-
-# Python
-ruff check . 2>&1 | head -30
-```
-
-### Phase 4: Test Suite
-```bash
-# Run tests with coverage
-npm run test -- --coverage 2>&1 | tail -50
-
-# Check coverage threshold
-# Target: 80% minimum
-```
-
-Report:
-- Total tests: X
-- Passed: X
-- Failed: X
-- Coverage: X%
-
-### Phase 5: Security Scan
-```bash
-# Check for secrets
-grep -rn "sk-" --include="*.ts" --include="*.js" . 2>/dev/null | head -10
-grep -rn "api_key" --include="*.ts" --include="*.js" . 2>/dev/null | head -10
-
-# Check for console.log
-grep -rn "console.log" --include="*.ts" --include="*.tsx" src/ 2>/dev/null | head -10
-```
-
-### Phase 6: Diff Review
-```bash
-# Show what changed
-git diff --stat
-git diff HEAD~1 --name-only
-```
-
-Review each changed file for:
-- Unintended changes
-- Missing error handling
-- Potential edge cases
-
-## Output Format
-
-After running all phases, produce a verification report:
-
-```
-VERIFICATION REPORT
-==================
-
-Build:     [PASS/FAIL]
-Types:     [PASS/FAIL] (X errors)
-Lint:      [PASS/FAIL] (X warnings)
-Tests:     [PASS/FAIL] (X/Y passed, Z% coverage)
-Security:  [PASS/FAIL] (X issues)
-Diff:      [X files changed]
-
-Overall:   [READY/NOT READY] for PR
-
-Issues to Fix:
-1. ...
-2. ...
-```
-
-## Continuous Mode
-
-For long sessions, run verification every 15 minutes or after major changes:
-
-```markdown
-Set a mental checkpoint:
-- After completing each function
-- After finishing a component
-- Before moving to next task
-
-Run: /verify
-```
-
-## Integration with Hooks
-
-This skill complements PostToolUse hooks but provides deeper verification.
-Hooks catch issues immediately; this skill provides comprehensive review.