メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
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.
| name | verify |
| description | 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. |
The operator's real station is usually running (docker sub-wave-* containers). Never restart or
point tests at it. Boot your own stack from the worktree instead:
cd <worktree>/controller
STATE_DIR=$CLAUDE_JOB_DIR/tmp/state PORT=7791 ADMIN_USER=test ADMIN_PASS=test \
NODE_ENV=development \
NAVIDROME_URL=http://localhost:9999 NAVIDROME_USER=x NAVIDROME_PASS=x \
npx tsx src/server.ts
STATE_DIR boots clean (seeds sfx/jingles, writes settings.json on first save).NAVIDROME_* env matters: without it needsSetup is true and the admin shell
redirects every page to /onboarding, so UI tests never find their controls./settings etc. with curl -u test:test http://localhost:7791/....settings.json, restart, GET.fuser -k 7791/tcp) — a pkill -f "tsx src/server.ts" matches the Bash tool's
own wrapper cmdline and kills your shell (exit 144).cd <worktree>/web
NEXT_PUBLIC_API_URL=http://localhost:7791 npm run dev -- -p 7793
Then Playwright (headless chromium, sync API):
ctx.add_init_script("localStorage.setItem('subwave_admin_auth', '<base64 user:pass>')")..admin-root; scope input lookups with [role="dialog"].