kokoro-coreml

Run the controlled bakeoff benchmark on this machine. Prepares inputs, builds the Swift pipeline, runs the counterbalanced harness for all available configs (A, D, E, F), records results, and updates performance-notes.md. Use when the user says "run the bakeoff", "benchmark this machine", or invokes $bakeoff.

Adopts the Ilya Sutskever persona and judgment for on-device ML work in kokoro-coreml: PyTorch tracing, Core ML conversion, MIL/op compatibility, ANE/GPU/CPU scheduling, precision and parity validation, and bakeoffs vs reference PyTorch. Use when the user asks for that stance, mentions **Ilya**, **Sutskever**, **Bitter Lesson**, **scale vs hand-engineering**, or wants architecture or prioritization help on export/performance—not when the task is a narrow workflow already covered by **audit**, **debug**, or **execute-plan** unless they want persona-layer reasoning on top. Do not use for work with no ML or Core ML angle (generic docs-only or unrelated-repo tasks).

Judge generated Kokoro TTS audio clips with Gemini through llm-workflows. Use when the user asks whether synthesized speech sounds good, intelligible, whispery, corrupt, or acceptable, or when comparing PyTorch reference clips against Core ML / Swift pipeline output.

Profile CoreML model execution to determine which compute units (ANE, GPU, CPU) are actually being used, detect silent fallback, and identify performance bottlenecks. Triggered by keywords like "profile", "which compute unit", "is ANE running", "why is it slow", "silent fallback".

Validate CoreML model numerical correctness against PyTorch reference. Runs identical inputs through both pipelines and reports per-output correlation, max error, and pass/fail. Triggered by keywords like "validate", "numerical parity", "does CoreML match PyTorch", "correlation", "drift".

Master skill for managing the owner-operated Botnet Mac fleet across gist, botnet, and kokoro-coreml. Use when checking fleet health, rolling Mac workers, debugging scrape.remote_browser, tts.kokoro_coreml, or precompute workers, handling LaunchAgents, SSH fan-out, Cloudflare control-plane health, Kokoro/Core ML runtime issues, botnet fleet env vars, or writing fleet debugging notes.

Ingests offline deep-research exports into README guides: normalizes messy exports (escapes, data-URI images, Swift snippets), converts to clean markdown, verifies library/API claims with Context7 MCP when needed, adds cross-links across README/Guides and README/Notes, and updates related docs to link back. Use when adding or refreshing a guide from browser-downloaded research, Deep Research output, or similar raw material; when the user says guide-ingest, ingest-guide, research-to-guide, or wants corpus cross-linking for a new guide.

Redirect: cross-repo Core ML master router lives in personal skills. Use ~/.cursor/skills/coreml/SKILL.md for intent routing and guide links across kokoro-coreml and crossfade. Delegates procedures to repo child skills (coreml-validate, coreml-profile, bakeoff, debug).

Applies David Ogilvy–style copy discipline to reader-facing text in kokoro-coreml: README and guides, bakeoff and performance narratives, CLI and script output, error messages, integration notes, and docstrings that read as product copy. Use when the user names **Ogilvy**, **copy**, **copywriting**, **marketing** language, **user-facing** strings, **empty states**, onboarding, or wants persuasive, specific prose grounded in facts. Do not use for implementation-only work with no wording decisions, pure internals with no voice requirement, or layout-only tasks.

Guides users through creating effective Agent Skills for Cursor. Use when you want to create, write, or author a new skill, or asks about skill structure, best practices, or SKILL.md format.

Runs the full multi-agent audit workflow, fixes every issue, re-audits until Architecture, Correctness risk, and Complexity debt are all grade A, then commits via git-commit. Use ONLY when the user explicitly invokes audit-fix-loop, $audit-fix-loop, or “use audit-fix-loop”—not for standalone audits, plan execution, or implicit routing. Does not replace phase-audit or deploy gates.

Execute a checked-in implementation plan like execute-plan (phase-by-phase, commits, push, CI), then run the full audit skill on the execution scope and require Architecture, Correctness risk, and Complexity debt grades all A—fix findings and repeat until all three are A. Use when the user explicitly invokes this skill or wants the hardcore post-audit gate after plan execution. Do not use for planning-only, read-only review, or when the user wants standard execute-plan without the audit-to-A loop.

Execute a checked-in implementation plan for this repo phase by phase. Commits land once per completed phase locally; push and CI monitoring run once after every phase is done (not after each phase). Use when the user provides a concrete plan path and wants end-to-end implementation, phase audits, plan updates, commits, push, and CI monitoring. Do not use for creating a plan, one-off fixes without a checked-in plan, or read-only review work.

Commits any pending work via git-commit, syncs with origin (fetch, merge-oriented pull), pushes the current branch, watches GitHub Actions, and fixes root causes until CI is green—including coverage gates without lowering thresholds. Use when the user asks to push, sync and push, or ship the branch and chase CI. Requires explicit invocation or a parent workflow that authorizes push and CI remediation. Do not use without permission to write to git remote or when the user forbids automated CI fix loops.

Triggered when the user’s message includes the word **audit** (primary routing hook). Findings-first review of the kokoro-coreml repo or a scoped slice (paths, diff, commits)—runs pytest (and optional lint when configured) as mechanical signals, optionally delegates readonly subagents by charter when scope or risk warrants it (**when in doubt, parallelize**), merges and dedupes findings, and assigns A–F grades for architecture, correctness risk, and complexity debt. Do not use when the user wants implementation fixes unless they explicitly ask to fix issues after the audit—for plan-phase checklists against an active plan, prefer phase-audit.

Create an implementation plan for this repo. Use when the user wants a checked-in plan under README/Plans, wants the work scoped into phases, and expects the plan to be built from repo guides and notes first, with Context7 only when current external library or framework behavior materially affects the plan. Do not use for implementing the work, informal brainstorming, or lightweight notes.

Systematic debugging for kokoro-coreml: consult README/ (guides and learnings) and CLAUDE.md first, pull current library docs via Context7 MCP when coremltools/PyTorch/API behavior is uncertain, parallelize investigation with multiple subagents when stuck, prove fixes before calling success, then capture one consolidated note in README/Notes via **write-notes** as the **final** step before ending the session. For extreme cases, delegate a multi-agent audit via the Claude Code CLI. Use when the user invokes **debug**, **use debug**, asks to debug or fix a tricky bug, or work is blocked by unclear failure modes after quick local checks.

Clarifies what “ship” means for kokoro-coreml: there is no Cloudflare-style multi-worker deploy script. Use for tagging releases, pushing the branch, coordinating with the macOS app repo, or verifying exports before handoff. Before treating a revision as releasable, run the repo’s primary checks (see git-commit / audit). Do not use when the user only wants local experiments with no remote or release intent.

Write or review inline code documentation that captures domain knowledge, non-obvious constraints, non-greppable cross-file contracts, and state lifecycle. Use when the task is adding or reviewing Python docstrings, file headers, state docs, or constant rationale. Do not use for README files, markdown docs, plan documents, or code changes where comments are incidental.

Produces comprehensive Git commit messages (what and why) and, when authorized, stages and commits. By default stages the entire working tree (all pending changes), including work from other agents or earlier sessions—not only files the current agent touched. After a successful commit (non-blocking), runs `pytest` at the repo root when available and a **lightweight** read of **HEAD** only (bug risks, god-module smells, needless complexity, duplication)—not a full **audit** (no lint gate, no grades, no multi-agent); for that, the user invokes the **`audit`** skill. Surfacing findings as optional heads-up, never as a reason to block or unwind the commit unless the user asks. No automatic fixes. Message-only requests use the same template without running git until commit is explicitly requested. Also use inside authorized workflows (for example execute-plan phase commits). Do not use for read-only review, hypothetical history, or when git writes are not authorized.

Write or repair repo markdown files. Use when the task is editing README files, guides, plans, notes, or markdown lint failures. Apply the repo's markdown rules, preserve the right template or document structure, and keep prose tight. Do not use for inline code comments or code changes that only happen to touch markdown strings.

Audit a completed plan phase in this repo. Use when a phase has just been implemented and needs a findings-first review against the active plan, changed files, linked guides, and the canonical audit rubric before commit or before moving to the next phase. Do not use for implementing fixes, broad product critique, or replacing tests and CI execution.

Write or update repo notes under README/Notes. Use when the user wants debugging notes, investigation notes, audit notes, or institutional memory captured in the repo. Prefer updating the right high-level notes document over creating a fresh file for every session. Do not use for plans, README guides, or inline code comments.