subwave

Benchmark and compare LLM models for SUB/WAVE's on-air calls — track picks, segments, listener requests, DJ scripts, banter, and programme beats — in both candidate-pool and agent modes, using controller/scripts/llm-bench (the matrix harness) or the legacy picker-only controller/scripts/picker-test.mjs. Use this skill whenever the user wants to assess, benchmark, compare, or test which LLM model to run the station on — phrases like "which model should I use", "benchmark the picker / the DJ / this model", "test these models", "is <model> good enough for the radio", "compare the ollama models", "will a small model work", "run llm-bench", "run picker-test", or when diagnosing slow/failing djAgentPick / djAgentSegment / generate* calls and the model choice is suspect. Trigger it even if the user doesn't name a harness — any request to evaluate model reliability or choose a model for SUB/WAVE belongs here. This skill only measures and recommends; it does NOT change the live station's configured model.

Drive a controller/admin-UI change end-to-end from a worktree without touching the live station — isolated controller on a spare port + temp STATE_DIR, worktree Next dev server, Playwright against /admin.

Draft a Discord release announcement for SUB/WAVE from a release PR, tag, or version number. Use this skill whenever the user wants to "write a Discord announcement / post", "announce the release on Discord", "draft a release announcement", "tell the Discord about vX.Y.Z", "post the release to the community", or hands you a release-please PR / release tag and asks for community copy. The skill knows the house voice (radio-themed, warm, no em-dashes), how to pull the changelog from GitHub, how to translate conventional-commit lines into listener-facing benefits, and to size the post to the release. It outputs a ready-to-paste markdown block; it does NOT post to Discord.

Set up, deploy, or update SUB/WAVE (a personal internet radio station). On a fresh checkout, runs scripts/setup.sh, prompts for Navidrome + Ollama credentials, brings the stack up, and generates jingles. On an already-running stack, pulls the latest, rebuilds only the Docker services whose code actually changed, recreates them, and verifies the stream is on-air. Use this skill any time the user wants to install, set up, bootstrap, deploy, update, sync, redeploy, refresh, restart, or "pull and restart" SUB/WAVE — including phrases like "set up subwave", "install subwave", "first boot", "bootstrap the radio", "pull subwave", "update the radio", "deploy subwave", "rebuild controller", "restart sub-wave", "redeploy after pull", "git pull and restart as needed", "check if the stream is healthy", or simply "deploy" / "install" / "set up" while in the subwave repo. Trigger proactively whenever the user is working in the subwave repo and mentions setting up, installing, deploying, updating, rebuilding, restarting, or

Cut a NEW iOS build of the SUB/WAVE app (the Expo project in `app/`) and ship it via EAS — to TestFlight, and on to the live App Store. The app is LIVE in production on the App Store, so a release is build+submit (one command) then a manual "promote to production" step in App Store Connect. Use this skill whenever the user wants to "submit a build", "release iOS again", "push a new TestFlight build", "ship the iOS app", "release to the App Store", "cut an iOS release", "build and submit for iOS", "send a new build to testers", "deploy the iOS app", "bump the iOS build", or any equivalent phrasing aimed at getting a fresh iOS build out. Trigger it even when the user doesn't say "EAS" or "TestFlight" by name — if they want a new iOS build out, this is the path. The one-time pieces (EAS project link, signing certs, App Store Connect app record, eas.json) already exist, so the build is essentially one command. Do NOT use this for the Android app (that's `subwave-app-android`), for running on a simulator/dev (`exp

Ship a JS/TS-only change to the already-installed SUB/WAVE app (the Expo project in `app/`) over-the-air via EAS Update — no new TestFlight/Play build, no store round-trip. Use this skill whenever the user wants to "send an OTA update", "push this over the air", "ship these changes without a new build", "eas update", "hotfix the app", "do we need a build or can we OTA this?", "publish to the preview/production channel", "get my last commit out to testers", or asks "will my TestFlight / Android beta build get this update?". Trigger it even when the user doesn't say "OTA" or "EAS" by name — if they changed app code and want it on people's phones quickly, this is the path. The skill judges OTA-eligibility (JS/asset change vs. a native change that needs a real build), publishes to a channel, and verifies which installed builds will actually receive it. Do NOT use this when native inputs changed (a dependency add/upgrade, anything under `app/patches/` or `plugins/`, or `app.json` native sections) — that needs a bi

Write a news post for the SUB/WAVE "Dispatches" page, a short human-friendly tutorial about a feature, fix, or release. Use this skill whenever the user wants to "write a news post / dispatch / news article", "announce a feature on the news page", "add a changelog entry to the site", "post an update about <feature>", "write release notes for the site", or "tell people about <what shipped>" for SUB/WAVE. The skill knows where the markdown lives (web/content/news), the frontmatter schema, the what/how/why structure, and that every draft must be run through the `humanizer` skill before saving. It does NOT publish or deploy; it just writes the .md file, and the /news page picks it up on the next build.

Open a release pull request from develop to main for SUB/WAVE, and keep develop from drifting behind main. Summarises the commits queued on develop, groups them by conventional-commit type, opens the PR via gh, and — once the release lands — back-merges main → develop so the release-please version bump and CHANGELOG come across. Trigger this skill whenever the user says "create a release PR", "open a release PR to main", "release to main", "cut a release", "ship to main from develop", "open a develop→main PR", "sync develop with main", "develop is behind main", "back-merge main into develop", or any equivalent phrasing where the goal is to open the develop→main merge that release-please will promote, or to reconcile develop with main afterward. The skill does NOT touch versions, changelogs, or tags directly — release-please workflows on main own all of that downstream.

Analyse the SUB/WAVE radio station's unified event log (state/logs/events-*.jsonl) and give the operator a diagnostic report on how the station is behaving — Navidrome/ Subsonic API call patterns, the DJ picker's behaviour and music-library coverage, and runtime health anomalies. Use this skill whenever the user wants to understand or get feedback on what the radio is doing under the hood: how Navidrome calls are being made and how often, why the picker keeps choosing certain tracks or artists, whether the library pool is too narrow, whether traces are failing or running slow, or asks things like "analyse the subwave logs", "check the radio's behaviour", "what is the picker doing", "why does it keep playing the same artists", "is the station healthy", "how are the navidrome calls looking", "give me feedback on the event log". Trigger this skill even if the user does not name the log file or the script — any request to diagnose, audit, review, or get feedback on SUB/WAVE's runtime behaviour from its logs belon

Stage a SUB/WAVE git worktree so the dev stack can run from it, then start it. A git worktree only checks out tracked files — the dev stack also needs gitignored files (controller/.env, web/.env.local, docker/.env, web/node_modules, and a state/ directory) that this skill copies or scaffolds from the main working tree. Use this skill whenever the user wants to test branch changes in a worktree, run subwave from a worktree, "prep"/"set up" a worktree for dev mode, or asks to copy env files / node_modules / state into a worktree — phrases like "test this worktree in dev mode", "start subwave from the worktree", "prep the worktree", "run my branch locally", "copy the required files into the worktree". Do NOT use it for the main checkout (that's subwave-control) or for production.

Start or stop the SUB/WAVE radio stack (a personal internet radio station) in dev or production mode — no builds, no rebuilds, no config rendering. Use this skill any time the user wants to "start subwave", "stop subwave", "bring up the radio", "shut down the radio", "boot subwave in dev/prod", "turn subwave on/off", "is subwave running?", or otherwise just power the stack up or down. Detects which compose file (dev vs prod) is already running and matches it; if nothing is running, asks dev or prod. Dev mode also launches the Next.js web dev server on :7700 in the background. Always verifies the stream is on-air after a start. Do NOT use this skill for first-time setup, `git pull` + rebuilds, jingle generation, or config changes — that's `subwave-deploy`. If the user asks for any of those, hand off rather than starting.