agenthub-multiagent-mcp 1.47.0 → 1.48.0

package/skills/skills/deploy-staging/SKILL.md

@@ -1,164 +1,164 @@
----
-name: deploy-staging
-description: Deploy AgentHub to the Contabo staging environment (agenthub.contetial.com) — build the Go server + dashboard, ship them INTO the Dockerized staging container, restart, and verify. Use when asked to deploy/ship/release AgentHub to staging. DESTRUCTIVE — runs real deploy commands against the live staging server.
-license: MIT
----
-
-# Deploy AgentHub to Staging
-
-Deploys the AgentHub Go server and React dashboard to the Contabo staging host.
-This is a **destructive, outward-facing** operation: it restarts the live
-staging service. Run deliberately, verify each step, and stop if anything looks
-wrong.
-
-**Target:** `agenthub.contetial.com` · host `109.123.246.254` · user `root`
-**SSH key:** `~/.ssh/contabo_staging`
-**Runtime:** Dockerized. Container `krishiai-agenthub`, image
-`krishiai-agenthub:staging`. The systemd `agenthub.service` no longer applies.
-
-## How this deployment actually works (read first)
-
-This setup is **not** a host-binary-swap. Verified mechanism:
-
-- The server binary lives **inside the container** at `/opt/agenthub/agenthub`
-  (the host's `/opt/agenthub/agenthub` is a stale leftover and is *not* what
-  runs). The container's filesystem persists across `docker restart`, so you
-  deploy with `docker cp` into the container, then restart.
-- The dashboard is a **Docker named volume** `krishiai_agenthub_dashboard`
-  mounted at `/opt/agenthub/dashboard` (host path
-  `/var/lib/docker/volumes/krishiai_agenthub_dashboard/_data/`). You deploy by
-  writing the SPA build into that volume.
-- The DB is the **`krishiai_agenthub_data`** volume mounted at
-  `/var/lib/agenthub` (`staging.db`). The container runs migrations on boot.
-
-> ⚠️ **Do NOT overwrite KrishiAI-specific server state.** Specifically:
-> - The dashboard volume has a **`docs/` subdir** (platform/intel/org-brain
->   guides) and an `uploads/`/`assets/` layout — **never `rsync --delete`** the
->   volume or you will wipe them. Add/overwrite files only.
-> - **Never touch** the `krishiai_agenthub_data` volume / `staging.db`, the
->   container's env (the entrypoint passes Slack/OAuth/DB flags), or the host's
->   timestamped `agenthub.pre-*` backups.
-> - Don't `docker run`/recreate the container — that drops env + the in-container
->   binary. Use `docker restart` only.
-
-## 0. Preconditions
-
-```bash
-cd server && go test ./... && cd ..
-cd mcp-server && npm run typecheck && cd ..
-
-# SSH reachable + container present; confirm the binary is INSIDE the container.
-ssh -i ~/.ssh/contabo_staging root@109.123.246.254 \
-  "docker ps --format '{{.Names}}' | grep krishiai-agenthub && \
-   docker exec krishiai-agenthub ls -la /opt/agenthub/agenthub"
-```
-
-If the container isn't named `krishiai-agenthub`, stop and reconcile.
-
-## 1. Build the server (Linux binary)
-
-```bash
-cd server
-GOOS=linux GOARCH=amd64 go build -o agenthub-linux ./cmd/agenthub
-cd ..
-```
-
-## 2. Ship + restart the server (docker cp, not host swap)
-
-```bash
-TS=$(date +%Y%m%d-%H%M%S)
-
-# 2a. Snapshot the CURRENT in-container binary to the host (rollback point).
-ssh -i ~/.ssh/contabo_staging root@109.123.246.254 \
-  "docker cp krishiai-agenthub:/opt/agenthub/agenthub /opt/agenthub/agenthub.pre-$TS && \
-   ls -lh /opt/agenthub/agenthub.pre-$TS"
-
-# 2b. Upload the new binary to the host, then copy it INTO the container.
-scp -i ~/.ssh/contabo_staging server/agenthub-linux \
-  root@109.123.246.254:/tmp/agenthub-new
-
-ssh -i ~/.ssh/contabo_staging root@109.123.246.254 '
-  set -e
-  docker cp /tmp/agenthub-new krishiai-agenthub:/opt/agenthub/agenthub
-  # docker cp writes as root; the container runs as the agenthub user, so fix
-  # ownership/perms with an explicit -u 0 exec.
-  docker exec -u 0 krishiai-agenthub chown agenthub:agenthub /opt/agenthub/agenthub
-  docker exec -u 0 krishiai-agenthub chmod 755 /opt/agenthub/agenthub
-  docker restart krishiai-agenthub
-  rm -f /tmp/agenthub-new
-'
-```
-
-Watch migrations (the binary runs them on boot). `failed=` must be 0:
-
-```bash
-ssh -i ~/.ssh/contabo_staging root@109.123.246.254 \
-  "docker logs --tail 120 krishiai-agenthub 2>&1 | grep -E 'migrations complete|failed=|ERROR|panic'"
-```
-
-`worker WebSocket read error ... close 1006` lines right after restart are just
-agents reconnecting — ignore them.
-
-## 3. Build + deploy the dashboard (into the volume, preserving docs/)
-
-```bash
-cd agenthub-dashboard
-npm run build
-cd ..
-
-VOL=/var/lib/docker/volumes/krishiai_agenthub_dashboard/_data
-
-# SPA: overwrite index.html + assets/ ONLY. Do not delete the volume — that
-# would remove the docs/ subdir served at /docs/.
-scp -i ~/.ssh/contabo_staging agenthub-dashboard/dist/index.html root@109.123.246.254:$VOL/index.html
-scp -i ~/.ssh/contabo_staging -r agenthub-dashboard/dist/assets root@109.123.246.254:$VOL/
-
-# Docs guides (only if you changed them): push into the docs/ subdir.
-scp -i ~/.ssh/contabo_staging docs/platform-guide.html docs/intel-layer-guide.html docs/org-brain-guide.html \
-  root@109.123.246.254:$VOL/docs/ 2>/dev/null || true
-```
-
-> The repo's `agenthub-dashboard/deploy.sh` rsyncs to the host path
-> `/opt/agenthub/dashboard` — that path is **not** what the container serves
-> (the volume is). Don't use it as-is; the volume scp above is the live path.
-
-## 4. Verify (from the host — external curl may be blocked from your machine)
-
-```bash
-ssh -i ~/.ssh/contabo_staging root@109.123.246.254 '
-  echo "-- health --";       curl -s --max-time 10 http://127.0.0.1:8787/health; echo
-  echo "-- config --";       curl -s --max-time 10 http://127.0.0.1:8787/api/config/public; echo
-  echo "-- metrics --";      curl -s --max-time 10 http://127.0.0.1:8787/metrics | grep -E "^agenthub_capability_" | head
-  echo "-- nginx https --";  curl -sk --max-time 10 https://localhost/health; echo
-'
-```
-
-Optional DB smoke (catalog + new columns landed):
-
-```bash
-ssh -i ~/.ssh/contabo_staging root@109.123.246.254 \
-  "docker exec krishiai-agenthub sqlite3 /var/lib/agenthub/staging.db \
-   'SELECT count(*) FROM capabilities WHERE deprecated_at IS NULL;'"
-```
-
-## 5. Rollback (if needed)
-
-```bash
-ssh -i ~/.ssh/contabo_staging root@109.123.246.254 '
-  set -e
-  BK=$(ls -t /opt/agenthub/agenthub.pre-* | head -1)
-  docker cp "$BK" krishiai-agenthub:/opt/agenthub/agenthub
-  docker exec -u 0 krishiai-agenthub chown agenthub:agenthub /opt/agenthub/agenthub
-  docker exec -u 0 krishiai-agenthub chmod 755 /opt/agenthub/agenthub
-  docker restart krishiai-agenthub
-'
-```
-
-Then re-deploy the previous dashboard build (checkout the prior commit, rebuild,
-re-run step 3).
-
-## Done
-
-Report: which commit shipped, migration outcome (`applied/failed`), and the
-verification results. If anything failed mid-way, say exactly which step and
-leave the system in a known state (rolled back or clearly flagged).
+---
+name: deploy-staging
+description: Deploy AgentHub to the Contabo staging environment (agenthub.contetial.com) — build the Go server + dashboard, ship them INTO the Dockerized staging container, restart, and verify. Use when asked to deploy/ship/release AgentHub to staging. DESTRUCTIVE — runs real deploy commands against the live staging server.
+license: MIT
+---
+
+# Deploy AgentHub to Staging
+
+Deploys the AgentHub Go server and React dashboard to the Contabo staging host.
+This is a **destructive, outward-facing** operation: it restarts the live
+staging service. Run deliberately, verify each step, and stop if anything looks
+wrong.
+
+**Target:** `agenthub.contetial.com` · host `109.123.246.254` · user `root`
+**SSH key:** `~/.ssh/contabo_staging`
+**Runtime:** Dockerized. Container `krishiai-agenthub`, image
+`krishiai-agenthub:staging`. The systemd `agenthub.service` no longer applies.
+
+## How this deployment actually works (read first)
+
+This setup is **not** a host-binary-swap. Verified mechanism:
+
+- The server binary lives **inside the container** at `/opt/agenthub/agenthub`
+  (the host's `/opt/agenthub/agenthub` is a stale leftover and is *not* what
+  runs). The container's filesystem persists across `docker restart`, so you
+  deploy with `docker cp` into the container, then restart.
+- The dashboard is a **Docker named volume** `krishiai_agenthub_dashboard`
+  mounted at `/opt/agenthub/dashboard` (host path
+  `/var/lib/docker/volumes/krishiai_agenthub_dashboard/_data/`). You deploy by
+  writing the SPA build into that volume.
+- The DB is the **`krishiai_agenthub_data`** volume mounted at
+  `/var/lib/agenthub` (`staging.db`). The container runs migrations on boot.
+
+> ⚠️ **Do NOT overwrite KrishiAI-specific server state.** Specifically:
+> - The dashboard volume has a **`docs/` subdir** (platform/intel/org-brain
+>   guides) and an `uploads/`/`assets/` layout — **never `rsync --delete`** the
+>   volume or you will wipe them. Add/overwrite files only.
+> - **Never touch** the `krishiai_agenthub_data` volume / `staging.db`, the
+>   container's env (the entrypoint passes Slack/OAuth/DB flags), or the host's
+>   timestamped `agenthub.pre-*` backups.
+> - Don't `docker run`/recreate the container — that drops env + the in-container
+>   binary. Use `docker restart` only.
+
+## 0. Preconditions
+
+```bash
+cd server && go test ./... && cd ..
+cd mcp-server && npm run typecheck && cd ..
+
+# SSH reachable + container present; confirm the binary is INSIDE the container.
+ssh -i ~/.ssh/contabo_staging root@109.123.246.254 \
+  "docker ps --format '{{.Names}}' | grep krishiai-agenthub && \
+   docker exec krishiai-agenthub ls -la /opt/agenthub/agenthub"
+```
+
+If the container isn't named `krishiai-agenthub`, stop and reconcile.
+
+## 1. Build the server (Linux binary)
+
+```bash
+cd server
+GOOS=linux GOARCH=amd64 go build -o agenthub-linux ./cmd/agenthub
+cd ..
+```
+
+## 2. Ship + restart the server (docker cp, not host swap)
+
+```bash
+TS=$(date +%Y%m%d-%H%M%S)
+
+# 2a. Snapshot the CURRENT in-container binary to the host (rollback point).
+ssh -i ~/.ssh/contabo_staging root@109.123.246.254 \
+  "docker cp krishiai-agenthub:/opt/agenthub/agenthub /opt/agenthub/agenthub.pre-$TS && \
+   ls -lh /opt/agenthub/agenthub.pre-$TS"
+
+# 2b. Upload the new binary to the host, then copy it INTO the container.
+scp -i ~/.ssh/contabo_staging server/agenthub-linux \
+  root@109.123.246.254:/tmp/agenthub-new
+
+ssh -i ~/.ssh/contabo_staging root@109.123.246.254 '
+  set -e
+  docker cp /tmp/agenthub-new krishiai-agenthub:/opt/agenthub/agenthub
+  # docker cp writes as root; the container runs as the agenthub user, so fix
+  # ownership/perms with an explicit -u 0 exec.
+  docker exec -u 0 krishiai-agenthub chown agenthub:agenthub /opt/agenthub/agenthub
+  docker exec -u 0 krishiai-agenthub chmod 755 /opt/agenthub/agenthub
+  docker restart krishiai-agenthub
+  rm -f /tmp/agenthub-new
+'
+```
+
+Watch migrations (the binary runs them on boot). `failed=` must be 0:
+
+```bash
+ssh -i ~/.ssh/contabo_staging root@109.123.246.254 \
+  "docker logs --tail 120 krishiai-agenthub 2>&1 | grep -E 'migrations complete|failed=|ERROR|panic'"
+```
+
+`worker WebSocket read error ... close 1006` lines right after restart are just
+agents reconnecting — ignore them.
+
+## 3. Build + deploy the dashboard (into the volume, preserving docs/)
+
+```bash
+cd agenthub-dashboard
+npm run build
+cd ..
+
+VOL=/var/lib/docker/volumes/krishiai_agenthub_dashboard/_data
+
+# SPA: overwrite index.html + assets/ ONLY. Do not delete the volume — that
+# would remove the docs/ subdir served at /docs/.
+scp -i ~/.ssh/contabo_staging agenthub-dashboard/dist/index.html root@109.123.246.254:$VOL/index.html
+scp -i ~/.ssh/contabo_staging -r agenthub-dashboard/dist/assets root@109.123.246.254:$VOL/
+
+# Docs guides (only if you changed them): push into the docs/ subdir.
+scp -i ~/.ssh/contabo_staging docs/platform-guide.html docs/intel-layer-guide.html docs/org-brain-guide.html \
+  root@109.123.246.254:$VOL/docs/ 2>/dev/null || true
+```
+
+> The repo's `agenthub-dashboard/deploy.sh` rsyncs to the host path
+> `/opt/agenthub/dashboard` — that path is **not** what the container serves
+> (the volume is). Don't use it as-is; the volume scp above is the live path.
+
+## 4. Verify (from the host — external curl may be blocked from your machine)
+
+```bash
+ssh -i ~/.ssh/contabo_staging root@109.123.246.254 '
+  echo "-- health --";       curl -s --max-time 10 http://127.0.0.1:8787/health; echo
+  echo "-- config --";       curl -s --max-time 10 http://127.0.0.1:8787/api/config/public; echo
+  echo "-- metrics --";      curl -s --max-time 10 http://127.0.0.1:8787/metrics | grep -E "^agenthub_capability_" | head
+  echo "-- nginx https --";  curl -sk --max-time 10 https://localhost/health; echo
+'
+```
+
+Optional DB smoke (catalog + new columns landed):
+
+```bash
+ssh -i ~/.ssh/contabo_staging root@109.123.246.254 \
+  "docker exec krishiai-agenthub sqlite3 /var/lib/agenthub/staging.db \
+   'SELECT count(*) FROM capabilities WHERE deprecated_at IS NULL;'"
+```
+
+## 5. Rollback (if needed)
+
+```bash
+ssh -i ~/.ssh/contabo_staging root@109.123.246.254 '
+  set -e
+  BK=$(ls -t /opt/agenthub/agenthub.pre-* | head -1)
+  docker cp "$BK" krishiai-agenthub:/opt/agenthub/agenthub
+  docker exec -u 0 krishiai-agenthub chown agenthub:agenthub /opt/agenthub/agenthub
+  docker exec -u 0 krishiai-agenthub chmod 755 /opt/agenthub/agenthub
+  docker restart krishiai-agenthub
+'
+```
+
+Then re-deploy the previous dashboard build (checkout the prior commit, rebuild,
+re-run step 3).
+
+## Done
+
+Report: which commit shipped, migration outcome (`applied/failed`), and the
+verification results. If anything failed mid-way, say exactly which step and
+leave the system in a known state (rolled back or clearly flagged).

package/skills/skills/deploy-vps-openclaw/SKILL.md

@@ -1,97 +1,97 @@
----
-name: deploy-vps-openclaw
-description: Deploy the AgentHub meta-agent OpenClaw plugin to the Hetzner VPS — build the plugin, ship it to /root/.openclaw/extensions, restart the OpenClaw gateway, and verify. Use when asked to deploy/ship the meta-agent or OpenClaw plugin. DESTRUCTIVE — restarts the live gateway on the VPS.
-license: MIT
----
-
-# Deploy the OpenClaw Meta-Agent to the Hetzner VPS
-
-Deploys the AgentHub meta-agent plugin to the OpenClaw gateway on the Hetzner
-VPS. This is a **destructive, outward-facing** operation: it restarts the live
-gateway, which briefly drops the meta-agent's monitoring + Slack reporting. Run
-deliberately and verify.
-
-**Target:** Hetzner VPS `178.104.62.122` · user `root`
-**SSH key:** `~/.ssh/id_openclaw`
-**Plugin dir:** `/root/.openclaw/extensions/agenthub-meta-agent`
-**State file:** `/root/.openclaw/state/meta-agent.json` (persists the connect
-token; survives restarts so the gateway reconnects instead of 409-deadlocking).
-
-> Authoritative script this runbook drives: `meta-agent/scripts/deploy-meta-agent.sh`.
-> Prefer running that script directly; the manual steps below mirror it for when
-> you need to deploy step-by-step or the script is unavailable.
-
-## 0. Ordering — server first, plugin second
-
-If this release also includes an AgentHub **server** change, deploy the server
-first (see the `deploy-staging` skill). The plugin's 409 fallback calls
-`POST /api/agents/{id}/replace_token`, which must exist server-side. A plugin
-against an older server degrades to manual recovery rather than failing hard,
-but the design assumes the endpoint is present.
-
-## 1. Deploy via the maintained script (preferred)
-
-```bash
-cd meta-agent
-./scripts/deploy-meta-agent.sh
-```
-
-That script builds the plugin (`npm run build`), uploads
-`openclaw.plugin.json`, `package.json`, and `dist/` to the plugin dir, restarts
-`openclaw-gateway`, and prints whether the service came back active.
-
-## 2. Manual steps (if running step-by-step)
-
-```bash
-cd meta-agent
-npm run build
-
-VPS=root@178.104.62.122
-KEY=~/.ssh/id_openclaw
-DIR=/root/.openclaw/extensions/agenthub-meta-agent
-
-ssh -i $KEY $VPS "mkdir -p $DIR/dist/src"
-scp -i $KEY openclaw.plugin.json package.json $VPS:$DIR/
-scp -i $KEY dist/index.js $VPS:$DIR/dist/
-scp -i $KEY dist/index.js.map $VPS:$DIR/dist/ 2>/dev/null || true
-scp -i $KEY -r dist/src/ $VPS:$DIR/dist/src/
-
-ssh -i $KEY $VPS "systemctl restart openclaw-gateway"
-```
-
-## 3. Verify
-
-```bash
-KEY=~/.ssh/id_openclaw; VPS=root@178.104.62.122
-# Gateway is active.
-ssh -i $KEY $VPS "systemctl is-active openclaw-gateway"
-# Plugin reconnected (look for the lifecycle-path line).
-ssh -i $KEY $VPS "journalctl -u openclaw-gateway -n 60 --no-pager | grep -iE 'meta-agent|lifecycle-path|reconnect'"
-```
-
-Expected lifecycle path on a healthy restart: `reconnect-from-disk` (it read the
-persisted connect token). `register-fresh` or `409-replace-token` are also
-valid; a stuck `409` deadlock means the state file was lost — see the recovery
-runbook in `docs/meta-agent.md`.
-
-Confirm in AgentHub that `meta-agent` is online (dashboard agents list) and
-that it resumes posting to `#agenthub-digest` / `#agenthub-alerts` on schedule.
-
-## 4. Rollback (if needed)
-
-Redeploy the previous build:
-
-```bash
-cd meta-agent && git checkout <previous-commit> -- . && npm run build && ./scripts/deploy-meta-agent.sh
-```
-
-If the gateway won't come back, check `journalctl -u openclaw-gateway` for plugin
-load errors and, if needed, disable the plugin (`enabled: false` in
-`openclaw.json` under `plugins.entries.agenthub-meta-agent`) then restart to
-restore the gateway without the meta-agent.
-
-## Done
-
-Report: which commit shipped, the lifecycle-path line from the logs, gateway
-active state, and whether the meta-agent re-appears online in AgentHub. If the
-restart failed, say so and leave the gateway in a known state.
+---
+name: deploy-vps-openclaw
+description: Deploy the AgentHub meta-agent OpenClaw plugin to the Hetzner VPS — build the plugin, ship it to /root/.openclaw/extensions, restart the OpenClaw gateway, and verify. Use when asked to deploy/ship the meta-agent or OpenClaw plugin. DESTRUCTIVE — restarts the live gateway on the VPS.
+license: MIT
+---
+
+# Deploy the OpenClaw Meta-Agent to the Hetzner VPS
+
+Deploys the AgentHub meta-agent plugin to the OpenClaw gateway on the Hetzner
+VPS. This is a **destructive, outward-facing** operation: it restarts the live
+gateway, which briefly drops the meta-agent's monitoring + Slack reporting. Run
+deliberately and verify.
+
+**Target:** Hetzner VPS `178.104.62.122` · user `root`
+**SSH key:** `~/.ssh/id_openclaw`
+**Plugin dir:** `/root/.openclaw/extensions/agenthub-meta-agent`
+**State file:** `/root/.openclaw/state/meta-agent.json` (persists the connect
+token; survives restarts so the gateway reconnects instead of 409-deadlocking).
+
+> Authoritative script this runbook drives: `meta-agent/scripts/deploy-meta-agent.sh`.
+> Prefer running that script directly; the manual steps below mirror it for when
+> you need to deploy step-by-step or the script is unavailable.
+
+## 0. Ordering — server first, plugin second
+
+If this release also includes an AgentHub **server** change, deploy the server
+first (see the `deploy-staging` skill). The plugin's 409 fallback calls
+`POST /api/agents/{id}/replace_token`, which must exist server-side. A plugin
+against an older server degrades to manual recovery rather than failing hard,
+but the design assumes the endpoint is present.
+
+## 1. Deploy via the maintained script (preferred)
+
+```bash
+cd meta-agent
+./scripts/deploy-meta-agent.sh
+```
+
+That script builds the plugin (`npm run build`), uploads
+`openclaw.plugin.json`, `package.json`, and `dist/` to the plugin dir, restarts
+`openclaw-gateway`, and prints whether the service came back active.
+
+## 2. Manual steps (if running step-by-step)
+
+```bash
+cd meta-agent
+npm run build
+
+VPS=root@178.104.62.122
+KEY=~/.ssh/id_openclaw
+DIR=/root/.openclaw/extensions/agenthub-meta-agent
+
+ssh -i $KEY $VPS "mkdir -p $DIR/dist/src"
+scp -i $KEY openclaw.plugin.json package.json $VPS:$DIR/
+scp -i $KEY dist/index.js $VPS:$DIR/dist/
+scp -i $KEY dist/index.js.map $VPS:$DIR/dist/ 2>/dev/null || true
+scp -i $KEY -r dist/src/ $VPS:$DIR/dist/src/
+
+ssh -i $KEY $VPS "systemctl restart openclaw-gateway"
+```
+
+## 3. Verify
+
+```bash
+KEY=~/.ssh/id_openclaw; VPS=root@178.104.62.122
+# Gateway is active.
+ssh -i $KEY $VPS "systemctl is-active openclaw-gateway"
+# Plugin reconnected (look for the lifecycle-path line).
+ssh -i $KEY $VPS "journalctl -u openclaw-gateway -n 60 --no-pager | grep -iE 'meta-agent|lifecycle-path|reconnect'"
+```
+
+Expected lifecycle path on a healthy restart: `reconnect-from-disk` (it read the
+persisted connect token). `register-fresh` or `409-replace-token` are also
+valid; a stuck `409` deadlock means the state file was lost — see the recovery
+runbook in `docs/meta-agent.md`.
+
+Confirm in AgentHub that `meta-agent` is online (dashboard agents list) and
+that it resumes posting to `#agenthub-digest` / `#agenthub-alerts` on schedule.
+
+## 4. Rollback (if needed)
+
+Redeploy the previous build:
+
+```bash
+cd meta-agent && git checkout <previous-commit> -- . && npm run build && ./scripts/deploy-meta-agent.sh
+```
+
+If the gateway won't come back, check `journalctl -u openclaw-gateway` for plugin
+load errors and, if needed, disable the plugin (`enabled: false` in
+`openclaw.json` under `plugins.entries.agenthub-meta-agent`) then restart to
+restore the gateway without the meta-agent.
+
+## Done
+
+Report: which commit shipped, the lifecycle-path line from the logs, gateway
+active state, and whether the meta-agent re-appears online in AgentHub. If the
+restart failed, say so and leave the gateway in a known state.

package/skills/skills/karpathy-guidelines/SKILL.md

@@ -1,67 +1,67 @@
----
-name: karpathy-guidelines
-description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
-license: MIT
----
-
-# Karpathy Guidelines
-
-Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
-
-**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
-
-## 1. Think Before Coding
-
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
-
-Before implementing:
-- State your assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them - don't pick silently.
-- If a simpler approach exists, say so. Push back when warranted.
-- If something is unclear, stop. Name what's confusing. Ask.
-
-## 2. Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios.
-- If you write 200 lines and it could be 50, rewrite it.
-
-Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
-
-## 3. Surgical Changes
-
-**Touch only what you must. Clean up only your own mess.**
-
-When editing existing code:
-- Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it - don't delete it.
-
-When your changes create orphans:
-- Remove imports/variables/functions that YOUR changes made unused.
-- Don't remove pre-existing dead code unless asked.
-
-The test: Every changed line should trace directly to the user's request.
-
-## 4. Goal-Driven Execution
-
-**Define success criteria. Loop until verified.**
-
-Transform tasks into verifiable goals:
-- "Add validation" → "Write tests for invalid inputs, then make them pass"
-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
-- "Refactor X" → "Ensure tests pass before and after"
-
-For multi-step tasks, state a brief plan:
-```
-1. [Step] → verify: [check]
-2. [Step] → verify: [check]
-3. [Step] → verify: [check]
-```
-
-Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
+---
+name: karpathy-guidelines
+description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
+license: MIT
+---
+
+# Karpathy Guidelines
+
+Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them - don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+## 3. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it - don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+The test: Every changed line should trace directly to the user's request.
+
+## 4. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.