chore: move agent routing to OpenCode Go; add firstmate tooling

- crew-dispatch.json: route crew tasks to OpenCode Go models - opencode/opencode2: pin opencode-go/gpt-6-luna - grok: default to grok-4.5 with high reasoning, permission auto - home.nix: axiTools activation for the *-axi CLIs; crewmate harness opencode; no-mistakes agent list opencode-only
Manage opencode 1.x config via home-manager and isolate opencode2
2026-09-27 21:30:11 -04:00 · 2026-09-21 21:55:00 -04:00
12 changed files with 1027 additions and 27 deletions
@@ -46,7 +46,7 @@ in
      cc = "claude --dangerously-skip-permissions";
      co = "codex --full-auto";
      gb = "grok --yolo";
-      # firstmate primary session via OpenCode 2 (isolated config; crewmates = Pi)
+      # firstmate primary session via OpenCode 2 (isolated config; crewmates = OpenCode)
      fm = "cd ${firstmateHome} && exec ${home}/.local/bin/oc2";
      oc2 = "${home}/.local/bin/oc2";
      # Sync ~/Music into the beets library on Unraid (requires NAS mounted).
@@ -111,6 +111,14 @@ in
    source = config.lib.file.mkOutOfStoreSymlink "${dotfiles}/home/AGENTS.md";
    force = true;
  };
+  home.file.".config/opencode/opencode.json" = {
+    source = config.lib.file.mkOutOfStoreSymlink "${dotfiles}/home/.config/opencode/opencode.json";
+    force = true;
+  };
+  home.file.".config/opencode/skills" = {
+    source = config.lib.file.mkOutOfStoreSymlink "${dotfiles}/home/.config/opencode/skills";
+    force = true;
+  };
  # OpenCode 2 isolated config - never share ~/.config/opencode with 1.x
  home.file.".config/opencode2/opencode.json" = {
    source = config.lib.file.mkOutOfStoreSymlink "${dotfiles}/home/.config/opencode2/opencode.json";
@@ -162,10 +170,10 @@ in
  };

  # firstmate is a mutable agent distro (self-update, state/, projects/). Clone once;
-  # never put it in the Nix store. Seed Pi+herdr defaults only when absent.
+  # never put it in the Nix store. Seed OpenCode+herdr defaults only when absent.
  # Do NOT npm install -g here: activation PATH often resolves Nix's npm, which
-  # cannot write into the store (EACCES). Use Homebrew's node for globals:
-  #   /opt/homebrew/bin/npm install -g tasks-axi quota-axi no-mistakes gh-axi lavish-axi chrome-devtools-axi
+  # cannot write into the store (EACCES). The firstmate companion CLIs (*-axi)
+  # are installed by home.activation.axiTools below via Homebrew's node.
  home.activation.firstmate = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
    set -euo pipefail
    fm="${firstmateHome}"
@@ -180,11 +188,11 @@ in

    # Local gitignored operating choices (do not overwrite captain edits)
    [ -f "$fm/config/backend" ] || printf 'herdr\n' > "$fm/config/backend"
-    [ -f "$fm/config/crew-harness" ] || printf 'pi\n' > "$fm/config/crew-harness"
+    [ -f "$fm/config/crew-harness" ] || printf 'opencode\n' > "$fm/config/crew-harness"

    # Crew dispatch profile - source of truth in dotfiles (reproducible across
    # machines). Symlinked into firstmate config so a rebuild restores routing.
-    # Crewmates run on Pi + opencode-go/mimo-v2.5-pro (see crew-dispatch.json).
+    # Crew harness and model routing are task-specific in crew-dispatch.json.
    ln -sfn "${dotfiles}/home/.config/firstmate/crew-dispatch.json" "$fm/config/crew-dispatch.json"

    # Gitea PR helper for local-only mode: after the first mate (opencode)
@@ -192,6 +200,33 @@ in
    ln -sfn "${dotfiles}/home/bin/fm-gitea-pr.sh" "$HOME/.local/bin/fm-gitea-pr.sh"
  '';

+  # Firstmate companion CLIs (*-axi). None is a Homebrew or Nix formula, so
+  # install them through Homebrew's npm. tasks-axi is version-gated by firstmate
+  # (>= 0.2.6 is required before a spawn/teardown automatic backlog transition
+  # will run), so pin it and reinstall on drift; the rest install when absent.
+  home.activation.axiTools = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
+    set -euo pipefail
+    # Activation PATH lacks /opt/homebrew/bin, so npm's `#!/usr/bin/env node`
+    # shebang and the installed shims would fail. Prepend only - replacing PATH
+    # breaks the rest of the HM activation (nix-env, gettext).
+    export PATH="/opt/homebrew/bin:$PATH"
+    npm=/opt/homebrew/bin/npm
+    if [ ! -x "$npm" ]; then
+      echo "axiTools: /opt/homebrew/bin/npm missing (declare node in homebrew.brews)" >&2
+      exit 1
+    fi
+    # Pin tasks-axi; reinstall only when the installed version differs.
+    want_tasks_axi="0.2.6"
+    have_tasks_axi="$(tasks-axi --version 2>/dev/null | head -1 | tr -d '[:space:]')"
+    if [ "$have_tasks_axi" != "$want_tasks_axi" ]; then
+      "$npm" install -g "tasks-axi@$want_tasks_axi"
+    fi
+    # Companion CLIs without a firstmate-enforced version floor: install once.
+    for tool in quota-axi gh-axi lavish-axi chrome-devtools-axi; do
+      [ -x "/opt/homebrew/bin/$tool" ] || "$npm" install -g "$tool"
+    done
+  '';
+
  # Authorize the SSH key so the phone can log in through the ngrok tunnel.
  # (home-manager 26.05 removed programs.ssh.authorizedKeys; manage the file
  # here so ~/.ssh is 0700 and authorized_keys is 0600. Public key is not a secret.)
@@ -228,9 +263,38 @@ in
    "$npm" install -g --allow-scripts=@opencode-ai/cli @opencode-ai/cli@beta
  '';

+  # backpass (kunchenguid/backpass) - gradient descent for agent memory: reads
+  # the transcript stores of the harnesses this config already declares
+  # (claude/codex/pi/opencode/grok), proposes evidence-backed edits to AGENTS.md
+  # and skills, gated by `backpass apply`. Every model call goes through `acpx`
+  # to a harness you already authenticated, so acpx is a hard runtime dep and
+  # must be on PATH. Homebrew node v26 satisfies backpass (>= 22.5) and acpx
+  # (>= 22.13). Neither is a Homebrew formula: install via Homebrew's npm,
+  # never Nix's npm (EACCES on the store). Skip-if-present like opencode2 so a
+  # rebuild never pulls a new version mid-session; refresh manually with
+  #   /opt/homebrew/bin/npm update -g backpass acpx
+  home.activation.backpass = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
+    set -euo pipefail
+    # Activation PATH lacks /opt/homebrew/bin, so npm's `#!/usr/bin/env node`
+    # shebang fails with "env: node: No such file or directory". Prepend only -
+    # replacing PATH breaks the rest of the HM activation (nix-env, gettext).
+    export PATH="/opt/homebrew/bin:$PATH"
+    npm=/opt/homebrew/bin/npm
+    if [ ! -x "$npm" ]; then
+      echo "backpass: /opt/homebrew/bin/npm missing (declare node in homebrew.brews)" >&2
+      exit 1
+    fi
+    if [ ! -x /opt/homebrew/bin/acpx ]; then
+      "$npm" install -g acpx@latest
+    fi
+    if [ ! -x /opt/homebrew/bin/backpass ]; then
+      "$npm" install -g backpass
+    fi
+  '';
+
  # kunchenguid/no-mistakes gate (git push no-mistakes) - declarative install + daemon + global config
-  # Covers every harness declared in Nix: pi (pi-coding-agent), opencode (oc2/fm), grok (grok-build),
-  # plus claude/codex aspirational (aliases cc/co). Binary lives in ~/.no-mistakes/bin
+  # Uses OpenCode only for pipeline steps (the opencode-go subscription), by the
+  # captain's decision. Binary lives in ~/.no-mistakes/bin
  # with symlink ~/.local/bin/no-mistakes (installer default). Do NOT npm install -g no-mistakes
  # - that npm name is jonathanong's static-analysis tool (shadowing bug fixed 2026-09-21).
  home.activation.noMistakes = lib.hm.dag.entryAfter [ "writeBoundary" ] ''
@@ -244,14 +308,14 @@ in
      fi
      curl -fsSL https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/install.sh | sh
    fi
-    # Ensure global config covers all Nix harnesses (idempotent - only writes if missing or still `agent: auto`)
+    # Ensure global config selects OpenCode (idempotent - only writes if missing or still `agent: auto`)
    cfg="$HOME/.no-mistakes/config.yaml"
    if [ -f "$cfg" ] && grep -qE '^\s*agent:\s*auto\s*$' "$cfg"; then
      tmp="$(mktemp)"
      awk '
        /^\s*agent:\s*auto\s*$/ {
          print "# Managed by dotfiles/home.nix home.activation.noMistakes";
-          print "agent: [pi, opencode, grok, claude, codex]";
+          print "agent: [opencode]";
          next
        }
        { print }
@@ -259,10 +323,9 @@ in
    fi
    if [ ! -f "$cfg" ]; then
      mkdir -p "$(dirname "$cfg")"
-      printf 'agent: [pi, opencode, grok, claude, codex]\n' > "$cfg"
+      printf 'agent: [opencode]\n' > "$cfg"
    fi
    # Ensure daemon running (launchd on macOS)
    "$bin" daemon restart >/dev/null 2>&1 || "$bin" daemon start >/dev/null 2>&1 || true
  '';
 }
-
@@ -1,20 +1,20 @@
 {
  "rules": [
    {
-      "when": "pure-function implementation with tests (indicators, slots, seasonal wiring, repositories)",
-      "use": [{ "harness": "pi", "model": "opencode-go/mimo-v2.5-pro" }],
-      "why": "MiMo V2.5 Pro (opencode-go, 1M ctx) produces clean correct code; flat-rate sub so $0 marginal cost. Pi drives it in an isolated worktree."
+      "when": "Well-specified implementation with clear acceptance criteria: pure functions, tests, repositories, adapters, or external-fetch integration.",
+      "use": [{ "harness": "opencode", "model": "opencode-go/deepseek-v4.1-flash", "provider": "opencode-go" }],
+      "why": "DeepSeek V4.1 Flash is the default OpenCode Go implementation worker; it is fast, economical, and strong on agentic coding tasks."
    },
    {
-      "when": "adapter or external-fetch integration (COT, seed backfills, vendor seams)",
-      "use": [{ "harness": "pi", "model": "opencode-go/mimo-v2.5-pro" }],
-      "why": "Pattern-following work against existing adapter contracts; MiMo handles iterative fetch/debug loops."
+      "when": "UI work where supplied screenshots or other image context materially affect the implementation or verification.",
+      "use": [{ "harness": "opencode", "model": "opencode-go/glm-5.3-flash", "provider": "opencode-go" }],
+      "why": "GLM-5.3-Flash is the Go worker with image input; use it when visual context matters."
    },
    {
-      "when": "frontend page or tRPC wiring (UI panels, router procedures, client exposure)",
-      "use": [{ "harness": "pi", "model": "opencode-go/mimo-v2.5-pro" }],
-      "why": "Mechanical wiring against existing components/routers; the contract carries the specialization."
+      "when": "Ambiguous investigation, difficult debugging, architectural tradeoffs, or broad changes with high uncertainty or blast radius.",
+      "use": [{ "harness": "opencode", "model": "opencode-go/gpt-6-luna", "provider": "opencode-go" }],
+      "why": "Reserve GPT-6 Luna for work that benefits from stronger reasoning than the fast implementation tier."
    }
  ],
-  "default": [{ "harness": "pi", "model": "opencode-go/mimo-v2.5-pro" }]
-}
+  "default": [{ "harness": "opencode", "model": "opencode-go/deepseek-v4.1-flash", "provider": "opencode-go" }]
+}
@@ -0,0 +1,33 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "model": "opencode-go/gpt-6-luna",
+  "instructions": ["AGENTS.md"],
+  "provider": {
+    "omlx": {
+      "npm": "@ai-sdk/openai-compatible",
+      "name": "oMLX (Local)",
+      "options": {
+        "baseURL": "http://localhost:8000/v1",
+        "apiKey": "none"
+      },
+      "models": {
+        "qwen3.6-35b": {
+          "id": "Jundot/Qwen3.6-35B-A3B-oQ4-mtp",
+          "name": "Qwen 3.6 35B (o4-mtp)",
+          "tool_call": true,
+          "limit": {
+            "context": 65536,
+            "output": 65536
+          }
+        }
+      }
+    }
+  },
+  "plugin": ["/Users/laptran/.automaton/plugins/automaton-guard"],
+  "command": {
+    "no-mistakes": {
+      "description": "Validate code changes through the no-mistakes pipeline",
+      "template": "Read $HOME/.config/opencode/skills/no-mistakes/SKILL.md and follow it. User request: {{args}}"
+    }
+  }
+}
@@ -0,0 +1,150 @@
+---
+name: cloud-deploy-cli
+description: Use when the user asks to deploy a project, create/manage a cloud deployment, roll back a release, tail production logs, or run a cloud command for Railway, Vercel, AWS, Azure, or Google Cloud. Triggers on keywords like "deploy", "railway up", "vercel deploy", "aws cli", "az ", "gcloud", "ship it", "push to prod", "cloud CLI", "rollback". Installs and drives the cloud provider's CLI so the agent can deploy on its own.
+---
+
+# Cloud deployment CLIs — let the agent deploy on its own
+
+The agent should run the deploy command itself, not hand the user a link to a web console. Pick the CLI for the user's cloud and run it.
+
+## Pick the CLI by what the user named
+
+| Cloud | CLI binary | Install (macOS) | Install (other) |
+|---|---|---|---|
+| Railway | `railway` | `brew install railway` / `npm i -g @railway/cli` | `sh -c "$(curl -fsSL cli.railway.app/install.sh)"` |
+| Vercel | `vercel` | `npm i -g vercel` | same |
+| AWS | `aws` | `brew install awscli` | `pip install awscli` / `winget install Amazon.AWSCLI` |
+| Azure | `az` | `brew install azure-cli` | `winget install Microsoft.AzureCLI` / `curl -sL https://aka.ms/InstallAzureCLIDeb \| sudo bash` |
+| Google Cloud | `gcloud` | `brew install --cask google-cloud-sdk` | `winget install Google.CloudSDK` / install from cloud.google.com/sdk |
+
+If the user said "deploy" without naming a cloud, ask which one (use the `question` tool) — or infer from repo files: `vercel.json` → Vercel, `railway.toml`/`Railway.json` → Railway, `appspec.yml`/`.ebextensions` → AWS, `azure-pipelines.yml`/`appservice` → Azure, `app.yaml`/`Dockerfile`+GCP files → GCP.
+
+Verify install: `<cli> --version`. If missing, install it (table above) then continue.
+
+## Authenticate (one-time per CLI)
+
+```bash
+railway login            # browser login
+vercel login             # browser login (vercel link on first deploy in a repo)
+aws configure            # prompts for Access Key ID, Secret, region, output
+az login                 # browser login
+gcloud auth login        # browser login; then gcloud config set project <PROJECT_ID>
+```
+
+For headless/agent runs use env vars instead of interactive login:
+
+| CLI | Env vars |
+|---|---|
+| Railway | `RAILWAY_TOKEN` (from Railway dashboard → Settings → API Tokens) |
+| Vercel | `VERCEL_TOKEN` (or `VERCEL_ORG_ID` + `VERCEL_PROJECT_ID` after `vercel link`) |
+| AWS | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_REGION` (or `AWS_PROFILE`) |
+| Azure | `az login --service-principal -u <app-id> -p <cert/password> --tenant <tenant>` |
+| Google | `gcloud auth activate-service-account --key-file=<sa.json>` then `GOOGLE_APPLICATION_CREDENTIALS=<sa.json>` |
+
+## Railway
+
+```bash
+railway link             # bind cwd to a Railway project/service
+railway up               # deploy current directory (detected buildpack or Dockerfile)
+railway up --service api # deploy to a specific service
+railway status           # current deployment, URL
+railway logs             # tail live logs
+railway variables        # view env vars (railway variables set KEY=val to add)
+railway rollback         # revert to the previous deployment
+```
+
+## Vercel
+
+```bash
+vercel link              # bind repo (writes .vercel/ with org + project IDs)
+vercel                   # preview deploy; prints a *.vercel.app URL
+vercel --prod            # production deploy (uses production domain)
+vercel logs <url>        # tail function/build logs
+vercel env ls            # vercel env add KEY (then vercel --prod to redeploy)
+vercel rm <url>          # remove a deployment
+vercel inspect <url>     # build/runtime details
+```
+
+For a fully scripted agent deploy:
+
+```bash
+vercel --prod --yes --token "$VERCEL_TOKEN"
+# --yes skips all prompts; requires .vercel/ linked (vercel link --yes --token $TOKEN)
+```
+
+## AWS
+
+AWS is broad — only use it when the user names a specific AWS service. Common agent tasks:
+
+```bash
+# S3
+aws s3 sync ./dist s3://<bucket>/ --delete
+aws s3 presign s3://<bucket>/file.zip --expires-in 3600
+
+# Lambda
+aws lambda update-function-code --function-name <fn> --zip-file fileb://fn.zip
+aws lambda invoke --function-name <fn> --payload fileb://event.json out.json
+
+# ECS
+aws ecs update-service --cluster <c> --service <s> --force-new-deployment
+aws ecs describe-services --cluster <c> --services <s>
+
+# Logs (CloudWatch Logs)
+aws logs tail /aws/lambda/<fn> --follow
+aws logs get-log-events --log-group-name <g> --log-stream-name <s>
+
+# Elastic Beanstalk
+eb deploy               # needs `eb` CLI (brew install aws-elasticbeanstalk)
+```
+
+Always pass `--region <region>` or rely on `aws configure`'s default. For `--query`/`--output text|json` to get parseable results.
+
+## Azure
+
+```bash
+az group list -o table
+az webapp up --runtime "NODE:20-lts" --sku F1 -n <app> -g <group>      # one-shot deploy from cwd
+az webapp deployment source config --name <app> -g <group> --repo-url <git> --branch main
+az webapp log tail -n <app> -g <group>
+az webapp config appsettings set -n <app> -g <group> --settings KEY=val
+az functionapp deployment source config-zip -g <group> -n <fn> --src ./deploy.zip
+```
+
+`-o table|json|tsv` controls output; `--query` for JMESPath filtering.
+
+## Google Cloud
+
+```bash
+gcloud config set project <PROJECT_ID>
+gcloud app deploy                              # App Engine
+gcloud run deploy <svc> --source . --region <r> --allow-unauthenticated   # Cloud Run
+gcloud run services list
+gcloud run services describe <svc> --region <r>
+gcloud functions deploy <fn> --runtime nodejs20 --trigger-http --allow-unauthenticated
+gcloud app logs tail -s default
+gcloud builds submit --tag gcr.io/<proj>/<img>
+```
+
+## When to use
+
+- "Deploy this" / "ship to prod" / "push to staging" with a cloud named or inferable from repo files
+- "Roll back the last deploy" / "tail the logs" / "restart the service"
+- "Set env var KEY=val on the deployed app" then redeploy
+- Any cloud CLI operation where the agent would otherwise say "go to the dashboard"
+
+## When NOT to use
+
+- Just running the app locally → use the project's dev server, not a cloud deploy
+- Building a Docker image for local use → `docker build`; only deploy to cloud if the user asks
+- Provisioning infra from scratch (VPCs, databases, IAM) → confirm scope first; these CLIs can do it but the user should explicitly ask before the agent creates billable resources
+
+## Gotchas
+
+- Always confirm the **environment** (production vs preview/staging) before `--prod`/production deploys. Prefer a preview deploy first; ask before promoting.
+- `vercel` without `--prod` is a safe preview; `vercel --prod` hits the real domain.
+- Railway/Vercel deploys read the repo's build config — check `package.json` scripts / `Dockerfile` / `vercel.json` / `railway.toml` before deploying so the agent knows what will run.
+- AWS/Azure/GCP commands can create billable resources; only run provisioning when the user explicitly asked for it.
+
+## Source
+
+Referenced in https://x.com/heyshruti7/status/2069083108092350823 — "Your cloud's CLI — every cloud ships one so your agent can deploy on its own: Railway, Vercel, AWS, Azure, Google Cloud."
@@ -0,0 +1,102 @@
+---
+name: cloudflared
+description: Use when the user asks to expose a local server to the internet, share a localhost URL publicly, test a webhook from a third-party, demo a local dev server to someone else, or get a public HTTPS URL for a port on this machine. Triggers on keywords like "cloudflared", "tunnel", "expose localhost", "public URL", "share local server", "webhook test", "ngrok alternative", "quick tunnel". Installs and runs `cloudflared` to put a localhost port on the public internet in one command.
+---
+
+# cloudflared — expose localhost to the world
+
+Use this when the user needs a public HTTPS URL pointing at a port on this machine — for demos, webhook callbacks, or letting someone else hit a local server. One command, no account, no firewall changes.
+
+## Install (first use)
+
+If `cloudflared` is not on PATH:
+
+```bash
+brew install cloudflared          # macOS
+# or: sudo apt install cloudflared       # Debian/Ubuntu (or download the .deb from github.com/cloudflare/cloudflared)
+# or: winget install Cloudflare.cloudflared   # Windows
+```
+
+Verify: `cloudflared --version`.
+
+## Quick tunnel (no account, no config)
+
+The fastest path — gives you a random `https://<random>.trycloudflare.com` URL instantly:
+
+```bash
+cloudflared tunnel --url http://localhost:3000
+```
+
+Output contains a line like:
+
+```
+--------------------------------------------------------------------------------------------+
+|  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
+|  https://example-words-tomorrow.trycloudflare.com                                          |
+--------------------------------------------------------------------------------------------+
+```
+
+Share that URL. The tunnel stays up as long as the process runs; kill it with Ctrl-C. No Cloudflare account needed. Random URL each run.
+
+## Named tunnel (stable URL, requires account)
+
+For a persistent hostname you can point clients/webhooks at repeatedly:
+
+```bash
+cloudflared tunnel login                       # browser auth, one-time
+cloudflared tunnel create my-tunnel            # creates tunnel UUID
+cloudflared tunnel route dns my-tunnel dev.example.com   # bind a hostname to it
+```
+
+Then run it with a config file `~/.cloudflared/config.yml`:
+
+```yaml
+tunnel: <tunnel-UUID>
+credentials-file: /Users/<you>/.cloudflared/<tunnel-UUID>.json
+
+ingress:
+  - hostname: dev.example.com
+    service: http://localhost:3000
+  - service: http_status:404
+```
+
+```bash
+cloudflared tunnel run my-tunnel
+# or as a service:
+sudo cloudflared service install        # macOS/Linux daemon
+```
+
+## Common patterns
+
+| Goal | Command |
+|---|---|
+| Expose port 3000 with random URL | `cloudflared tunnel --url http://localhost:3000` |
+| Expose a different local port | `cloudflared tunnel --url http://localhost:8080` |
+| Expose HTTPS local server | `cloudflared tunnel --url https://localhost:3000` |
+| Point a hostname at local server | named tunnel + `route dns` (above) |
+| Run named tunnel in background | `cloudflared tunnel run my-tunnel &` or `cloudflared service install` |
+| TCP port (e.g. SSH) | `cloudflared tunnel --url tcp://localhost:22` (needs named tunnel + `cloudflared access` client) |
+
+## When to use
+
+- "Give me a public URL for this local server" / "share this with my teammate"
+- "I need to test a Stripe/GitHub/Slack webhook hitting my local machine"
+- "Demo the dev server without deploying"
+- "ngrok alternative" / "expose localhost"
+
+## When NOT to use
+
+- Production ingress → set up a real CDN/reverse proxy; quick tunnels are for dev/demo
+- Internal-only access on the same machine → just use `localhost:PORT`
+- Long-running stable hostnames without a Cloudflare account → quick tunnels are random and not persistent; use a named tunnel or a different tool
+
+## Gotchas
+
+- Quick tunnel URLs are random per run and can take 10-30s to become reachable after the banner prints.
+- Cloudflare's free tier is fine for dev; rate limits and TOS apply to high-volume production traffic.
+- If the local server binds to `127.0.0.1` only, that's fine — cloudflared connects from the same machine.
+- Webhooks that verify SSL: the `*.trycloudflare.com` URL is real HTTPS with a valid cert, so verifiers pass.
+
+## Source
+
+Referenced in https://x.com/heyshruti7/status/2069083108092350823 — "cloudflared — expose localhost to the world with one prompt. Demo links in seconds."
@@ -0,0 +1,135 @@
+---
+name: github-cli
+description: Use when the user asks to open a PR, review or merge a PR, list/check/review issues, react to or comment on PRs, create/manage releases, browse a repo's metadata, or do any GitHub operation without opening the web UI. Triggers on keywords like "gh", "GitHub CLI", "open a PR", "merge the PR", "review request", "list my PRs", "create release". Installs and drives the `gh` CLI so the agent never needs the browser for GitHub workflows.
+---
+
+# GitHub CLI (`gh`) — GitHub without the web UI
+
+The agent should open PRs, review, merge, and manage issues/releases from the terminal instead of telling the user to "go to GitHub and click merge."
+
+## Install (first use)
+
+If `gh` is not on PATH:
+
+```bash
+brew install gh          # macOS
+# or: sudo apt install gh        # Debian/Ubuntu
+# or: winget install GitHub.cli  # Windows
+```
+
+Authenticate (one-time):
+
+```bash
+gh auth login
+# choose GitHub.com → HTTPS → "Login with a web browser"
+# or use a token: echo "$GH_TOKEN" | gh auth login --with-token
+```
+
+Verify: `gh auth status`.
+
+If automation is needed and interactive login isn't possible, set `GH_TOKEN` (or `GITHUB_TOKEN`) env var from a fine-grained PAT with the repo scopes needed (contents, pull-requests, workflows, issues).
+
+## Core workflows
+
+### Open a PR from the current branch
+
+```bash
+gh pr create --title "<title>" --body "<body>" --base main
+# body supports markdown; can also read from a file: --body-file pr.md
+# add reviewers/assignees/labels:
+gh pr create --title "..." --body "..." --reviewer alice,bob --label "needs review" --assignee @me
+```
+
+The opencode convention: only open PRs when the user explicitly asks. Inspect `git status`, `git diff`, and `git log --oneline -10` first, and stage only intended files.
+
+### Review and merge
+
+```bash
+gh pr view <N>                      # PR details, checks, mergeable state
+gh pr view <N> --comments           # read the discussion
+gh pr diff <N>                      # the diff in the terminal
+gh pr checks <N>                    # CI status
+gh pr review <N> --approve --body "lgtm"
+gh pr review <N> --request-changes --body "please fix X"
+gh pr merge <N> --squash --delete-branch
+# --merge / --squash / --rebase match repo allowed methods
+# --auto waits for required checks before merging
+```
+
+### List and filter
+
+```bash
+gh pr list --author @me --state open
+gh pr list --search "review-requested:@me"
+gh issue list --assignee @me --state open
+gh pr list --state closed --limit 5
+```
+
+### Issues
+
+```bash
+gh issue create --title "..." --body "..." --label bug --assignee @me
+gh issue view <N>
+gh issue close <N>
+gh issue comment <N> --body "..."
+```
+
+### Releases
+
+```bash
+gh release create v1.2.3 --notes "..." --title "v1.2.3"
+gh release create v1.2.3 ./dist/*   # attach build artifacts
+gh release list
+gh release view v1.2.3
+gh release download v1.2.3
+```
+
+### Repo metadata & browsing
+
+```bash
+gh repo view                       # current repo info
+gh repo view owner/repo            # another repo
+gh repo clone owner/repo
+gh repo create <name> --private --source=. --push   # create + push cwd
+gh repo fork owner/repo --clone
+```
+
+### Cross-repo / search
+
+```bash
+gh search prs --author @me --state open
+gh search issues "is:open label:bug"
+gh search repos "topic:local-llm"
+```
+
+## Aliases (optional quality-of-life)
+
+```bash
+gh alias set co 'pr checkout'
+gh alias set rv 'pr review --view'
+# then: gh co 123   →  gh pr checkout 123
+```
+
+## When to use
+
+- "Open a PR for this branch" / "merge it" / "what's the status of PR #123"
+- "Review the latest PR" / "request changes on #45"
+- "List my open issues" / "create an issue for this bug"
+- "Cut a release" / "attach these binaries to v2.0"
+- Any GitHub action where the agent would otherwise say "go to the web UI"
+
+## When NOT to use
+
+- Reading the repo's source code → use Read/Glob/Grep on the working copy, not `gh`
+- Git operations (commit, push, branch) → use `git` directly; `gh` wraps GitHub, not git
+- Long-form PR body authoring → write to a file first, pass `--body-file`
+
+## Auth troubleshooting
+
+- `gh auth status` fails → run `gh auth login` again, or confirm `GH_TOKEN` is exported in the shell.
+- "could not find any releases" on a fork → releases live on the upstream repo; use `gh release list --repo owner/repo`.
+- 403 on merge → the token lacks `pull-requests: write` (or repo `contents: write`); regenerate with the scope and re-login.
+
+## Source
+
+Referenced in https://x.com/heyshruti7/status/2069083108092350823 — "GitHub CLI — open PRs, review, merge. Your agent never touches the web UI."
@@ -0,0 +1,392 @@
+---
+name: no-mistakes
+description: Validate your code changes through the no-mistakes pipeline - automated code review, tests, lint, docs, push, PR, and CI - before they reach the configured push target. Use when the user asks to run no-mistakes, gate or ship or validate their changes, push safely, asks you to do a task and then validate it, or invokes /no-mistakes.
+user-invocable: true
+---
+
+# no-mistakes
+
+`no-mistakes` is a local gate that validates your code changes through a pipeline
+(intent, rebase, review, test, document, lint, push, PR, CI) before they reach
+the configured push target. You drive it through the `no-mistakes axi` command family, which prints
+machine-readable [TOON](https://toonformat.dev) to stdout and progress to stderr.
+
+
+## Active validation-step boundary
+
+A no-mistakes validation-step agent is already inside an active outer run. It
+must inspect, fix, and return only its assigned phase. It must never initialize,
+start, reattach, rerun, respond to, synchronize, abort, eject, or directly push
+a no-mistakes pipeline. Delivery requirements in user intent remain
+acceptance context, but the outer executor alone performs the other validation,
+push, PR, and CI phases.
+
+`NO_MISTAKES_GATE` is fast diagnostic evidence, not authorization by
+itself. The runtime combines managed Git identity with authenticated process
+ancestry. If a pipeline-control command returns
+`error.code: nested_gate_context`, stop immediately and
+return control to the outer executor. Safe inspection remains available through
+`no-mistakes axi status`, `no-mistakes axi logs`, help, and
+`no-mistakes doctor`.
+
+
+When the user invokes `/no-mistakes`, report the outcome at the end. If the user
+asks for something specific, translate that request into the matching `axi run`
+flags yourself - for example, "skip the lint step" becomes `--skip=lint`. Run
+`no-mistakes axi run --help` to see the available flags.
+
+## Two ways to invoke
+
+`/no-mistakes` works in two modes, depending on whether the user hands you a
+task along with the command:
+
+- **Validate-only** - bare `/no-mistakes` (optionally with flag-style requests
+  like "skip the lint step"). The user's code changes are already committed;
+  validate them and report the outcome.
+- **Task-first** - `/no-mistakes <task>`, e.g.
+  `/no-mistakes add a --json flag to the status command`. First carry out the
+  task yourself, then validate the result through the pipeline:
+  1. **Check scope.** Inspect `git status` before you change or commit anything.
+     Preserve unrelated pre-existing uncommitted changes, and when you commit,
+     commit only the changes that belong to the user's task.
+  2. **Do the work.** Make the changes the task describes, then **commit them on
+     a feature branch**. If the user is on the repository's default branch,
+     create a feature branch first - the gate validates committed history on a
+     non-default branch, so the work must land there before you run.
+  3. **Then validate**, passing the user's task as your `--intent`. The task
+     text is exactly what the user set out to accomplish, in their own words, so
+     it *is* the intent - preserve requirements stated directly by the user,
+     including constraints, exclusions, acceptance criteria, and later decisions;
+     do not condense them into a diff summary or drop them while adding
+     implementation context. Enrich it with the decisions and tradeoffs you
+     made while doing the work (see
+     [Intent is required](#intent-is-required)).
+
+
+## Test-quality rule
+
+Never add a test whose only evidence is that it opens, reads, greps, parses, or
+snapshots implementation source code and finds or omits particular strings,
+tokens, lines, commands, function names, prompt phrases, regex matches, AST
+shapes, or incidental snapshots. That does not prove behavior: matching text
+can be dead or commented out, and a behavior-preserving refactor can change it.
+
+Instead execute a public or executable interface and assert observable behavior,
+state, output, side effects, and failure modes. For machine-consumed declarative
+artifacts such as workflow YAML, JSON, policy, .gitignore, or generated
+configuration, invoke the real consumer when feasible or parse into a typed or
+normalized semantic model and assert meaning. A raw substring or regex over the
+file is still the anti-pattern.
+
+Reading a file is legitimate when the file is itself generated public output, a
+serialized protocol, persisted state, an intentional snapshot, or another
+explicitly owned text or byte contract. Name that contract, and do not use its
+contents as a proxy that unrelated code works. A natural-language prompt or
+instruction is not proven effective because its source contains a sentence.
+Deterministic CI may test the final emitted prompt delivered to an agent as an
+intentional generated interface; model interpretation belongs in
+development-only evaluation, not live-LLM CI.
+
+For a regression, reproduce the reported failure when feasible: the test should
+fail before the fix and pass after it.
+
+
+Everything below - preconditions, intent, the validate-and-decide loop - applies
+the same way once the work is committed on a feature branch.
+
+## Before you start
+
+- The work you want validated must be **committed** on a branch. The gate
+  validates committed history, not your uncommitted working tree.
+- You must be on a **feature branch**, not the repository's default branch.
+- The repository must already be initialized with `no-mistakes init`.
+- The daemon must have a runnable configured pipeline agent: a supported native
+  agent binary, the `agent: cursor` ACP alias, or an explicit `acp:<target>` through
+  `acpx`. You are the AXI driver, not
+  an implicit pipeline-agent backend. If none is available, the run fails
+  before its first step; `no-mistakes doctor` reports the configuration problem.
+
+If any of these is not met, `axi run` returns an `error:` with the exact command
+to fix it - read it and act on it (commit your work, or create a branch). If the
+repository is not initialized, run `no-mistakes init` first; if the `no-mistakes`
+command itself is missing or misbehaving, `no-mistakes doctor` reports what is
+wrong.
+Before starting, run `no-mistakes axi` (home view).
+If it shows an active run on your current branch, inspect it with `no-mistakes axi status`.
+If it is parked at a gate, drive it with `no-mistakes axi respond`.
+Reattach an in-flight run by re-running `no-mistakes axi run` when it still matches your current `HEAD` - either as the submitted head or as the current pipeline head.
+Only `no-mistakes axi abort` it when you mean to discard that run before starting over; aborting is a between-runs action, never a way to take over or bypass a gate while a run is still going (see [Validate and decide](#validate-and-decide)).
+If it shows an active run on another branch, leave that run alone and start validation for your current branch with `no-mistakes axi run --intent "..."`.
+
+## Intent is required
+
+When you start a run you must pass `--intent`: **what the user set out to
+accomplish** - the goal or request behind this work, in their terms. This is not
+a description of the diff or the files you changed; it is the objective the
+change is meant to achieve. You know it from the conversation, so pass it
+directly - no-mistakes uses it verbatim instead of inferring it from local agent
+transcripts (slower and flakier).
+
+Err on the side of completeness, not brevity. The review step uses `--intent`
+to tell a deliberate decision apart from a mistake, so a thin one-line summary
+makes it flag things the user already chose. Capture the nuance: the user's
+goal, the specific decisions and tradeoffs they made along the way, any
+constraints or approaches they ruled in or out, and anything they explicitly
+asked for that might otherwise look surprising in the diff. A few sentences to a
+short paragraph is normal - write down what you learned from the conversation
+that a reviewer reading only the diff would not know.
+
+## Validate and decide
+
+Run the pipeline and decide on its findings as they come up:
+
+1. Start the run. It blocks until the first decision point or the end:
+   ```sh
+   no-mistakes axi run --intent "<what the user set out to accomplish>"
+   ```
+   `axi run` and every `axi respond` block synchronously - the review, test,
+   and CI steps can each take **several minutes**, so a single call may not
+   return for a while. That is normal; do not cancel or re-issue the command
+   because it seems slow. Both commands default to `--wait 8m` so a harness
+   with a 10-minute tool cap gets a structured return instead of an unbounded
+   hang. If the command returns because that wait elapsed, it is not a failed
+   run and does not mean the daemon is dead: inspect with `no-mistakes axi status`
+   and re-run `axi run` or `axi respond` to reattach. A slow live daemon is
+   retried after a health probe rather than treated as I/O failure. To check
+   progress without disturbing the run, use `no-mistakes axi status` from a
+   separate call.
+   A long-running call is working, not stalled - background it if your harness
+   needs to, but the run **never advances past a gate on its own**. Read every
+   return; on a `gate:`, respond; loop until an `outcome:`. Never idle-wait
+   for the run to move forward by itself.
+   When that status output includes `awaiting_agent: parked <duration>` under the run,
+   the run is parked at an approval or fix-review gate and waiting for you to
+   send `axi respond`. The field is observability only: it does not change
+   gate resolution, auto-resume the run, or make `--yes` the default.
+   While a step is actively `running` or `fixing`, `axi status` may include
+   `active_steps` with step-scoped `active_for`, current-round `round_active_for`,
+   `last_activity`, a native `agent_pid` when a subprocess agent is running, and the current round such as `round 1`,
+   `auto-fix 1/3`, or `fix 2`. If `last_activity` is prefixed with
+   `quiet`, no step log or native-agent lifecycle activity has arrived for
+   longer than `step_quiet_warning`. Treat that as a liveness clue, not as
+   permission to cancel, rerun, or edit the worktree yourself.
+2. If the output contains a `gate:` object, the pipeline is waiting on you.
+   Read its `findings` table. Each finding has an `id`, `severity`,
+   `file`, `description`, and an `action` that tells you how the
+   pipeline classified it:
+   - `auto-fix` - mechanical and low-risk; you can authorize the fix on
+     your own judgment by responding with `--action fix`.
+   - `no-op` - informational only; nothing to do.
+   - `ask-user` - the finding challenges the user's deliberate intent or
+     touches product behavior. This is a call only the user can make - see
+     [Escalate `ask-user` findings](#escalate-ask-user-findings) below.
+
+   **Review auto-fix is disabled by default** (`auto_fix.review: 0`; a repo
+   or global `auto_fix.review > 0` override re-enables it), so blocking and
+   ask-user review findings park for your decision rather than being silently
+   self-fixed. (Other steps such as test and lint may auto-fix within the
+   pipeline and re-run before they ever gate.)
+
+   Choose one response:
+   ```sh
+   # accept the step as-is and continue
+   no-mistakes axi respond --action approve
+
+   # have the pipeline fix specific findings, then continue
+   no-mistakes axi respond --action fix --findings <id1,id2> --instructions "<optional guidance>"
+
+   # skip this step
+   no-mistakes axi respond --action skip
+   ```
+   While a run is active, never fix findings by editing the code yourself -
+   the pipeline owns both the findings and the fixes. Your job at a gate is to
+   decide and respond; `--action fix` has the pipeline apply the fix and
+   re-review the result. For the same reason, while a run is active do **not**
+   `abort` or `rerun` to go fix a finding yourself - even a real bug in
+   your own code - because that discards the pipeline's in-flight work and
+   forces a full re-validation. `abort` and `rerun` are for *between*
+   runs (after a `failed` or `cancelled` outcome), never to circumvent a
+   gate.
+
+    Each `respond` blocks until the next `gate:`, `checks-passed` decision point, or final outcome, subject to the same default `--wait 8m` hold.
+
+    Extra flags on `respond`:
+    - `--wait` bounds the hold (default 8m).
+    - `--reason "the operator's explanation"` records an explicitly authorized Test exception with `--step test --action approve`.
+      This does not grant approval authority; escalate ask-user findings as before.
+      Without a reason, Test approval remains effective; an approval past a failing command, `no-go`, or `inconclusive` verdict is reported as an exception with no operator reason supplied.
+    - `--add-finding '<json>'` (with `--action fix`) folds a finding you
+      spotted yourself - one the pipeline did not surface - into the fix round,
+      as a JSON finding object. Use it for a problem you noticed that is not in
+      the gate's own `findings` table.
+    - `--step <name>` responds to a specific step instead of the one currently
+      awaiting approval. You rarely need this; omit it to answer the active gate.
+3. Repeat step 2 until the output has an `outcome:` instead of a `gate:`. The
+   outcomes are:
+   - `checks-passed` - the change is validated and CI is green (or the
+     trusted default-branch config declares `no_ci: true` and no checks are
+     registered - the help line names that declaration when it applies), but
+     the PR is not merged yet. **You are done driving the pipeline.** Do not
+     wait for the merge: tell the user the PR is ready and ask them to review
+     and merge it (the PR link is in the `help` line). A generic empty forge
+     check list without that declaration is not ready. no-mistakes keeps
+     monitoring the PR in the background until it is merged, closed, or its
+     configured idle timeout elapses, so a human can watch it in the TUI.
+   - `passed` - the pipeline completed under the requested steps, including any
+     explicit per-run skips. This alone is not evidence that a PR was merged.
+   - `passed-with-override` - the pipeline completed with an explicitly approved Test exception or CI failure.
+     Report the exception, not a clean pass.
+     Test evidence is in `run.test_override_reason`, including when CI readiness returns `checks-passed`; do not omit it from the summary.
+   - `passed-with-skips` - publication or CI verification automatically skipped.
+     Report the missing evidence and its cause from `run.automatic_skips`,
+     bound to the full `run.head_sha`. This is neither CI readiness nor a
+     failing code verdict. Explicit per-run skips retain their existing behavior.
+   - `failed` or `cancelled` - they did not; read the output and address it.
+     Follow the custody guidance below before fixing whatever the output
+     points at (a failing test, a lint error, a finding you skipped). Commit the
+     fix on the same feature branch, then submit it with
+     `no-mistakes axi run --intent "..."`. A fresh run or `rerun` is a
+     *between-runs* action, correct only after a terminal outcome like this -
+     never mid-run to circumvent a gate. Do not leave the user at a `failed`
+     outcome without either retrying or explaining what blocks it.
+
+`no-mistakes rerun` keeps its existing head selection: the gate head, or the
+latest terminal run's verified unpublished preserved head while custody remains
+outstanding. If a known clean caller `HEAD` differs from that selected head,
+it refuses before starting or superseding any run and reports both full SHAs.
+It never substitutes the caller head or moves either branch to make them match.
+On refusal, inspect `no-mistakes axi status` and follow the custody guidance
+below. Dirty callers and callers without clean-head evidence retain existing
+selection behavior.
+
+Before any post-pipeline local commit or fresh run, read the structured `branch_sync` object returned by AXI home, status, or a drive result.
+Only when its `next_action.code` is `sync`, run `no-mistakes axi sync` first.
+That guarded sync may be a strict fast-forward or a content-equivalent diverged advance that anchors the pre-sync head before moving the branch with reset semantics; genuine divergence stays blocked.
+If it reports `next_action.code` is `continue_active_run`, the pipeline still owns the branch: run the reported command, keep driving the active run, and do not make local follow-up commits.
+When `next_action.code` is `recover_custody`, run its exact `next_action.command` rather than reconstructing one. That is `no-mistakes axi sync --recover` to take a still-available preserved pipeline head, or `no-mistakes axi sync --recover --keep-local` in two keep-local cases: when an accessible gate confirms the verified preserved head is missing and you are explicitly discarding those unpublished commits, or when a bound archive proves divergent later work remains preserved while recovery keeps the branch at the exact reported required head and never selects, merges, or replays the archive. Do not substitute plain `--recover` or `rerun` for a reported keep-local action. `no-mistakes rerun` can resume validating a still-available ordinary preserved head instead, subject to the clean-head check above.
+Ordinary recovery takes that head by fast-forward, or by adopting a diverged preserved head proven to carry every local change - the ordinary result of the pipeline rebasing your commits onto a newer base - after anchoring your pre-recovery head under `refs/no-mistakes/recover-local/<run>`.
+The ordinary containment proof is deliberately narrow, so a rebase whose fix rounds also rewrote your own lines refuses instead of being adopted: when nothing can tell a deliberate pipeline fix from a dropped change, the decision is yours.
+A `branch_sync.state` of `user_owned` means the run went terminal before changing the submitted head and cancellation released the branch: the exact branch and head are yours and immediately usable for whichever delivery path is authorized - no sync action is needed, and a repeated `--recover` there is a harmless no-op.
+A dirty worktree, or divergence that cannot be proven contained, makes the recovery refuse with explicit choices; `--keep-local` keeps your current head while the preserved commits stay anchored under `refs/no-mistakes/recover/<run>`. The same flag is the recovery when an accessible gate confirms that the verified preserved head is missing and recovery refs are compatible: it returns custody at the current local head without requiring that object.
+If synchronization is blocked, process that structured state instead of improvising reset, stash, merge, rebase, force, or branch replacement.
+After synchronization, commit the follow-up on top and re-run `no-mistakes axi run --intent "..."` with the original user intent.
+This preserves every prior gate-fix commit regardless of its configured subject.
+
+The CI step deliberately keeps watching the PR after checks pass, so
+`axi run` returns `checks-passed` the moment checks are green (or a trusted
+`no_ci: true` declaration covers a zero-check repository) rather than
+blocking on the human merge. Never poll or re-run waiting for the merge yourself.
+Never treat "no CI checks reported" alone as green.
+
+Because that monitor stays live, a PR that falls behind the default branch or
+hits a merge conflict after checks pass - commonly because another PR merged
+first - needs **no command from you**: never hand-rebase. When the CI monitor
+sees an actual conflict it **rebases onto the base, resolves it, revalidates from Review
+because rebasing cannot prove continuity with the reviewed head, and re-pushes
+the branch through Push**; a PR that is merely behind but still clean needs nothing
+either, since the platform merges it. The one exception is when that monitor is
+no longer running - the PR was closed, the run was aborted or superseded, it
+idle-timed-out, or its auto-fix attempts were exhausted - in which case recover
+with `no-mistakes rerun`, subject to the clean-head check above. An accepted
+rerun cancels the stale monitor and re-runs the full pipeline including a
+deterministic rebase step. Do **not** reach for
+`no-mistakes axi run` to refresh a still-active PR: after `checks-passed` it
+reattaches to the running monitor (HEAD unchanged) and returns its output
+without rebasing.
+
+On a successful outcome (`checks-passed` or `passed`), close the loop with the
+user: summarize what happened during the pipeline in a concise, easily readable
+format - what was validated and what was found. If the output includes a
+`fixes` table, the pipeline fixed findings your original change missed:
+acknowledge those misses and explicitly list each fix so the user can easily
+review them.
+
+## Escalate `ask-user` findings
+
+A gate whose findings are all `auto-fix` or `no-op` is safe to drive on your
+own judgment: respond with `--action fix` or `--action approve` as
+appropriate. But a finding marked
+`ask-user` is a decision that belongs to the user, not you - the pipeline
+flagged it because it challenges their deliberate intent or changes product
+behavior. Do not approve, fix, or skip it on your own. Instead, stop and bring
+it to the user before you respond:
+
+- Relay each `ask-user` finding to them as the pipeline wrote it - its
+  `id`, `file`, and full `description` verbatim. Do not paraphrase,
+  summarize away the detail, or pre-judge the answer.
+- Ask how they want to proceed, then translate their decision into the matching
+  `respond` call: `--action fix` (pass their guidance through
+  `--instructions`), `--action approve`, or `--action skip`.
+
+The exception is `--yes` (below): it is the user's standing consent to
+drive eligible gates unattended, so under `--yes` you resolve ordinary
+`ask-user` findings automatically instead of stopping to ask.
+
+If you have clear consent to drive the run automatically, pass `--yes` to `axi run`
+or `axi respond`. For eligible gates, it treats actionable findings - `auto-fix` and
+`ask-user` alike - as consent to fix it, selects every current finding for one
+fix round, accepts the resulting fix review, and approves gates with only
+`no-op` findings. Only use it when the user has asked you to drive the whole
+run without checking back.
+
+A `protected-path-refusal` gate still requires an explicit operator response
+under `--yes`. Relay its path and rule; do not automatically fix, approve,
+or skip it. Approval is rejected. Have the operator inspect and resolve the
+reported edit, then send `--action fix` to retry the unfinished step.
+The [protected-path reference](https://kunchenguid.github.io/no-mistakes/reference/repo-config/#protected_paths)
+owns the staging guard's scope and limitations.
+
+A `test-agent-unvalidated-work` finding means a timed-out Test agent left
+commits or changes no Test turn validated. Approval is rejected, so `--yes`
+stops at that gate without responding. Relay what the finding names and do
+not skip Test, which would publish that work. Ask the operator to choose:
+`--action fix` spends another agent budget to validate the work, and
+`no-mistakes axi abort` stops the run.
+
+## Inspecting state
+
+```sh
+no-mistakes axi               # home view: current branch, active runs, next steps
+no-mistakes axi status        # full detail plus cached branch_sync when relevant
+no-mistakes axi sync --check  # freshly verify an offered synchronization plan
+no-mistakes axi sync          # apply only an offered guarded synchronization
+no-mistakes axi sync --recover  # return custody after a terminal run left unpublished pipeline commits
+no-mistakes axi logs --step <name> --full   # full log output of one step
+no-mistakes axi abort         # cancel the current-branch active run
+no-mistakes axi abort --run <id>   # cancel a specific run by id (works outside its worktree)
+```
+
+## Reading the output
+
+- Output is TOON: `key: value` pairs, `name[N]{cols}:` tables, and `help[N]:` hints.
+- `axi status` is scoped to your current branch when `--run` is omitted: with a known current branch, an implicitly resolved `run:` is this branch's. A run under `other_branch_run:` is one you named with `--run <id>` that belongs to another branch - never read its status or outcome as your own work. An explicit `--run <id>` rendered under `run:` while the current branch is unknown (detached `HEAD` or a branch-lookup failure) encodes no branch relationship. In a successful status response, no run object at all means this branch has no run yet, whatever the recent-runs table lists; an `error:` response proves nothing about run ownership, so act on the error instead of concluding the branch is idle.
+- A non-terminal run object may include `awaiting_agent: parked <duration>` immediately after `status`; that means the run is parked at a gate. Only an implicitly resolved current-branch gate offers `axi respond`; an explicit `--run <id>` status is inspection-only even when its branch matches, because the branch may have a newer active run. Follow the response's `help`.
+- A run object with a `running` or `fixing` step may include an `active_steps` table. `active_for` is the enclosing step duration; `round_active_for` is the displayed execution or fix round duration and resets for a fix round. Older runs without round timing leave `round_active_for` empty.
+- The `help` list at the bottom of most responses tells you the next commands to run.
+- Errors are printed as `error: ...` on stdout with a `help` list; act on the suggestion.
+- Exit codes: `0` success, no-op, or normal decision gates, `1` failed or cancelled final outcomes, `2` bad usage.
+
+A `gate:` waiting on you looks roughly like this - a `gate:` line naming the step, optional step-specific fields such as `note`, a `findings[N]{...}:` table with one row per finding, and a `help[N]:` list of next commands:
+
+```
+gate: review
+note: Review auto-fix is disabled by default (auto_fix.review: 0; a repo or global auto_fix.review > 0 override re-enables it), so blocking and ask-user review findings park for your decision rather than being silently self-fixed.
+findings[2]{id,severity,file,line,action,description}:
+  r1,warning,internal/pipeline/executor.go,,auto-fix,Error from os.Remove is ignored
+  r2,error,cmd/no-mistakes/main.go,,ask-user,New --force flag bypasses the confirm prompt
+help[6]:
+  Run `no-mistakes axi respond --action approve` to accept this step and continue
+  Run `no-mistakes axi respond --action fix --findings <ids>` to have the pipeline fix the selected findings (do not edit files yourself)
+  Run `no-mistakes axi respond --action skip` to skip this step
+  Run `no-mistakes axi logs --step review --full` to read the full step log
+  A long-running call is working, not stalled - background it if your harness needs to, but the run never advances past a gate on its own. Read every return; on a `gate:`, respond; loop until an `outcome:`.
+  Commit post-pipeline follow-up work on top of the existing branch so every pipeline fix commit remains present. Never abort-and-restart, reset, or replace the branch in a way that drops prior gate-fix commits.
+```
+
+Read the `action` column per row: decide `r1` (auto-fix) on your own
+judgment - `respond --action fix --findings r1` hands it to the pipeline to
+fix - but stop and escalate `r2` (ask-user) to the user before responding. A
+final state
+instead shows `outcome: <checks-passed|passed|passed-with-override|passed-with-skips|failed|cancelled>` with no
+`findings` table. Field names and exact columns can vary by step and version,
+so read the actual `findings` header rather than assuming this layout.
@@ -0,0 +1,87 @@
+---
+name: playwright-cli
+description: Use when the user asks to test a web app in a real browser, automate browser clicks/form submissions, take screenshots of flows, verify a UI works end-to-end, or do end-to-end (E2E) testing. Triggers on keywords like "browser test", "E2E test", "click through", "playwright", "verify the flow", "screenshot the page". Installs and drives the Playwright CLI to let the agent act as a real browser user.
+---
+
+# Playwright CLI — agent-driven browser testing
+
+The agent should not say "looks good to me" about a UI it never opened. Use Playwright to actually click through the flow, fill forms, assert outcomes, and screenshot the result.
+
+## Install (first use)
+
+If `playwright` is not on PATH, install it:
+
+```bash
+npm install -g @playwright/mcp@latest
+npx playwright install --with-deps
+```
+
+`npx playwright install` downloads the browser binaries (chromium, firefox, webkit). `--with-deps` installs OS libraries they need (Linux only; on macOS it's a no-op for the deps portion).
+
+Verify: `npx playwright --version`.
+
+## Core CLI commands
+
+| Task | Command |
+|---|---|
+| Scaffold a new test project | `npm init playwright@latest` (creates `tests/`, `playwright.config.ts`) |
+| Run all tests | `npx playwright test` |
+| Run one file | `npx playwright test tests/login.spec.ts` |
+| Run by title grep | `npx playwright test -g "logs in"` |
+| Run headed (see the browser) | `npx playwright test --headed` |
+| Run with browser visible + slow | `npx playwright test --headed --workers=1` |
+| UI mode (interactive watcher) | `npx playwright test --ui` |
+| Trace viewer (post-mortem) | `npx playwright show-trace trace.zip` |
+| Codegen a flow by clicking | `npx playwright codegen <url>` |
+| Codegen to a file | `npx playwright codegen <url> -o tests/flow.spec.ts` |
+| Screenshot a page | `npx playwright screenshot --browser chromium <url> out.png` |
+| PDF a page | `npx playwright pdf <url> out.pdf` |
+| Open a page in a real browser | `npx playwright open <url>` |
+
+## When to use
+
+- User says "test the login flow", "verify the checkout works", "click through and make sure nothing breaks"
+- User asks to record a new E2E test from a manual flow → `playwright codegen`
+- User wants a screenshot/PDF of a rendered page for verification
+- After touching auth, forms, navigation, or anything with state, run the relevant spec instead of asserting "should work"
+
+## When NOT to use
+
+- Unit testing component logic → use the project's existing unit test runner (vitest, jest, etc.)
+- API/endpoint testing → use `curl`/httpie or the API test framework already in the repo
+- Load testing → Playwright is functional, not perf; suggest k6 or similar
+
+## Writing tests (codegen first, edit second)
+
+The fastest path to a working test is `codegen`, not hand-writing:
+
+```bash
+npx playwright codegen http://localhost:3000 -o tests/auth.spec.ts
+```
+
+Click through the flow in the browser that pops up; Playwright writes the spec live. Then edit the generated file to add assertions (`expect(locator).toHaveText(...)`, `expect(page).toHaveURL(...)`) and clean up selectors (prefer `getByRole`, `getByLabel` over CSS).
+
+## Assertions quick reference
+
+```ts
+import { test, expect } from '@playwright/test';
+
+test('user can log in', async ({ page }) => {
+  await page.goto('/login');
+  await page.getByLabel('Email').fill('user@example.com');
+  await page.getByLabel('Password').fill('secret');
+  await page.getByRole('button', { name: 'Sign in' }).click();
+  await expect(page).toHaveURL(/dashboard/);
+  await expect(page.getByRole('heading', { name: 'Welcome' })).toBeVisible();
+});
+```
+
+## Debugging a failing test
+
+1. `npx playwright test tests/x.spec.ts --headed --workers=1` — watch it run.
+2. If still unclear, add `--trace on` then `npx playwright show-trace trace.zip`.
+3. `page.pause()` in the spec drops into the Playwright Inspector (step through, try selectors live).
+
+## Source
+
+Referenced in https://x.com/heyshruti7/status/2069083108092350823 — "Playwright CLI — your agent tests the browser itself. No more 'looks good to me.' It actually clicks through the flow."
@@ -0,0 +1,35 @@
+---
+name: read-tweet
+description: Use when the user asks to read, fetch, or show the content of an X (Twitter) tweet or thread by URL or ID. Triggers on x.com/twitter.com URLs or tweet IDs. Uses the local `bird` CLI to pull content via the browser cookie session.
+---
+
+# Read X/Twitter Tweet Content with bird
+
+When the user asks to read, fetch, view, or summarize a tweet (or thread), use the locally installed `bird` CLI instead of `webfetch` — it authenticates via the active browser session and returns full tweet content + metadata.
+
+## Commands
+
+Use `/opt/homebrew/bin/bird` (absolute path since PATH can be sparse in non-interactive shells):
+
+- Single tweet: `bird read <tweet-url-or-id> --json`
+- Full thread/conversation: `bird thread <tweet-url-or-id> --json`
+- Replies to a tweet: `bird replies <tweet-url-or-id> --json`
+
+Prefer `--json` for parseable output (author, text, media, created_at, metrics). Drop `--json` only if the user wants pretty-printed terminal output.
+
+## When to use
+
+- User pastes an `x.com`/`twitter.com` URL and asks anything about it
+- User references a tweet by numeric ID
+- User asks for "the thread", "the replies", or "what does this tweet say"
+
+## When NOT to use
+
+- User asks to post, reply, like, bookmark, follow, or search tweets — use other `bird` subcommands directly (see `bird --help`)
+- User asks about article content linked FROM a tweet — `bird` only returns tweet text/metadata, not outbound article bodies; fall back to `webfetch` on the linked URL
+
+## Notes
+
+- `bird` reads `auth_token` and `ct0` cookies from Safari/Chrome/Firefox; no paid dev account needed
+- If a fetch fails with auth errors, tell the user to sign in to x.com in their browser and retry
+- Quote tweets and retweets include the referenced tweet in the JSON payload
@@ -1,6 +1,6 @@
 {
  "$schema": "https://opencode.ai/config.json",
-  "model": "omlx/qwen3.6-35b",
+  "model": "opencode-go/gpt-6-luna",
  "autoupdate": false,
  "providers": {
    "omlx": {
@@ -7,7 +7,8 @@ name = "xAI Official"
 git = "https://github.com/xai-org/plugin-marketplace.git"

 [models]
-default = "qwen"
+default = "grok-4.5"
+default_reasoning_effort = "high"

 [model.qwen]
 model = "Jundot/Qwen3.6-35B-A3B-oQ4-mtp"
@@ -24,7 +25,7 @@ max_completion_tokens = 65536
 theme = "rosepine"
 max_thoughts_width = 120
 fork_secondary_model = "grok-build"
-permission_mode = "always-approve"
+permission_mode = "auto"
 yolo = false
 compact_mode = false

@@ -32,4 +33,4 @@ compact_mode = false
 installer = "internal"

 [privacy]
-privacy_banner_acked = "2026-09-21T16:02:21Z"
+privacy_banner_acked = "2026-09-24T02:33:29Z"
@@ -40,6 +40,7 @@ managed=(
  "$HOME/.claude/CLAUDE.md"
  "$HOME/.codex/AGENTS.md"
  "$HOME/.config/opencode/AGENTS.md"
+  "$HOME/.config/opencode/opencode.json"
  "$HOME/.config/opencode2/opencode.json"
  "$HOME/.config/opencode2/AGENTS.md"
  "$HOME/.local/bin/oc2"
@@ -60,6 +61,7 @@ for path in \
  "$HOME/.config/wezterm" \
  "$HOME/.config/nvim" \
  "$HOME/.config/herdr" \
+  "$HOME/.config/opencode/skills" \
  "$HOME/.pi/agent/themes" \
  "$HOME/.pi/agent/extensions/calm"
 do