Clean non-artifact files from model repo

Remove source, build, demo, test, virtualenv, and generated-output files from the Hugging Face model repo while leaving README.md and all existing model/voice artifacts untouched.

.claude/settings.local.json

@@ -1,24 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Bash(wc -l /Users/mm/Documents/GitHub/kokoro-coreml/test_ane_pipeline.py /Users/mm/Documents/GitHub/kokoro-coreml/export_synthesizers.py /Users/mm/Documents/GitHub/kokoro-coreml/export_*.py /Users/mm/Documents/GitHub/kokoro-coreml/test_*.py)",
-      "Bash(wc -l /Users/mm/Documents/GitHub/kokoro-coreml/*.py)",
-      "Bash(ls -lh /Users/mm/Documents/GitHub/kokoro-coreml/*.py)",
-      "Bash(head -20 /Users/mm/Documents/GitHub/kokoro-coreml/export_*.py)",
-      "Bash(grep -l \"def export\" /Users/mm/Documents/GitHub/kokoro-coreml/*.py)",
-      "Bash(grep -l \"export_\" /Users/mm/Documents/GitHub/kokoro-coreml/examples/*.py)",
-      "Bash(grep -n \"def _load_module_from\" /Users/mm/Documents/GitHub/kokoro-coreml/export_*.py)",
-      "Bash(grep -n \"TODO\\\\|FIXME\\\\|XXX\\\\|HACK\\\\|dead\\\\|unused\\\\|deprecated\" /Users/mm/Documents/GitHub/kokoro-coreml/*.py)",
-      "Bash(sed -n '24,50p' /Users/mm/Documents/GitHub/kokoro-coreml/export_duration.py)",
-      "Bash(sed -n '24,50p' /Users/mm/Documents/GitHub/kokoro-coreml/export_f0n_fixed.py)",
-      "Bash(sed -n '38,64p' /Users/mm/Documents/GitHub/kokoro-coreml/export_synthesis_fixed.py)",
-      "Bash(grep -rn \"__all__\" /Users/mm/Documents/GitHub/kokoro-coreml/*.py)",
-      "Bash(ls -la /Users/mm/Documents/GitHub/kokoro-coreml/export_*.py)",
-      "Bash(git rm:*)",
-      "Bash(git add:*)",
-      "Bash(git commit -m ':*)",
-      "Bash(grep -n \"from kokoro._export_utils import\\\\|from.*_export_utils\" /Users/mm/Documents/GitHub/kokoro-coreml/examples/export_coreml.py /Users/mm/Documents/GitHub/kokoro-coreml/export_synth/*.py)",
-      "Bash(grep -n \"_load_module_from\\\\|load_kokoro_for_export\" /Users/mm/Documents/GitHub/kokoro-coreml/export_*.py /Users/mm/Documents/GitHub/kokoro-coreml/examples/*.py)"
-    ]
-  }
-}

.claude/skills/audit/SKILL.md

@@ -1,199 +0,0 @@
----
-name: audit
-description: 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.
----
-
-# Audit
-
-## Purpose
-
-Run a **structured, paranoid-friendly** audit focused on **bugs** and **needless complexity** in this **PyTorch → Core ML** repo. The orchestrator **does not** silently rewrite code; it **surfaces** issues with severity, paths, and letter grades.
-
-**Posture:** use **judgment**. Narrow scope (few files, small diff, localized
-change) can be a **single-agent** pass. **Whole-repo**, **large diff**, **high
-blast radius**, or **you are unsure** → prefer **multiple readonly subagents in
-parallel** (one turn, several `Task` calls), each with a **narrow charter**, then
-**merge and dedupe** into one report. **When in doubt, use multiple agents.**
-
-## Use When
-
-- The user’s message includes **`audit`** as a substring (primary trigger)—e.g.
-  **audit**, **audit this**, **security audit**, **use the audit skill** (case
-  insensitive in normal routing).
-
-## Do Not Use When
-
-- The user wants **implementation** only—unless they ask for fixes **after**
-  the audit lands.
-- The work is **only** validating an `execute-plan` phase against the plan and
-  rubric—use **`phase-audit`** instead (this skill is broader).
-
-## Scope (ask or infer once)
-
-Establish **audit scope** before delegating:
-
-| Kind | How to bound |
-| --- | --- |
-| **Whole codebase** | Repo root; subagents apportion by area (`kokoro/`, `examples/`, `coreml/`, `kokoro.js/`, export scripts) or by charter only. |
-| **Paths** | User-provided globs or directories; all charters focus there. |
-| **Git delta** | User provides base (`main`, `origin/main`, tag) or “last N commits”; use `git diff`, `git log -n`, `git diff-tree --name-only`. |
-| **Single feature** | User names flows (e.g. “duration export”, “decoder-only 3s”); map to directories from `README.md` and `README/*.md`. |
-
-State the **chosen scope** in the final report header.
-
-## Mechanical signals (orchestrator, once)
-
-From **repository root**, when the audited surface includes **Python** (default for this repo):
-
-1. **`pytest`** — run the test suite when pytest is installed (`python -m pytest` if needed).
-2. **Lint** — only if the repo defines a standard lint command (e.g. in `pyproject.toml` or docs); otherwise skip and note “no configured lint.”
-
-Report failures as **P0 / Critical** findings with command output (summarize if
-huge). Do not “fix” unless the user later asks.
-
-**Optional:** targeted **`kokoro.js`** checks (`npm test` in `kokoro.js/`) when the
-change touches the JS package; failures are **P0** for that surface.
-
-When subagents run, they should assume mechanical checks ran **once**; they
-focus on **review**, not on re-running gates unless a charter requires
-spot-checking a file.
-
-## Subagent delegation (use judgment)
-
-**When one agent is enough:** tiny or localized scope (e.g. a handful of files,
-one worker, or a single focused diff); low coupling; user asked for a quick
-pass. The orchestrator performs the full charter coverage **solo** (still hit
-architecture, correctness, security/ops, and complexity—just in one pass).
-
-**When to parallelize:** whole-repo or multi-package audit; large `git` range;
-security- or money-sensitive paths; queue/cron/webhook/idempotency concerns; or
-**any uncertainty** about depth. **When in doubt, launch parallel subagents.**
-
-**If parallelizing:** in **one assistant turn**, launch **up to four**
-`Task` subagents with `readonly: true`, **`subagent_type`:** `generalPurpose`
-(or `explore` when the request is mostly mapping file layout). Use **`model: fast`**
-unless the user asks for maximum depth. You may use **fewer than four** if scope
-is medium (e.g. two agents—correctness+security vs architecture+complexity).
-
-Give each subagent:
-
-- The **exact scope** (paths, diff summary, or “whole repo”).
-- One **charter** from below (copy the charter text into the task prompt).
-- Instruction: **concrete file paths**, **severity** (P0–P3), **one paragraph
-  max per finding**, **no generic advice**.
-
-### Charter 1 — Architecture & modules
-
-God modules; separation between **export scripts**, **`kokoro/`** library code,
-and **runtime-facing** `coreml/` artifacts; public surfaces; fan-in choke points;
-misplaced orchestration vs model math. Flag files approaching **~1000 LOC** or
-cramming unrelated responsibilities (**repo norm:** well under 1k LOC per file).
-
-### Charter 2 — Correctness & reliability
-
-Logic bugs; tensor shape mistakes; tracing/export mismatches; numerical drift;
-error paths; swallowed exceptions; **async** misuse in JS if in scope; boundary
-conditions for **static buckets** and Swift-side alignment; Core ML runtime
-assumptions vs actual graphs.
-
-### Charter 3 — Security, privacy, operational
-
-Secrets in logs or committed credentials; unsafe subprocess usage; obvious **path**
-or **checkpoint** foot-guns; operational mismatches between **documented I/O**
-and code **when relevant to scope**.
-
-### Charter 4 — Complexity, duplication, maintainability
-
-Needless abstraction; configuration or branching explosion; **duplication with
-drift** between export paths; dead code; **comment/doc lies** vs `README/` or
-`CLAUDE.md`; weak tests; naming that hides behavior.
-
-## Consolidation (orchestrator)
-
-After **subagents return** or after a **solo** review pass:
-
-1. **Dedupe:** merge findings that cite the same root cause or file+theme.
-2. **Severity:** **P0** critical (wrongness, security, data loss, build breaks),
-   **P1** high, **P2** medium, **P3** low / hygiene.
-3. **Grades:** assign three letter grades **A–F** using [Grading rubric](#grading-rubric).
-   **Overall grade = worst of the three** (if any dimension is **D**, overall
-   cannot be **B** or higher—cap at **D** unless you justify an exception in one
-   sentence).
-4. **New teammate test:** one line—would a newcomer likely break this area in
-   week one? (y/n + why)
-
-## Grading rubric
-
-Assign **Architecture**, **Correctness risk**, and **Complexity debt** separately.
-
-| Grade | Meaning |
-| --- | --- |
-| **A** | Clear boundaries, hard to misuse, simple where it matters, issues are cosmetic. |
-| **B** | Solid with minor debt; a few focused fixes would raise to A. |
-| **C** | Meaningful issues; would block merges in a strict shop without a plan. |
-| **D** | Serious structural or reliability risk; bounded scope but unsafe. |
-| **F** | Unsafe, incomprehensible, or broken; needs pause and redesign or revert. |
-
-**Correctness risk** includes likelihood of **latent bugs** and **failure-mode**
-holes—not only existing failing tests.
-
-## Output template
-
-```text
-## Audit scope
-- ...
-
-## Mechanical checks
-- pytest: pass | fail (summary)
-- lint (if configured): pass | fail (summary)
-- kokoro.js tests (if run): ...
-
-## Grades
-- Architecture: ?
-- Correctness risk: ?
-- Complexity debt: ?
-- Overall (worst-of-three): ?
-
-## Findings (severity order)
-### P0 — Critical
-- ...
-
-### P1 — High
-- ...
-
-### P2 — Medium
-- ...
-
-### P3 — Low
-- ...
-
-## Delegation / overlap notes
-- Solo vs N subagents; deduped: ...
-
-## Residual risks / what we did not run
-- ...
-
-## New teammate test
-- ...
-```
-
-## Anti-patterns
-
-- **Whole-repo or high-risk audit in a single shallow pass** when depth was
-  needed—**when in doubt, parallelize.**
-- **Four subagents for a three-line diff**—wasted latency; judge proportionally.
-- **Findings without paths**—every substantive issue should anchor to a file or
-  symbol when possible.
-- **Auto-implementing** during audit when the user only asked for review.
-- **Grade inflation**—if Correctness is **D**, overall is not **B**.
-- **Ignoring mechanical failures**—typecheck/lint red is at least **P0** for
-  code health.
-
-## Relation to other skills
-
-- **`phase-audit`:** plan-phase completion vs rubric and plan checkboxes.
-- **`git-commit`:** post-commit **non-blocking** **`pytest`** + **`HEAD`** diff
-  scan only—**not** a substitute for **`audit`** (no full matrix by default, no
-  grades, no multi-agent).
-- **`deploy`:** defines what “ship” means here (no Cloudflare scripts); audit does
-  not replace user-intent release checks.

.claude/skills/create-plan/SKILL.md

@@ -1,64 +0,0 @@
----
-name: create-plan
-description: 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.
----
-
-# Create Plan
-
-## Purpose
-
-Use this skill to turn a concrete request into a repo-native implementation
-plan. The output is a real plan file under `README/Plans/...`, not a chat-only
-outline.
-
-## Use When
-
-- The work is large enough to need a real implementation plan.
-- The user wants a plan written into the repo.
-- The implementation needs phases, verification steps, and concrete files.
-
-## Do Not Use When
-
-- The user wants direct implementation instead of planning.
-- The request is still too vague to scope honestly.
-- The output should be a note, scratchpad, or brainstorm instead of a plan.
-
-## Procedure
-
-1. Read [references/index.md](references/index.md) first.
-2. Gather repo context in this order:
-   - directly related `README/Guides`
-   - directly related `README/Notes`
-   - `README/Skills` when the work touches plan workflow, skills, or routing
-   - neighboring plans in the target `README/Plans/...` subtree
-3. Use Context7 only when the plan depends on current library, framework, or
-   API behavior that may have changed.
-4. If Context7 is insufficient, fall back to official vendor docs.
-5. Choose the most specific existing `README/Plans/...` subdirectory that fits
-   the work. If none fits cleanly, place the plan in the closest higher-level
-   subtree instead of inventing a noisy new folder.
-6. Write the plan with the repo's canonical template and make it implementation
-   ready:
-   - concrete phases
-   - specific files where knowable
-   - verification per phase
-   - hard requirements
-   - rollback or kill switch when relevant
-7. Audit the draft before stopping:
-   - no missing policy that an implementer would have to invent
-   - no fake certainty where the repo context is incomplete
-   - no implementation work performed while planning
-
-## Canonical Docs
-
-Read [references/index.md](references/index.md) first. It maps the canonical
-workflow guide, the plan template, and the repo references to inspect before
-writing a new plan.
-
-## Handoff Rules
-
-- Hand off to `execute-plan` only after the plan is checked in and the user
-  wants implementation.
-- Hand off to a domain skill only if the planning request narrows into a
-  domain-specific technical question that must be answered before the plan can
-  be completed.

.claude/skills/create-plan/references/index.md

@@ -1,20 +0,0 @@
-# Create Plan References
-
-Canonical docs for `create-plan`.
-
-- `README/Skills/plan-workflow-skills-guide.md`
-  Read first for the shared workflow contract and the required research order.
-- `README/Templates/Plans-template.md`
-  Read for the exact structure and required sections of the final plan.
-
-Use **`README/Skills/`** when the plan touches repo skills, routing, or skill
-authoring (the workflow guide covers boundaries and progressive disclosure; use
-other files in that folder as canonical skill docs are added). For the live skill
-inventory, inspect `.claude/skills/` (`.cursor/skills` and `.agents/skills` symlink here in this repo).
-
-Also inspect:
-
-- the most relevant `README/Guides/...` and `README/Notes/...` files for the
-  task domain
-- neighboring plans in the target `README/Plans/...` subtree for local style and
-  naming patterns

.claude/skills/create-skill/SKILL.md

@@ -1,557 +0,0 @@
----
-name: create-skill
-description: >-
-  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.
----
-# Creating Skills in Cursor
-
-This skill guides you through creating effective Agent Skills for Cursor. Skills are markdown files that teach the agent how to perform specific tasks: reviewing PRs using team standards, generating commit messages in a preferred format, querying database schemas, or any specialized workflow.
-
-## Default: mirror personal skills everywhere
-
-When the user wants a **personal (global) skill**—not something checked into a single repo—**treat “create this skill” as “create it for Cursor, Claude Code, Codex, and Agents”** unless they **explicitly** narrow scope (examples: “Cursor only”, “don’t touch ~/.agents”, “repo skill only”).
-
-**Mirror targets** (same directory layout: `skill-name/SKILL.md`). Write one canonical `SKILL.md`, then install **identical** copies under:
-
-| # | Path | Load by |
-|---|------|--------|
-| 1 | `~/.cursor/skills/skill-name/` | Cursor (personal) |
-| 2 | `~/.claude/skills/skill-name/` | Claude Code (user) |
-| 3 | `~/.codex/skills/skill-name/` | Codex |
-| 4 | `~/.agents/skills/skill-name/` | Agents layouts that read `~/.agents/skills` |
-
-`~/.codex/skills/.system/` is bundled—**never** mirror into `.system/`; only into sibling `skill-name/` folders.
-
-**Implementation habit:** after authoring `SKILL.md`, run `mkdir -p` for each path above and **copy the same file** (or write once and `cp` to each root). If a directory does not exist yet, create it—avoid leaving a skill in only one tree.
-
-## Default: project skills triple mirror (repo)
-
-When **creating** a new **project** skill (checked into a repository), **always** install the **same** `SKILL.md` (and any `reference.md` / `scripts/` siblings) in all of:
-
-| # | Path | Tool |
-|---|------|------|
-| 1 | `.cursor/skills/skill-name/` | Cursor |
-| 2 | `.claude/skills/skill-name/` | Claude Code |
-| 3 | `.agents/skills/skill-name/` | Codex (Agents convention in this repo) |
-
-Skip a path only when the user **explicitly** narrows scope (e.g. “Cursor only in this repo”).
-
-**kokoro-coreml:** `.cursor/skills` and `.agents/skills` are **symlinks** to `.claude/skills` (see `ls -la .cursor/skills .agents/skills`). **Edit only** under `.claude/skills/`—Cursor and Agents resolve the same files; do not maintain duplicate trees.
-
-**Project skills** (repo) **do not** automatically go under `~/` unless the user asks. In **kokoro-coreml**, adding a skill means creating it under **`.claude/skills/`** only (Cursor/Agents paths are symlinks). In other repos, use the **triple mirror** above—**one** source of truth, identical copies or symlinks.
-
-## Before You Begin: Gather Requirements
-
-Before creating a skill, gather essential information from the user about:
-
-1. **Purpose and scope**: What specific task or workflow should this skill help with?
-2. **Target location**: **Personal** → default [mirror everywhere](#default-mirror-personal-skills-everywhere). **Project** → default [triple mirror](#default-project-skills-triple-mirror-repo) (`.cursor/`, `.claude/`, `.agents/`); do not install under `~/` unless the user asks. Confirm any explicit **single-tool** exception before skipping a mirror path.
-3. **Trigger scenarios**: When should the agent automatically apply this skill?
-4. **Key domain knowledge**: What specialized information does the agent need that it wouldn't already know?
-5. **Output format preferences**: Are there specific templates, formats, or styles required?
-6. **Existing patterns**: Are there existing examples or conventions to follow?
-
-### Inferring from Context
-
-If you have previous conversation context, infer the skill from what was discussed. You can create skills based on workflows, patterns, or domain knowledge that emerged in the conversation.
-
-### Gathering Additional Information
-
-If you need clarification, use the AskQuestion tool when available:
-
-```
-Example AskQuestion usage:
-- "Where should this skill be stored?" with options like ["Personal—mirror Cursor + Claude + Codex + ~/.agents (default)", "Project—triple mirror .cursor + .claude + .agents (default)", "Single-tool exception (explicit)"]
-- "Should this skill include executable scripts?" with options like ["Yes", "No"]
-```
-
-If the AskQuestion tool is not available, ask these questions conversationally.
-
----
-
-## Skill File Structure
-
-### Directory Layout
-
-Skills are stored as directories containing a `SKILL.md` file:
-
-```
-skill-name/
-├── SKILL.md              # Required - main instructions
-├── reference.md          # Optional - detailed documentation
-├── examples.md           # Optional - usage examples
-└── scripts/              # Optional - utility scripts
-    ├── validate.py
-    └── helper.sh
-```
-
-### Storage Locations
-
-| Type | Path | Scope |
-|------|------|-------|
-| Personal | ~/.cursor/skills/skill-name/ | Available across all your projects |
-| Project | .cursor/skills/skill-name/ | Cursor (repo; shared with team) |
-| Project | .claude/skills/skill-name/ | Claude Code (repo; shared with team) |
-| Project | .agents/skills/skill-name/ | Codex / Agents (repo; **same** files as `.claude` when symlinked) |
-
-**Project default:** When adding a new checked-in skill, create it in **Cursor**, **Claude Code**, and **Codex** locations above (see [Default: project skills triple mirror (repo)](#default-project-skills-triple-mirror-repo)).
-
-**IMPORTANT**: Never create **your** skills in `~/.cursor/skills-cursor/`. That directory is for Cursor-shipped defaults (including this `create-skill` document). Cursor may replace files there on upgrade—if you customize something under `skills-cursor`, keep a backup or maintain your own copy under `~/.cursor/skills/`.
-
-### Same skill in Claude Code, Codex, or Agents
-
-Other assistants use their own user-level trees (same layout: `skill-name/SKILL.md`):
-
-| Tool | Typical user skills path | Notes |
-|------|--------------------------|--------|
-| Claude Code | ~/.claude/skills/skill-name/ | Repo-specific skills can also live in `.claude/skills/` inside a project |
-| Codex | ~/.codex/skills/skill-name/ | Often alongside `~/.codex/skills/.system/` (bundled); do not edit `.system` |
-| Agents | ~/.agents/skills/skill-name/ | Separate tree from Codex; not every install has it |
-
-For **personal** skills, follow [Default: mirror personal skills everywhere](#default-mirror-personal-skills-everywhere): **repo-agnostic** text when the skill should work in any checkout, then **identical `SKILL.md`** in each user-level path (not “on request”—**unless** the user opted out of a tool).
-
-### SKILL.md Structure
-
-Every skill requires a `SKILL.md` file with YAML frontmatter and markdown body:
-
-```markdown
----
-name: your-skill-name
-description: Brief description of what this skill does and when to use it
----
-
-# Your Skill Name
-
-## Instructions
-Clear, step-by-step guidance for the agent.
-
-## Examples
-Concrete examples of using this skill.
-```
-
-### Required Metadata Fields
-
-| Field | Requirements | Purpose |
-|-------|--------------|---------|
-| `name` | Max 64 chars, lowercase letters/numbers/hyphens only | Unique identifier for the skill |
-| `description` | Max 1024 chars, non-empty | Helps agent decide when to apply the skill |
-
----
-
-## Writing Effective Descriptions
-
-The description is **critical** for skill discovery. The agent uses it to decide when to apply your skill.
-
-### Description Best Practices
-
-1. **Write in third person** (the description is injected into the system prompt):
-   - ✅ Good: "Processes Excel files and generates reports"
-   - ❌ Avoid: "I can help you process Excel files"
-   - ❌ Avoid: "You can use this to process Excel files"
-
-2. **Be specific and include trigger terms**:
-   - ✅ Good: "Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction."
-   - ❌ Vague: "Helps with documents"
-
-3. **Include both WHAT and WHEN**:
-   - WHAT: What the skill does (specific capabilities)
-   - WHEN: When the agent should use it (trigger scenarios)
-
-### Description Examples
-
-```yaml
-# PDF Processing
-description: Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
-
-# Excel Analysis
-description: Analyze Excel spreadsheets, create pivot tables, generate charts. Use when analyzing Excel files, spreadsheets, tabular data, or .xlsx files.
-
-# Git Commit Helper
-description: Generate descriptive commit messages by analyzing git diffs. Use when the user asks for help writing commit messages or reviewing staged changes.
-
-# Code Review
-description: Review code for quality, security, and best practices following team standards. Use when reviewing pull requests, code changes, or when the user asks for a code review.
-```
-
----
-
-## Core Authoring Principles
-
-### 1. Concise is Key
-
-The context window is shared with conversation history, other skills, and requests. Every token competes for space.
-
-**Default assumption**: The agent is already very smart. Only add context it doesn't already have.
-
-Challenge each piece of information:
-- "Does the agent really need this explanation?"
-- "Can I assume the agent knows this?"
-- "Does this paragraph justify its token cost?"
-
-**Good (concise)**:
-```markdown
-## Extract PDF text
-
-Use pdfplumber for text extraction:
-
-\`\`\`python
-import pdfplumber
-
-with pdfplumber.open("file.pdf") as pdf:
-    text = pdf.pages[0].extract_text()
-\`\`\`
-```
-
-**Bad (verbose)**:
-```markdown
-## Extract PDF text
-
-PDF (Portable Document Format) files are a common file format that contains
-text, images, and other content. To extract text from a PDF, you'll need to
-use a library. There are many libraries available for PDF processing, but we
-recommend pdfplumber because it's easy to use and handles most cases well...
-```
-
-### 2. Keep SKILL.md Under 500 Lines
-
-For optimal performance, the main SKILL.md file should be concise. Use progressive disclosure for detailed content.
-
-### 3. Progressive Disclosure
-
-Put essential information in SKILL.md; detailed reference material in separate files that the agent reads only when needed.
-
-```markdown
-# PDF Processing
-
-## Quick start
-[Essential instructions here]
-
-## Additional resources
-- For complete API details, see [reference.md](reference.md)
-- For usage examples, see [examples.md](examples.md)
-```
-
-**Keep references one level deep** - link directly from SKILL.md to reference files. Deeply nested references may result in partial reads.
-
-### 4. Set Appropriate Degrees of Freedom
-
-Match specificity to the task's fragility:
-
-| Freedom Level | When to Use | Example |
-|---------------|-------------|---------|
-| **High** (text instructions) | Multiple valid approaches, context-dependent | Code review guidelines |
-| **Medium** (pseudocode/templates) | Preferred pattern with acceptable variation | Report generation |
-| **Low** (specific scripts) | Fragile operations, consistency critical | Database migrations |
-
----
-
-## Common Patterns
-
-### Template Pattern
-
-Provide output format templates:
-
-```markdown
-## Report structure
-
-Use this template:
-
-\`\`\`markdown
-# [Analysis Title]
-
-## Executive summary
-[One-paragraph overview of key findings]
-
-## Key findings
-- Finding 1 with supporting data
-- Finding 2 with supporting data
-
-## Recommendations
-1. Specific actionable recommendation
-2. Specific actionable recommendation
-\`\`\`
-```
-
-### Examples Pattern
-
-For skills where output quality depends on seeing examples:
-
-```markdown
-## Commit message format
-
-**Example 1:**
-Input: Added user authentication with JWT tokens
-Output:
-\`\`\`
-feat(auth): implement JWT-based authentication
-
-Add login endpoint and token validation middleware
-\`\`\`
-
-**Example 2:**
-Input: Fixed bug where dates displayed incorrectly
-Output:
-\`\`\`
-fix(reports): correct date formatting in timezone conversion
-
-Use UTC timestamps consistently across report generation
-\`\`\`
-```
-
-### Workflow Pattern
-
-Break complex operations into clear steps with checklists:
-
-```markdown
-## Form filling workflow
-
-Copy this checklist and track progress:
-
-\`\`\`
-Task Progress:
-- [ ] Step 1: Analyze the form
-- [ ] Step 2: Create field mapping
-- [ ] Step 3: Validate mapping
-- [ ] Step 4: Fill the form
-- [ ] Step 5: Verify output
-\`\`\`
-
-**Step 1: Analyze the form**
-Run: \`python scripts/analyze_form.py input.pdf\`
-...
-```
-
-### Conditional Workflow Pattern
-
-Guide through decision points:
-
-```markdown
-## Document modification workflow
-
-1. Determine the modification type:
-
-   **Creating new content?** → Follow "Creation workflow" below
-   **Editing existing content?** → Follow "Editing workflow" below
-
-2. Creation workflow:
-   - Use docx-js library
-   - Build document from scratch
-   ...
-```
-
-### Feedback Loop Pattern
-
-For quality-critical tasks, implement validation loops:
-
-```markdown
-## Document editing process
-
-1. Make your edits
-2. **Validate immediately**: \`python scripts/validate.py output/\`
-3. If validation fails:
-   - Review the error message
-   - Fix the issues
-   - Run validation again
-4. **Only proceed when validation passes**
-```
-
----
-
-## Utility Scripts
-
-Pre-made scripts offer advantages over generated code:
-- More reliable than generated code
-- Save tokens (no code in context)
-- Save time (no code generation)
-- Ensure consistency across uses
-
-```markdown
-## Utility scripts
-
-**analyze_form.py**: Extract all form fields from PDF
-\`\`\`bash
-python scripts/analyze_form.py input.pdf > fields.json
-\`\`\`
-
-**validate.py**: Check for errors
-\`\`\`bash
-python scripts/validate.py fields.json
-# Returns: "OK" or lists conflicts
-\`\`\`
-```
-
-Make clear whether the agent should **execute** the script (most common) or **read** it as reference.
-
----
-
-## Anti-Patterns to Avoid
-
-### 1. Windows-Style Paths
-- ✅ Use: `scripts/helper.py`
-- ❌ Avoid: `scripts\helper.py`
-
-### 2. Too Many Options
-```markdown
-# Bad - confusing
-"You can use pypdf, or pdfplumber, or PyMuPDF, or..."
-
-# Good - provide a default with escape hatch
-"Use pdfplumber for text extraction.
-For scanned PDFs requiring OCR, use pdf2image with pytesseract instead."
-```
-
-### 3. Time-Sensitive Information
-```markdown
-# Bad - will become outdated
-"If you're doing this before August 2025, use the old API."
-
-# Good - use an "old patterns" section
-## Current method
-Use the v2 API endpoint.
-
-## Old patterns (deprecated)
-<details>
-<summary>Legacy v1 API</summary>
-...
-</details>
-```
-
-### 4. Inconsistent Terminology
-Choose one term and use it throughout:
-- ✅ Always "API endpoint" (not mixing "URL", "route", "path")
-- ✅ Always "field" (not mixing "box", "element", "control")
-
-### 5. Vague Skill Names
-- ✅ Good: `processing-pdfs`, `analyzing-spreadsheets`
-- ❌ Avoid: `helper`, `utils`, `tools`
-
----
-
-## Skill Creation Workflow
-
-When helping a user create a skill, follow this process:
-
-### Phase 1: Discovery
-
-Gather information about:
-1. The skill's purpose and primary use case
-2. Storage location (**personal** → confirm default full mirror vs explicit single-tool exception; **project** → default triple mirror unless explicit exception)
-3. Trigger scenarios
-4. Any specific requirements or constraints
-5. Existing examples or patterns to follow
-
-If you have access to the AskQuestion tool, use it for efficient structured gathering. Otherwise, ask conversationally.
-
-### Phase 2: Design
-
-1. Draft the skill name (lowercase, hyphens, max 64 chars)
-2. Write a specific, third-person description
-3. Outline the main sections needed
-4. Identify if supporting files or scripts are needed
-
-### Phase 3: Implementation
-
-1. Create the directory structure
-2. Write the SKILL.md file with frontmatter
-3. Create any supporting reference files
-4. Create any utility scripts if needed
-5. **Personal skills:** mirror the skill directory (at minimum `SKILL.md`; include `reference.md` / `scripts/` if present) to **`~/.cursor/skills/`**, **`~/.claude/skills/`**, **`~/.codex/skills/`**, and **`~/.agents/skills/`**, unless the user specified an exception. Do not stop after the first path.
-6. **Project skills:** mirror to **`.cursor/skills/`**, **`.claude/skills/`**, and **`.agents/skills/`** at the repository root (identical `SKILL.md`), unless the user specified an exception. Do not stop after the first path. If `.agents/skills` symlinks to `.claude/skills`, confirm the new skill is visible under both paths.
-
-### Phase 4: Verification
-
-1. Verify the SKILL.md is under 500 lines
-2. Check that the description is specific and includes trigger terms
-3. Ensure consistent terminology throughout
-4. Verify all file references are one level deep
-5. **Personal skills:** confirm the same `SKILL.md` exists in every mirror path (no stray single-tool install)
-6. **Project skills:** confirm the same `SKILL.md` exists under `.cursor/skills/`, `.claude/skills/`, and `.agents/skills/` (or symlink equivalence for `.agents`)
-7. Test that the skill can be discovered and applied
-
----
-
-## Complete Example
-
-Here's a complete example of a well-structured skill:
-
-**Directory structure:**
-```
-code-review/
-├── SKILL.md
-├── STANDARDS.md
-└── examples.md
-```
-
-**SKILL.md:**
-```markdown
----
-name: code-review
-description: Review code for quality, security, and maintainability following team standards. Use when reviewing pull requests, examining code changes, or when the user asks for a code review.
----
-
-# Code Review
-
-## Quick Start
-
-When reviewing code:
-
-1. Check for correctness and potential bugs
-2. Verify security best practices
-3. Assess code readability and maintainability
-4. Ensure tests are adequate
-
-## Review Checklist
-
-- [ ] Logic is correct and handles edge cases
-- [ ] No security vulnerabilities (SQL injection, XSS, etc.)
-- [ ] Code follows project style conventions
-- [ ] Functions are appropriately sized and focused
-- [ ] Error handling is comprehensive
-- [ ] Tests cover the changes
-
-## Providing Feedback
-
-Format feedback as:
-- 🔴 **Critical**: Must fix before merge
-- 🟡 **Suggestion**: Consider improving
-- 🟢 **Nice to have**: Optional enhancement
-
-## Additional Resources
-
-- For detailed coding standards, see [STANDARDS.md](STANDARDS.md)
-- For example reviews, see [examples.md](examples.md)
-```
-
----
-
-## Summary Checklist
-
-Before finalizing a skill, verify:
-
-### Core Quality
-- [ ] Description is specific and includes key terms
-- [ ] Description includes both WHAT and WHEN
-- [ ] Written in third person
-- [ ] SKILL.md body is under 500 lines
-- [ ] Consistent terminology throughout
-- [ ] Examples are concrete, not abstract
-
-### Structure
-- [ ] File references are one level deep
-- [ ] Progressive disclosure used appropriately
-- [ ] Workflows have clear steps
-- [ ] No time-sensitive information
-
-### Personal (global) skills
-- [ ] Mirrored to `~/.cursor/skills/`, `~/.claude/skills/`, `~/.codex/skills/`, and `~/.agents/skills/` unless the user explicitly excluded a target
-
-### Project (repo) skills
-- [ ] Identical `SKILL.md` under `.cursor/skills/`, `.claude/skills/`, and `.agents/skills/` (or confirm `.agents/skills` → `.claude/skills` symlink so one write covers Claude + Codex)
-
-### If Including Scripts
-- [ ] Scripts solve problems rather than punt
-- [ ] Required packages are documented
-- [ ] Error handling is explicit and helpful
-- [ ] No Windows-style paths

.claude/skills/debug/SKILL.md

@@ -1,129 +0,0 @@
----
-name: debug
-description: >-
-  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.
----
-
-# Debug
-
-## Purpose
-
-Reduce guesswork: **README/ and CLAUDE.md first**, **Context7 when library
-behavior is uncertain**, **parallel hypotheses when stuck**, **proof before
-“fixed”**, **one write-notes pass at session end**, **CLI multi-agent audit**
-only for exceptional escalation.
-
-## Use When
-
-- The user says **debug**, **use the debug skill**, **debug this**, or the task
-  is **bug investigation** / **root-cause** analysis that is stalling.
-- Failures involve **coremltools**, **PyTorch**, **Core ML runtime**, or **Swift
-  integration** where training data may be stale—use Context7 before assuming
-  APIs.
-
-## Do Not Use When
-
-- The user only wants a **trivial fix** with an obvious stack trace and no doc
-  ambiguity (still skim `README/` if the area is known to be finicky).
-- The task is **greenfield feature build** with no defect.
-
-## Workflow (in order)
-
-### 1. Read repo knowledge first (mandatory)
-
-Before writing code or deep-diving the stack:
-
-1. **Skim `README/`** for files that match the subsystem (conversion, export,
-   Core ML runtime, tokenizer bridge, `kokoro.js`, etc.). Open the most relevant
-   guides and look for **known issues**, **workarounds**, and **checklists**.
-2. **Skim `README/Notes/`** (when present) and high-level docs linked from
-   `README.md` for past investigations.
-3. Read **`CLAUDE.md`** for PyTorch → Core ML playbook constraints (static
-   shapes, ANE layout, divide-and-conquer).
-
-### 2. Context7 MCP (library and platform docs)
-
-When the bug touches **coremltools**, **PyTorch**, **Swift Core ML**, or related
-APIs:
-
-1. Use **Context7**: resolve the library ID, then fetch focused docs for the API
-   or behavior in question.
-2. Prefer Context7 over memory or generic web search **for API shape and
-   version-sensitive behavior**.
-
-If Context7 is unavailable, fall back to official docs—**do not** invent APIs.
-
-### 3. Reproduce and narrow
-
-- Confirm **minimal repro** or the exact **export step / predict call / log
-  line** that fails.
-- State a **one-sentence hypothesis** and what evidence would falsify it.
-
-### 4. Parallel investigation when stuck
-
-If the problem is **hard**, **cross-cutting**, or you have been **going in
-circles** after the reproduce-and-narrow pass:
-
-- In **one turn**, spin up **multiple** `Task` subagents with **`readonly: true`**
-  and **narrow charters** (e.g. “MIL/export path only”, “Swift shapes only”).
-- **Merge** overlapping hypotheses; avoid duplicate deep reads of the same file.
-
-**When in doubt, parallelize** (same posture as **`audit`**, but
-hypothesis-driven).
-
-### 5. Exceptionally frustrating bugs — CLI + audit
-
-When **still stuck** after parallel investigation, or blast radius is **high**:
-
-1. Use the **Claude Code CLI** from the repo root to run a **multi-agent `audit`**
-   over the **scoped slice** that matters.
-2. In the handoff, cite relevant **`README/`** paths, **symptom + ruled-out
-   items**, and instruct use of the **`audit`** skill with readonly subagents.
-
-Escalation only—**after** README, Context7, and a fair parallel pass.
-
-### 6. Prove the fix (before claiming success)
-
-Do **not** say **fixed** until there is **objective proof**: failing test passes,
-export completes, Core ML predict matches tolerance, bad log line absent—whatever
-matches the bug.
-
-### 7. Write notes once (mandatory last step)
-
-**After** investigation, perform **a single** `README/Notes/` update using
-[**`write-notes`**](../write-notes/SKILL.md) (consolidate the session).
-
-- One pass: symptom, repro, ruled out, root cause (`TBD` if unknown), fix,
-  **verification** (proven / not), pointers to guides.
-- **Skip** only when the user explicitly wants no note or the outcome is trivial.
-
-## Output expectations
-
-- **What was read** from `README/` / `CLAUDE.md` (paths).
-- **Verification:** what proved the fix (or **unverified** / **blocked**).
-- **Which note file(s)** were updated in step 7 (or why skipped).
-- **Whether Context7** was used and for which topic.
-- **Leading hypothesis(es)** if still open, else **root cause** summary.
-
-## Anti-patterns
-
-- Skipping **`README/`** / **`CLAUDE.md`** to “save time.”
-- Assuming API behavior without **Context7 or official docs** when versions
-  matter.
-- **Serial** thrashing instead of **parallel** charters.
-- **Declaring victory** without **verification**.
-- **Patching notes throughout** instead of **one** end-of-session pass.
-
-## Relation to other skills
-
-- **`audit`:** structured review; use via CLI escalation when debug maxes out.
-- **`write-notes`:** once at end of debug session.
-- **`phase-audit`:** plan-phase checks—not the same as production debugging.

.claude/skills/deploy/SKILL.md

@@ -1,67 +0,0 @@
----
-name: deploy
-description: >-
-  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.
----
-
-# Deploy (kokoro-coreml)
-
-## Purpose
-
-This repository is a **PyTorch → Core ML** conversion and model-artifact tree for
-Kokoro TTS. It is **not** the Roast Cloudflare monorepo: there are **no**
-`pnpm deploy:*` scripts or Workers/Pages pipelines here.
-
-“Deploy” in this context means **release engineering** appropriate to this repo:
-
-- **Git:** push branches, tags, or PRs (often via **`git-push`**).
-- **Artifacts:** `.mlpackage` bundles under `coreml/`, checkpoints, and export
-  scripts consumed by a separate macOS app (e.g. TalkToMe).
-- **Verification:** run **`pytest`** (or targeted export smoke scripts) before
-  declaring a revision ready for downstream integration.
-
-## Default interpretation
-
-- **“Ship it” / “deploy”** → confirm what the user means: **push to GitHub**,
-  **cut a tag**, or **hand models to the app**—not a cloud deploy unless they
-  name another system.
-
-## Pre-ship gate (recommended)
-
-From the **repository root**, when a change touches **Python export, Core ML, or
-tests**:
-
-1. **`pytest`** (full test pass when tests are present).
-2. If the change is export-only, at minimum run the **relevant** `examples/` or
-   `test_*.py` scripts the guides mention.
-
-There is no single CI workflow in `.github/workflows/` for this repo yet; treat
-**local green tests** as the main gate before pushing risky changes.
-
-## Procedure (agent)
-
-1. Read **`README.md`**, **`CLAUDE.md`** (PyTorch → Core ML playbook), and the
-   relevant **`README/*.md`** guide for the subsystem (conversion, runtime,
-   export).
-2. Do **not** run Cloudflare/Roast deploy commands—they do not apply.
-3. Run [Pre-ship gate](#pre-ship-gate-recommended) before advising “ready to
-   ship.”
-4. For **git remote** operations, follow **`git-push`** when the user wants push
-   + CI (if added later).
-
-## Anti-patterns
-
-- Copying **Roast** `pnpm deploy:staging` / Workers steps into this repo.
-- Pushing large binary or regenerated **`.mlpackage`** changes without noting
-  what was regenerated and how to verify.
-
-## Related skills
-
-- **`git-push`:** commit, merge, push, chase CI when CI exists.
-- **`git-commit`:** post-commit **`pytest`** awareness (non-blocking heads-up).
-- **`audit`:** full review when the user says **`audit`**.

.claude/skills/documentation/SKILL.md

@@ -1,53 +0,0 @@
----
-name: documentation
-description: 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.
----
-
-# Documentation
-
-## Purpose
-
-Enforce the repo's inline code documentation standards. Document what a future
-editor cannot safely derive from the code itself.
-
-## Use When
-
-- Adding or reviewing Python docstrings or file headers.
-- Documenting state lifecycle, constant rationale, or Core ML / export gotchas.
-- A PR review flags missing or low-quality documentation.
-
-## Do Not Use When
-
-- Writing README, plan, or notes documents.
-- General code changes where documentation isn't the focus.
-- Markdown formatting issues (that's linting, not documentation).
-
-## Procedure
-
-1. Read [references/index.md](references/index.md) first.
-2. Inspect the target file and the smallest set of related files needed to
-   confirm what context is truly missing.
-3. Add or tighten docs only where they capture:
-   - domain knowledge
-   - non-obvious constraints
-   - non-greppable cross-file contracts
-   - state lifecycle or constant rationale
-4. Prefer short, durable comments over boilerplate:
-   - short file headers
-   - docstrings that explain why or constraints
-   - state docs that explain lifetime and persistence
-   - constant comments that explain why the value exists
-5. Do not add manual call graphs, line-by-line prose, or comments that are more
-   likely to drift than to help.
-6. If the missing context actually belongs in a canonical guide, update the
-   guide as well instead of burying the whole explanation in code comments.
-
-## References
-
-Read [references/index.md](references/index.md) first.
-
-## Handoff Rules
-
-- Hand off to **`debug`** if the real issue is a runtime bug, not missing docs.
-- Hand off to normal refactoring flow if the task is structural change, not
-  documentation.

.claude/skills/documentation/references/index.md

@@ -1,11 +0,0 @@
-# Documentation References
-
-Canonical docs for `documentation`.
-
-- `README/Guides/content/code-documentation-guide.md`
-  Read first for the repo's actual inline code documentation philosophy and
-  review checklist.
-- the most relevant `README/Guides/...` docs for the subsystem you are
-  documenting
-  Read these when the useful comment depends on export, Core ML runtime, or
-  app-integration context that is not obvious from the local file.

.claude/skills/execute-plan/SKILL.md

@@ -1,103 +0,0 @@
----
-name: execute-plan
-description: Execute a checked-in implementation plan for this repo phase by 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.
----
-
-# Execute Plan
-
-## Purpose
-
-Use this skill to execute an existing repo plan without collapsing the work into
-one giant unreviewed change. The unit of progress is one completed phase at a
-time.
-
-## Use When
-
-- A concrete checked-in plan path exists in [README/Plans](../../../README/Plans).
-- The plan is implementation-ready.
-- The user wants the full implementation loop, not just discussion.
-
-## Do Not Use When
-
-- No checked-in plan exists yet.
-- The request is a one-off fix without a real plan.
-- The request is planning, brainstorming, or read-only review.
-
-## Authority Model
-
-- Explicit invocation of `$execute-plan` counts as authorization for this
-  workflow's git side effects. Direct naming also counts, for example
-  "use execute-plan":
-  - phase commits
-  - sync with `origin/main`
-  - push
-  - CI monitoring and follow-up fixes
-- If `execute-plan` was routed implicitly or inferred rather than invoked
-  directly, it may prepare local implementation work but must stop before the
-  first commit or push and explain why.
-- At the start of the workflow, state that `execute-plan` is running and that
-  it will create phase commits, push, and monitor CI unless the user opts out.
-
-## Procedure
-
-1. Read [references/index.md](references/index.md) first.
-2. Read the target plan and the linked canonical
-   [README/Skills](../../../README/Skills),
-   [README/Guides](../../../README/Guides), and
-   [README/Notes](../../../README/Notes) before changing code.
-3. Refuse to start if the plan is missing, too vague to execute honestly, or
-   still requires planning work.
-4. Execute one phase at a time:
-   - 4a. Execute the current phase. Implement only the active phase scope.
-     Make it perfect. No god modules. No bugs. Just elegant, modular code.
-   - 4b. Audit the execution with `phase-audit`. Prefer delegated review when
-     the runtime supports it cleanly; otherwise run the same checklist locally
-     against the canonical rubric. Double-check the work and fix findings
-     before moving on. Make it perfect.
-   - 4c. Update the plan. Make the phase checkboxes match reality before
-     calling the phase complete.
-   - 4d. Commit only your changes. Stage **only** the files for the completed
-     phase (narrower than the default `git-commit` whole-tree staging) and
-     follow the `git-commit` skill for the commit **message** (what and why).
-5. After all phases are complete:
-   - follow `git-push` for syncing with `origin`, pushing the branch, watching
-     GitHub Actions (when CI exists), and fixing failures until green (phase
-     commits stay narrower than default `git-commit`; `git-push` still applies
-     merge/push/CI loop).
-
-## Worktree Rules
-
-- Ignore unrelated dirty files unless they directly conflict with the active
-  phase.
-- Never revert unrelated user work.
-- Stop only when an existing change creates a real safety or correctness
-  conflict with the current phase.
-
-## Audit Contract
-
-Before each phase commit, explicitly verify:
-
-- the phase goal is actually complete
-- the plan checkboxes match the implementation
-- obvious edge cases are handled
-- tests or checks are appropriate for the change
-- the current phase is commit-ready
-
-## Boundaries
-
-- Do not create a new plan inside this workflow.
-- Do not silently skip the audit step.
-- Do not push with known failing CI unless the user explicitly overrides that
-  rule.
-
-## Canonical Docs
-
-Read [references/index.md](references/index.md) first. It maps the shared
-workflow guide, the phase audit rubric, and the artifacts needed to execute a
-plan cleanly.
-
-## Handoff Rules
-
-- Hand off to `phase-audit` when clean delegated review is available.
-- Hand off to `create-plan` only if the user actually needs a new plan instead
-  of execution.

.claude/skills/execute-plan/references/index.md

@@ -1,20 +0,0 @@
-# Execute Plan References
-
-Canonical docs for `execute-plan` live under **`README/Skills/`**:
-
-- `README/Skills/plan-workflow-skills-guide.md`  
-  Read first for the shared workflow contract and the explicit execution loop.
-- `README/Skills/phase-audit-rubric.md`  
-  Read for the canonical local-audit fallback when delegated review is not
-  available.
-
-Use **`README/Skills/`** when the active plan interacts with other repo skills and
-routing constraints (start with the guides above; extend to other files in that
-folder as they are added).
-
-Always inspect:
-
-- the concrete checked-in plan file before any implementation
-- every guide or note linked from the active phase
-- the changed files and verification outputs before updating plan checkboxes or
-  committing

.claude/skills/git-commit/SKILL.md

@@ -1,236 +0,0 @@
----
-name: git-commit
-description: 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.
----
-
-# Git Commit
-
-## Purpose
-
-Produce **reviewable commits**: a clear subject line and a body that explains
-**what** changed and **why**. **Staging is whole-tree by default** so one commit
-reflects everything currently pending on the branch, not a cherry-pick of what
-this session edited.
-
-## Authority
-
-- **`git commit` allowed when** the user explicitly asks you to commit, or a
-  checked-in workflow skill (for example `execute-plan`) authorizes commits as
-  part of its procedure.
-- **Message text only** when the user wants a commit message but did **not**
-  ask you to run Git: use the subject and body rules below, optionally after
-  `git status` / `git diff` for context. Do **not** `git add` or `git commit`.
-- If committing would be a surprise—no explicit commit request and no
-  workflow granting commit authority—**stop** before `git commit` and confirm
-  intent.
-
-## Use When
-
-- A commit with a strong message is requested or workflow-authorized.
-- The user wants help composing commit message text (with or without you
-  running `git commit`—see Authority).
-
-## Do Not Use When
-
-- Git writes are forbidden by context and nothing overrides that.
-
-## Staging scope
-
-- **Default (this skill alone):** Stage **all** changes in the working tree that
-  Git will track—modified, deleted, and **untracked** files—typically
-  `git add -A` at the repo root. That includes edits made by **other agents**,
-  the user, or tooling. `.gitignore` still applies (do not fight it to force
-  secrets into the commit).
-- **Parent workflow override:** If the active procedure **explicitly** limits
-  what may be staged (for example `execute-plan` phase commits: only files for
-  the completed phase), **follow that staging scope** and still use the message
-  rules below.
-- If `git status` shows something surprising (unexpected paths, credentials,
-  huge artifacts), **surface it** before committing; do not silently drop
-  co-workers’ changes to keep the commit “tidy.”
-
-## Procedure
-
-1. **Inspect** full `git status` and `git diff` (and `git diff --staged` if
-   anything is already staged). Understand **everything** that will be included.
-2. **Stage** per [Staging scope](#staging-scope) above.
-3. **Subject line** (about 50 characters target, 72 hard cap):
-   - Imperative mood: "Add", "Fix", "Refactor" — not past tense ("Added",
-     "Fixed") or third-person singular ("Adds", "Fixes") as the **subject**.
-   - The **body** may include issue closers such as `Fixes #123` when that is the
-     project convention.
-   - Be specific about area or behavior, not "Update code" or "WIP".
-4. **Body** (one blank line after the subject; wrap near 72 columns):
-   - **What**: bullets or short paragraphs covering **all** substantive areas in
-     this commit (not only the files you touched this turn).
-   - **Why**: motivation, tradeoffs, what was broken or awkward, or why this
-     approach over alternatives.
-   - **Context** (optional): issue links, plan paths, or follow-ups when they
-     help the next reader.
-5. **Commit** (commit path only), for example in bash or zsh:
-   - `git commit -m "subject" -m $'paragraph...\n\n- bullet'`
-   - or `git commit` with an editor when the body is long.
-6. **Verify** (commit path only): `git show --stat HEAD` matches intent (entire
-   staged set landed).
-7. **Post-commit audit** (commit path only): after the commit succeeds, follow
-   [Post-commit audit](#post-commit-audit). Run **`pytest`** at the repo root
-   when pytest is installed; then scan **only** the `HEAD` diff for bug risks,
-   god modules, needless complexity, and duplication (**lightweight**—see
-   [What this is not](#what-this-is-not)).
-   **Tell the user** about findings in the same turn (paths,
-   severity, next step if obvious)—as **heads-up**, not scolding. The commit is
-   already done; do **not** delay the commit, imply it was a mistake, or push
-   amend/revert unless the user asks. Do **not** silently “fix” findings unless
-   the user asked; surfacing is the goal. If everything passes and nothing
-   worrisome stands out in the diff, you may omit commentary.
-
-On the **message-only** path, perform step 1 as needed for context, skip
-staging and steps 5–7, and output the subject and body (use the template
-below).
-
-## Message template
-
-```text
-Add/improve/fix <behavior> in <area>
-
-What:
-- ...
-
-Why:
-- ...
-```
-
-## Post-commit audit
-
-Run this **only after** `git commit` completes successfully (same repo, same
-branch).
-
-### Intent (non-blocking)
-
-- **Commit always wins.** Nothing here vetoes, reorders, or shames a commit that
-  already landed. People should keep committing; this step is **extra awareness**
-  for the author, not policy for the team.
-- **Alerts, not gates.** Test or review findings are **heads-up** so you can fix
-  forward (`pytest` failed after commit—here is the output) or choose to ignore.
-  Do not treat red tests as “the commit was wrong.”
-- **Optional follow-up.** Suggest a fix commit or local cleanup only when helpful;
-  never pressure amend/revert unless the user explicitly wants that.
-- **Deeper review:** For **lint + full test matrix**, **A–F grades**, optional
-  **multi-agent** passes, and broader scope, the user should invoke the **`audit`**
-  skill (message contains **`audit`**)—do not inflate post-commit into a full audit.
-
-### What this is not
-
-Stay **narrow** so commits stay fast:
-
-- **Do** run **`pytest`** (when available) and read **`git show -p HEAD`** (this commit only).
-- **Do not** run exhaustive export suites or multi-step smoke tests here by
-  default—those belong to **`audit`**, **`deploy`**, or the user’s task unless
-  already requested.
-
-### Python checks
-
-From the **repository root**, when `pytest` is on the path:
-
-- Run **`pytest`** (or **`python -m pytest`** if that is how the environment is set up).
-
-If pytest is missing, no tests exist, or the run fails, **report the relevant
-output** with neutral framing (“Heads-up: `pytest` failed after your commit”).
-The commit stays; the user can fix in a follow-up. Do not hide failures.
-
-### Diff scope
-
-Use the committed change as the source of truth—e.g. `git show HEAD` or
-`git show -p HEAD`, and the paths touched:
-`git diff-tree --no-commit-id --name-only -r HEAD`.
-
-### Bug scan
-
-Re-read the change as a quick self-review **on changed lines only**. Flag **likely**
-problems for the user (this is not a substitute for CI, **`audit`**, or the full
-test suite unless already part of the task):
-
-- Logic errors, wrong conditions, off-by-one, incorrect defaults.
-- Missing or broken error handling / early returns where failures are plausible.
-- Obvious regressions: removed guards, weakened validation, race or stale-state
-  risks introduced by the new code.
-- API or type mismatches, impossible states, or changes that contradict the
-  commit message.
-- **Async discipline (spot-check):** missing `await`, fire-and-forget promises,
-  or ambiguous error propagation in the diff—borrowed from **`audit`** charter,
-  but **only** what you see in this patch.
-- **Workers / queues / webhooks / cron (spot-check):** if the diff touches those,
-  glance for obvious at-least-once hazards (duplicate side effects without
-  idempotency)—**one-line flag**, not a full reliability audit.
-- **Security / privacy (glance):** obvious secrets or PII logged in the diff; if
-  it needs auth review, nudge toward **`audit`** instead of digging here.
-- Anything that would make you say “wait, that can’t be right” on a PR.
-
-### God module scan
-
-Align with repo philosophy: **clear separation of concerns**, no dumping
-unrelated responsibilities into one place.
-
-Flag when this commit **creates or substantially grows** a module that looks
-like a grab-bag “does everything” file—for example:
-
-- **Size**: one file approaches or exceeds the project’s per-file size guidance
-  (this repo aims for well under ~1000 LOC per file—use judgment near that
-  band).
-- **Scope creep**: unrelated domains, layers, or features fused into a single
-  module (many disparate exports, orchestration + persistence + UI helpers in
-  one file, etc.).
-- **Fan-in smell**: a change that makes one file the obvious choke point for
-  unrelated call sites when a split would be natural.
-
-When in doubt, **flag lightly** with reasoning; avoid crying wolf, but do not
-skip obvious smells to avoid bothering the user.
-
-### Needless complexity and duplication
-
-- **Needless complexity**: extra layers, over-abstraction, clever patterns where
-  a straight line would do, new dependencies or infrastructure for trivial
-  wins, configuration explosions, or branching that obscures the actual
-  behavior—especially when it violates **simpler is better** for this repo.
-- **Duplication**: copy-pasted blocks, parallel implementations of the same rule
-  or transform, near-identical helpers that should be one function, or “another
-  copy” of logic that already exists elsewhere—when unifying would obviously
-  reduce drift risk.
-
-Flag when this commit **introduces or worsens** these; cite paths and why it
-matters.
-
-### What to output
-
-- **pytest**: pass/fail; if fail, enough output to act on, framed as post-commit
-  awareness—not a blocked workflow.
-- **If other issues**: short summary, bullet list with **file paths**, what you
-  saw, and whether it looks like a definite bug vs. a risk vs. a maintainability
-  smell.
-- **If clean**: say nothing or one line—no boilerplate required.
-
-## Anti-patterns
-
-- One-word subjects ("fix", "wip", "updates").
-- A body that only repeats the subject.
-- **Cherry-staging** only the files you personally edited when the user asked
-  for a commit and no narrower workflow override applies—other agents’ work
-  must ship too.
-- Claiming a “single logical change” while omitting co-present dirty files
-  without explicit user direction.
-- **Skipping the post-commit audit** after a successful commit when this skill’s
-  commit path ran—especially omitting **`pytest`** when available or staying silent
-  when it fails or the diff clearly introduces risk.
-- **Skipping pytest** when it is installed and the repo has tests; hiding failures
-  instead of showing them.
-- **Turning post-commit into a full audit:** running full export smoke, multi-agent
-  **`Task`** delegation, or **A–F grades** here—use the **`audit`** skill when the
-  user says **`audit`**.
-- **Blocking mindset:** implying the user should not have committed, or urging
-  amend/revert, because of post-commit findings—unless they asked for that.
-
-## Related skills
-
-- **`audit`:** user message includes **`audit`**; optional full tests, optional
-  multi-agent, **A–F** grades, broader scope.
-- **`deploy`:** what “ship” means for this repo (no Cloudflare scripts); see that skill.

.claude/skills/git-push/SKILL.md

@@ -1,111 +0,0 @@
----
-name: git-push
-description: 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.
----
-
-# Git Push
-
-## Purpose
-
-Close the loop from **dirty working tree → clean push → green GitHub Actions**:
-commit everything pending when needed, integrate upstream with **merge** (not
-silent rebase unless the user prefers otherwise), push, watch workflows, and
-iterate on real failures until passes.
-
-## Authority
-
-- **`git push` allowed when** the user invokes `$git-push`, names `git-push`,
-  or clearly asks you to sync, push, and fix CI until green—or a checked-in
-  workflow authorizes the same (for example cooperating with `execute-plan`
-  after phased work).
-- This authorizes **`git commit`**, **`git pull`/`git merge`** (integrating
-  `origin`), **`git push`**, reading CI logs, and **code/test fixes** needed to
-  get workflows green.
-- If push or CI remediation would be a surprise, **stop** and confirm.
-
-## Use When
-
-- The user wants the branch **on the remote** and **CI passing**.
-- You need the full “commit if needed → sync → push → babysit CI” routine.
-
-## Do Not Use When
-
-- The user only wants a **dry run** or local-only commands.
-- You are not allowed to touch **`origin`** or fix CI (no override).
-
-## Preconditions (agent)
-
-1. Know the **current branch** and whether it has an **upstream**
-   (`git status -sb`, `git rev-parse --abbrev-ref @{u}` when set).
-2. `git fetch origin` before deciding you are in sync.
-
-## Procedure
-
-### 1. Uncommitted changes
-
-- If **`git status --porcelain`** is non-empty (including untracked you intend
-  to keep), run **`git-commit`** first so the working tree is committed with a
-  full **what / why** message.
-- **Do not** bypass `git-commit` with a lazy one-liner unless the user
-  explicitly overrides.
-
-### 2. Integrate `origin` (merge-oriented)
-
-- **Preferred** for this skill: after `git fetch origin`, integrate with
-  **merge**, not rebase—unless the user explicitly asks for rebase.
-- If an upstream exists: e.g. `git pull --no-rebase` (or `git merge`
-  `origin/<upstream-branch>` after fetch) so local commits combine with remote
-  updates.
-- If there is **no upstream** yet, a reasonable first push is
-  `git push -u origin HEAD` after the branch is ready—set upstream for future
-  pulls.
-- **Merge conflicts**: resolve carefully; if intent is ambiguous, **stop** and
-  ask rather than guessing.
-
-### 3. Push
-
-- `git push` to the appropriate remote (usually `origin`) and branch.
-- If push is rejected because the remote advanced, **fetch**, **merge** (per
-  above), resolve conflicts, then **push again**—do not force-push unless the
-  user explicitly requests it and it is safe for the branch.
-
-### 4. Monitor GitHub Actions
-
-- Identify the run(s) for the pushed commit / branch (for example
-  `gh run list --branch <branch> --limit 5` then
-  `gh run watch <run-id> --exit-status`, or the Actions UI).
-- Wait until the relevant workflow(s) **finish**.
-
-### 5. On failure: fix root cause, repeat
-
-- Read logs; reproduce locally when possible (`pytest`, targeted scripts,
-  `kokoro.js` tests if relevant, matching what failed).
-- Fix the **underlying issue**—not symptoms only—then **commit** (again via
-  **`git-commit`** when there are new changes) and **push**, then **re-watch**
-  CI.
-- **Loop** until green or until you hit a blocker (permissions, flaky external,
-  ambiguous product intent).
-
-### 6. Coverage and quality gates
-
-- If CI fails because **test coverage** (or a similar **required threshold**)
-  is not met:<br />
-  **Never satisfy the gate by lowering the threshold or disabling checks** as
-  a shortcut.
-- Correct response: **add or strengthen tests**, **exercise untested paths**,
-  or **refactor for testability** so coverage **earns** the bar.
-
-## Anti-patterns
-
-- Pushing with a dirty tree (except when every pending change is intentionally
-  left out—and then say so explicitly; default is commit first).
-- Force-push to shared branches without explicit approval.
-- “Fixing” CI by weakening lint, coverage, or type gates.
-- Re-running CI repeatedly without changing what failed.
-
-## Related skills
-
-- **`git-commit`**: message shape and default **whole-tree** staging (unless a
-  narrower parent workflow applies).
-- **`execute-plan`**: may narrow what gets committed **per phase**; this skill
-  still applies to the **push / merge / CI loop** once commits are ready.

.claude/skills/markdown/SKILL.md

@@ -1,55 +0,0 @@
----
-name: markdown
-description: 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.
----
-
-# Markdown
-
-## Purpose
-
-Use this skill to keep repo markdown clean, consistent, and easy to maintain.
-
-## Use When
-
-- Writing or revising markdown docs.
-- Fixing markdown lint failures.
-- Editing plans, notes, guides, or README files.
-
-## Do Not Use When
-
-- The real task is inline code documentation.
-- The work is code implementation, not doc authoring.
-- The file is not markdown.
-
-## Procedure
-
-1. Read [references/index.md](references/index.md) first.
-2. Identify the document family:
-   - guide
-   - note
-   - plan
-   - general README or content doc
-3. Use the canonical template when the document family has one.
-4. Preserve the existing structure of the doc family unless the task is
-   explicitly a reorganization.
-5. Apply the repo markdown rules:
-   - real markdown links, not bare URLs
-   - no unnecessary inline HTML
-   - blank lines around headings and lists
-   - language-tagged fenced code blocks when known
-   - single trailing newline
-6. Keep prose lean. Prefer one canonical explanation over duplicated text across
-   several files.
-7. If the task is markdown-focused or touches several markdown files, run a
-   markdown lint pass before stopping when repo tooling is available.
-
-## References
-
-Read [references/index.md](references/index.md) first.
-
-## Handoff Rules
-
-- Hand off to `documentation` if the real work is inline code docs rather than
-  markdown documents.
-- Hand off to `write-notes` if the main question is where a note belongs and how
-  to consolidate it without note sprawl.

.claude/skills/markdown/references/index.md

@@ -1,14 +0,0 @@
-# Markdown References
-
-Canonical docs for `markdown`.
-
-- `README/Guides/content/markdown-authoring-guide.md`
-  Read first for the repo's markdown rules and markdown-specific verification
-  flow.
-- `README/Templates/Plans-template.md`
-  Read when the markdown file is a plan under `README/Plans/...`.
-- `README/Templates/Notes-template.md`
-  Read when the markdown file is a notes entry under `README/Notes/...`.
-- `README/Guides/content/notes-consolidation-guide.md`
-  Read when the markdown edit touches notes and you need to avoid creating note
-  sprawl.

.claude/skills/phase-audit/SKILL.md

@@ -1,77 +0,0 @@
----
-name: phase-audit
-description: 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.
----
-
-# Phase Audit
-
-## Purpose
-
-Use this skill to audit a completed implementation phase like a skeptical
-senior engineer doing code review. The job is to decide whether the phase is actually complete and ready to commit or push, not to help implement it.
-
-## Use When
-
-- A plan phase was just implemented.
-- The current plan checkboxes need validation against reality.
-- The repo needs a findings-first review before commit or before moving to the
-  next phase.
-
-## Do Not Use When
-
-- The request is to implement or patch code.
-- The request is broad product or UX feedback.
-- The request is to replace tests, CI, or runtime verification with a code
-  review.
-
-## Procedure
-
-1. Read [references/index.md](references/index.md) first.
-2. Read the active plan and isolate the exact phase being audited:
-   - phase goal
-   - checked tasks
-   - phase verification text
-   - linked canonical references in [README/Skills](../../../README/Skills),
-     [README/Guides](../../../README/Guides), and [README/Notes](../../../README/Notes)
-3. Inspect the implementation evidence:
-   - changed files and diffs
-   - tests or checks that were run
-   - any notes that explain scope decisions
-4. Compare the implementation against the canonical rubric and linked guides.
-5. Produce a findings-first audit:
-   - severity ordered
-   - concrete file references when applicable
-   - explicit call on whether the phase is complete
-6. Explicitly check:
-   - missing scope
-   - missing edge cases
-   - missing tests or weak verification
-   - checkbox drift between the plan and the code
-   - commit readiness
-   - push and CI readiness
-7. If there are no findings, say so directly and note residual risks or
-   verification gaps.
-
-## Output Contract
-
-- Findings first.
-- Severity ordered.
-- Concrete file references when applicable.
-- Brief summary only after the findings.
-
-## Boundaries
-
-- Do not edit files.
-- Do not silently fix the problem instead of reporting it.
-- Do not replace tests, CI, or runtime verification with review prose.
-
-## Canonical Docs
-
-Read [references/index.md](references/index.md) first. It maps the workflow
-guide, the audit rubric, and the repo artifacts that define whether a phase is
-actually done.
-
-## Handoff Rules
-
-- Hand findings back to `execute-plan` or the user for remediation.
-- Re-run this skill after fixes if the phase changed materially.

.claude/skills/phase-audit/references/index.md

@@ -1,19 +0,0 @@
-# Phase Audit References
-
-Canonical docs for `phase-audit` live under **`README/Skills/`**:
-
-- `README/Skills/plan-workflow-skills-guide.md`
-  Read first for the shared workflow contract and the boundary between
-  `phase-audit` and `execute-plan`.
-- `README/Skills/phase-audit-rubric.md`
-  Read for the canonical review checklist and commit-readiness criteria.
-- `README/Templates/Plans-template.md`
-  Read when you need to validate whether the active plan phase, checkbox
-  updates, and verification text still match the template contract.
-
-Always inspect:
-
-- the active plan file and the specific phase being audited
-- the changed files for that phase
-- any directly linked `README/Guides/...`, `README/Notes/...`, or
-  `README/Skills/...` files that constrain the implementation

.claude/skills/write-notes/SKILL.md

@@ -1,62 +0,0 @@
----
-name: write-notes
-description: 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.
----
-
-# Write Notes
-
-## Purpose
-
-Capture useful institutional memory in `README/Notes/` without creating note
-sprawl.
-
-## Use When
-
-- The user wants a bug, investigation, audit, or debugging trail captured in
-  repo notes.
-- A change should leave behind durable troubleshooting context.
-- An existing notes bundle should be updated with a new issue section.
-
-## Do Not Use When
-
-- The user wants a plan.
-- The output belongs in a guide or README instead of `README/Notes/`.
-- The content is really inline code documentation.
-- The note would be throwaway session chatter with no lasting value.
-
-## Procedure
-
-1. Read [references/index.md](references/index.md) first.
-2. Scan `README/Notes/` for the best existing home before creating any new
-   file.
-3. Default to consolidation:
-   - update the right high-level domain note file
-   - add a new issue section inside that file
-   - keep the issue self-contained with the notes-template structure
-4. Create a new notes file only when the topic is durable enough to deserve its
-   own entry point:
-   - recurring subsystem problem
-   - cross-cutting audit
-   - report likely to be searched directly later
-5. Use topic-based names for new files. Do not create a new file just because
-   there is a new date or session.
-6. Keep the note high signal:
-   - summary
-   - symptom
-   - root cause or `TBD`
-   - related guides
-   - fix or current status
-   - verification or next step
-7. Keep active issues near the top. Convert fixed issues to resolved status and
-   prune dead investigation branches after resolution.
-
-## References
-
-Read [references/index.md](references/index.md) first.
-
-## Handoff Rules
-
-- Hand off to `markdown` when the real task is markdown cleanup rather than note
-  placement or note structure.
-- Hand off to `create-plan` when the user wants a real implementation plan
-  instead of notes.

.claude/skills/write-notes/references/index.md

@@ -1,11 +0,0 @@
-# Write Notes References
-
-Canonical docs for `write-notes`.
-
-- `README/Guides/content/notes-consolidation-guide.md`
-  Read first for the repo's anti-sprawl notes policy and file-selection rules.
-- `README/Templates/Notes-template.md`
-  Read for the required issue structure inside a notes document.
-- the most relevant `README/Guides/...` files for the subsystem
-  Read when the note should link out to canonical guidance for context or
-  recurrence handling.

.github/FUNDING.yml

@@ -1,15 +0,0 @@
-# These are supported funding model platforms
-
-github: hexgrad # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
-patreon: # Replace with a single Patreon username
-open_collective: # Replace with a single Open Collective username
-ko_fi: # Replace with a single Ko-fi username
-tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
-community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
-liberapay: # Replace with a single Liberapay username
-issuehunt: # Replace with a single IssueHunt username
-lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
-polar: # Replace with a single Polar username
-buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
-thanks_dev: # Replace with a single thanks.dev username
-custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']

.gitignore

@@ -1,178 +0,0 @@
-# Byte-compiled / optimized / DLL files
-__pycache__/
-*.py[cod]
-*$py.class
-
-# C extensions
-*.so
-
-# Distribution / packaging
-.Python
-build/
-develop-eggs/
-dist/
-downloads/
-eggs/
-.eggs/
-lib/
-lib64/
-parts/
-sdist/
-var/
-wheels/
-share/python-wheels/
-*.egg-info/
-.installed.cfg
-*.egg
-MANIFEST
-
-# PyInstaller
-#  Usually these files are written by a python script from a template
-#  before PyInstaller builds the exe, so as to inject date/other infos into it.
-*.manifest
-*.spec
-
-# Installer logs
-pip-log.txt
-pip-delete-this-directory.txt
-
-# Unit test / coverage reports
-htmlcov/
-.tox/
-.nox/
-.coverage
-.coverage.*
-.cache
-nosetests.xml
-coverage.xml
-*.cover
-*.py,cover
-.hypothesis/
-.pytest_cache/
-cover/
-
-# Translations
-*.mo
-*.pot
-
-# Django stuff:
-*.log
-local_settings.py
-db.sqlite3
-db.sqlite3-journal
-
-# Flask stuff:
-instance/
-.webassets-cache
-
-# Scrapy stuff:
-.scrapy
-
-# Sphinx documentation
-docs/_build/
-
-# PyBuilder
-.pybuilder/
-target/
-
-# Jupyter Notebook
-.ipynb_checkpoints
-
-# IPython
-profile_default/
-ipython_config.py
-
-# pyenv
-#   For a library or package, you might want to ignore these files since the code is
-#   intended to run in multiple environments; otherwise, check them in:
-# .python-version
-
-# pipenv
-#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
-#   However, in case of collaboration, if having platform-specific dependencies or dependencies
-#   having no cross-platform support, pipenv may install dependencies that don't work, or not
-#   install all needed dependencies.
-#Pipfile.lock
-
-# UV
-#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
-#   This is especially recommended for binary packages to ensure reproducibility, and is more
-#   commonly ignored for libraries.
-#uv.lock
-
-# poetry
-#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
-#   This is especially recommended for binary packages to ensure reproducibility, and is more
-#   commonly ignored for libraries.
-#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
-#poetry.lock
-
-# pdm
-#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
-#pdm.lock
-#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
-#   in version control.
-#   https://pdm.fming.dev/latest/usage/project/#working-with-version-control
-.pdm.toml
-.pdm-python
-.pdm-build/
-
-# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
-__pypackages__/
-
-# Celery stuff
-celerybeat-schedule
-celerybeat.pid
-
-# SageMath parsed files
-*.sage.py
-
-# Environments
-.env
-.venv
-env/
-venv/
-ENV/
-env.bak/
-venv.bak/
-
-# Spyder project settings
-.spyderproject
-.spyproject
-
-# Rope project settings
-.ropeproject
-
-# mkdocs documentation
-/site
-
-# mypy
-.mypy_cache/
-.dmypy.json
-dmypy.json
-
-# Pyre type checker
-.pyre/
-
-# pytype static type analyzer
-.pytype/
-
-# Cython debug symbols
-cython_debug/
-
-# PyCharm
-#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
-#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
-#  and can be added to the global gitignore or merged into this file.  For a more nuclear
-#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
-#.idea/
-
-# PyPI configuration file
-.pypirc
-
-# Local TTS debug outputs (WAV/CSV/JSON)
-outputs/
-outputs/**
-
-# Local scratch notes (not for version control)
-scratchpad.md

.venv-coreml/bin/Activate.ps1

@@ -1,247 +0,0 @@
-<#
-.Synopsis
-Activate a Python virtual environment for the current PowerShell session.
-
-.Description
-Pushes the python executable for a virtual environment to the front of the
-$Env:PATH environment variable and sets the prompt to signify that you are
-in a Python virtual environment. Makes use of the command line switches as
-well as the `pyvenv.cfg` file values present in the virtual environment.
-
-.Parameter VenvDir
-Path to the directory that contains the virtual environment to activate. The
-default value for this is the parent of the directory that the Activate.ps1
-script is located within.
-
-.Parameter Prompt
-The prompt prefix to display when this virtual environment is activated. By
-default, this prompt is the name of the virtual environment folder (VenvDir)
-surrounded by parentheses and followed by a single space (ie. '(.venv) ').
-
-.Example
-Activate.ps1
-Activates the Python virtual environment that contains the Activate.ps1 script.
-
-.Example
-Activate.ps1 -Verbose
-Activates the Python virtual environment that contains the Activate.ps1 script,
-and shows extra information about the activation as it executes.
-
-.Example
-Activate.ps1 -VenvDir C:\Users\MyUser\Common\.venv
-Activates the Python virtual environment located in the specified location.
-
-.Example
-Activate.ps1 -Prompt "MyPython"
-Activates the Python virtual environment that contains the Activate.ps1 script,
-and prefixes the current prompt with the specified string (surrounded in
-parentheses) while the virtual environment is active.
-
-.Notes
-On Windows, it may be required to enable this Activate.ps1 script by setting the
-execution policy for the user. You can do this by issuing the following PowerShell
-command:
-
-PS C:\> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
-
-For more information on Execution Policies: 
-https://go.microsoft.com/fwlink/?LinkID=135170
-
-#>
-Param(
-    [Parameter(Mandatory = $false)]
-    [String]
-    $VenvDir,
-    [Parameter(Mandatory = $false)]
-    [String]
-    $Prompt
-)
-
-<# Function declarations --------------------------------------------------- #>
-
-<#
-.Synopsis
-Remove all shell session elements added by the Activate script, including the
-addition of the virtual environment's Python executable from the beginning of
-the PATH variable.
-
-.Parameter NonDestructive
-If present, do not remove this function from the global namespace for the
-session.
-
-#>
-function global:deactivate ([switch]$NonDestructive) {
-    # Revert to original values
-
-    # The prior prompt:
-    if (Test-Path -Path Function:_OLD_VIRTUAL_PROMPT) {
-        Copy-Item -Path Function:_OLD_VIRTUAL_PROMPT -Destination Function:prompt
-        Remove-Item -Path Function:_OLD_VIRTUAL_PROMPT
-    }
-
-    # The prior PYTHONHOME:
-    if (Test-Path -Path Env:_OLD_VIRTUAL_PYTHONHOME) {
-        Copy-Item -Path Env:_OLD_VIRTUAL_PYTHONHOME -Destination Env:PYTHONHOME
-        Remove-Item -Path Env:_OLD_VIRTUAL_PYTHONHOME
-    }
-
-    # The prior PATH:
-    if (Test-Path -Path Env:_OLD_VIRTUAL_PATH) {
-        Copy-Item -Path Env:_OLD_VIRTUAL_PATH -Destination Env:PATH
-        Remove-Item -Path Env:_OLD_VIRTUAL_PATH
-    }
-
-    # Just remove the VIRTUAL_ENV altogether:
-    if (Test-Path -Path Env:VIRTUAL_ENV) {
-        Remove-Item -Path env:VIRTUAL_ENV
-    }
-
-    # Just remove VIRTUAL_ENV_PROMPT altogether.
-    if (Test-Path -Path Env:VIRTUAL_ENV_PROMPT) {
-        Remove-Item -Path env:VIRTUAL_ENV_PROMPT
-    }
-
-    # Just remove the _PYTHON_VENV_PROMPT_PREFIX altogether:
-    if (Get-Variable -Name "_PYTHON_VENV_PROMPT_PREFIX" -ErrorAction SilentlyContinue) {
-        Remove-Variable -Name _PYTHON_VENV_PROMPT_PREFIX -Scope Global -Force
-    }
-
-    # Leave deactivate function in the global namespace if requested:
-    if (-not $NonDestructive) {
-        Remove-Item -Path function:deactivate
-    }
-}
-
-<#
-.Description
-Get-PyVenvConfig parses the values from the pyvenv.cfg file located in the
-given folder, and returns them in a map.
-
-For each line in the pyvenv.cfg file, if that line can be parsed into exactly
-two strings separated by `=` (with any amount of whitespace surrounding the =)
-then it is considered a `key = value` line. The left hand string is the key,
-the right hand is the value.
-
-If the value starts with a `'` or a `"` then the first and last character is
-stripped from the value before being captured.
-
-.Parameter ConfigDir
-Path to the directory that contains the `pyvenv.cfg` file.
-#>
-function Get-PyVenvConfig(
-    [String]
-    $ConfigDir
-) {
-    Write-Verbose "Given ConfigDir=$ConfigDir, obtain values in pyvenv.cfg"
-
-    # Ensure the file exists, and issue a warning if it doesn't (but still allow the function to continue).
-    $pyvenvConfigPath = Join-Path -Resolve -Path $ConfigDir -ChildPath 'pyvenv.cfg' -ErrorAction Continue
-
-    # An empty map will be returned if no config file is found.
-    $pyvenvConfig = @{ }
-
-    if ($pyvenvConfigPath) {
-
-        Write-Verbose "File exists, parse `key = value` lines"
-        $pyvenvConfigContent = Get-Content -Path $pyvenvConfigPath
-
-        $pyvenvConfigContent | ForEach-Object {
-            $keyval = $PSItem -split "\s*=\s*", 2
-            if ($keyval[0] -and $keyval[1]) {
-                $val = $keyval[1]
-
-                # Remove extraneous quotations around a string value.
-                if ("'""".Contains($val.Substring(0, 1))) {
-                    $val = $val.Substring(1, $val.Length - 2)
-                }
-
-                $pyvenvConfig[$keyval[0]] = $val
-                Write-Verbose "Adding Key: '$($keyval[0])'='$val'"
-            }
-        }
-    }
-    return $pyvenvConfig
-}
-
-
-<# Begin Activate script --------------------------------------------------- #>
-
-# Determine the containing directory of this script
-$VenvExecPath = Split-Path -Parent $MyInvocation.MyCommand.Definition
-$VenvExecDir = Get-Item -Path $VenvExecPath
-
-Write-Verbose "Activation script is located in path: '$VenvExecPath'"
-Write-Verbose "VenvExecDir Fullname: '$($VenvExecDir.FullName)"
-Write-Verbose "VenvExecDir Name: '$($VenvExecDir.Name)"
-
-# Set values required in priority: CmdLine, ConfigFile, Default
-# First, get the location of the virtual environment, it might not be
-# VenvExecDir if specified on the command line.
-if ($VenvDir) {
-    Write-Verbose "VenvDir given as parameter, using '$VenvDir' to determine values"
-}
-else {
-    Write-Verbose "VenvDir not given as a parameter, using parent directory name as VenvDir."
-    $VenvDir = $VenvExecDir.Parent.FullName.TrimEnd("\\/")
-    Write-Verbose "VenvDir=$VenvDir"
-}
-
-# Next, read the `pyvenv.cfg` file to determine any required value such
-# as `prompt`.
-$pyvenvCfg = Get-PyVenvConfig -ConfigDir $VenvDir
-
-# Next, set the prompt from the command line, or the config file, or
-# just use the name of the virtual environment folder.
-if ($Prompt) {
-    Write-Verbose "Prompt specified as argument, using '$Prompt'"
-}
-else {
-    Write-Verbose "Prompt not specified as argument to script, checking pyvenv.cfg value"
-    if ($pyvenvCfg -and $pyvenvCfg['prompt']) {
-        Write-Verbose "  Setting based on value in pyvenv.cfg='$($pyvenvCfg['prompt'])'"
-        $Prompt = $pyvenvCfg['prompt'];
-    }
-    else {
-        Write-Verbose "  Setting prompt based on parent's directory's name. (Is the directory name passed to venv module when creating the virutal environment)"
-        Write-Verbose "  Got leaf-name of $VenvDir='$(Split-Path -Path $venvDir -Leaf)'"
-        $Prompt = Split-Path -Path $venvDir -Leaf
-    }
-}
-
-Write-Verbose "Prompt = '$Prompt'"
-Write-Verbose "VenvDir='$VenvDir'"
-
-# Deactivate any currently active virtual environment, but leave the
-# deactivate function in place.
-deactivate -nondestructive
-
-# Now set the environment variable VIRTUAL_ENV, used by many tools to determine
-# that there is an activated venv.
-$env:VIRTUAL_ENV = $VenvDir
-
-if (-not $Env:VIRTUAL_ENV_DISABLE_PROMPT) {
-
-    Write-Verbose "Setting prompt to '$Prompt'"
-
-    # Set the prompt to include the env name
-    # Make sure _OLD_VIRTUAL_PROMPT is global
-    function global:_OLD_VIRTUAL_PROMPT { "" }
-    Copy-Item -Path function:prompt -Destination function:_OLD_VIRTUAL_PROMPT
-    New-Variable -Name _PYTHON_VENV_PROMPT_PREFIX -Description "Python virtual environment prompt prefix" -Scope Global -Option ReadOnly -Visibility Public -Value $Prompt
-
-    function global:prompt {
-        Write-Host -NoNewline -ForegroundColor Green "($_PYTHON_VENV_PROMPT_PREFIX) "
-        _OLD_VIRTUAL_PROMPT
-    }
-    $env:VIRTUAL_ENV_PROMPT = $Prompt
-}
-
-# Clear PYTHONHOME
-if (Test-Path -Path Env:PYTHONHOME) {
-    Copy-Item -Path Env:PYTHONHOME -Destination Env:_OLD_VIRTUAL_PYTHONHOME
-    Remove-Item -Path Env:PYTHONHOME
-}
-
-# Add the venv to the PATH
-Copy-Item -Path Env:PATH -Destination Env:_OLD_VIRTUAL_PATH
-$Env:PATH = "$VenvExecDir$([System.IO.Path]::PathSeparator)$Env:PATH"

.venv-coreml/bin/activate

@@ -1,69 +0,0 @@
-# This file must be used with "source bin/activate" *from bash*
-# you cannot run it directly
-
-deactivate () {
-    # reset old environment variables
-    if [ -n "${_OLD_VIRTUAL_PATH:-}" ] ; then
-        PATH="${_OLD_VIRTUAL_PATH:-}"
-        export PATH
-        unset _OLD_VIRTUAL_PATH
-    fi
-    if [ -n "${_OLD_VIRTUAL_PYTHONHOME:-}" ] ; then
-        PYTHONHOME="${_OLD_VIRTUAL_PYTHONHOME:-}"
-        export PYTHONHOME
-        unset _OLD_VIRTUAL_PYTHONHOME
-    fi
-
-    # This should detect bash and zsh, which have a hash command that must
-    # be called to get it to forget past commands.  Without forgetting
-    # past commands the $PATH changes we made may not be respected
-    if [ -n "${BASH:-}" -o -n "${ZSH_VERSION:-}" ] ; then
-        hash -r 2> /dev/null
-    fi
-
-    if [ -n "${_OLD_VIRTUAL_PS1:-}" ] ; then
-        PS1="${_OLD_VIRTUAL_PS1:-}"
-        export PS1
-        unset _OLD_VIRTUAL_PS1
-    fi
-
-    unset VIRTUAL_ENV
-    unset VIRTUAL_ENV_PROMPT
-    if [ ! "${1:-}" = "nondestructive" ] ; then
-    # Self destruct!
-        unset -f deactivate
-    fi
-}
-
-# unset irrelevant variables
-deactivate nondestructive
-
-VIRTUAL_ENV="/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml"
-export VIRTUAL_ENV
-
-_OLD_VIRTUAL_PATH="$PATH"
-PATH="$VIRTUAL_ENV/bin:$PATH"
-export PATH
-
-# unset PYTHONHOME if set
-# this will fail if PYTHONHOME is set to the empty string (which is bad anyway)
-# could use `if (set -u; : $PYTHONHOME) ;` in bash
-if [ -n "${PYTHONHOME:-}" ] ; then
-    _OLD_VIRTUAL_PYTHONHOME="${PYTHONHOME:-}"
-    unset PYTHONHOME
-fi
-
-if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT:-}" ] ; then
-    _OLD_VIRTUAL_PS1="${PS1:-}"
-    PS1="(.venv-coreml) ${PS1:-}"
-    export PS1
-    VIRTUAL_ENV_PROMPT="(.venv-coreml) "
-    export VIRTUAL_ENV_PROMPT
-fi
-
-# This should detect bash and zsh, which have a hash command that must
-# be called to get it to forget past commands.  Without forgetting
-# past commands the $PATH changes we made may not be respected
-if [ -n "${BASH:-}" -o -n "${ZSH_VERSION:-}" ] ; then
-    hash -r 2> /dev/null
-fi

.venv-coreml/bin/activate.csh

@@ -1,26 +0,0 @@
-# This file must be used with "source bin/activate.csh" *from csh*.
-# You cannot run it directly.
-# Created by Davide Di Blasi <davidedb@gmail.com>.
-# Ported to Python 3.3 venv by Andrew Svetlov <andrew.svetlov@gmail.com>
-
-alias deactivate 'test $?_OLD_VIRTUAL_PATH != 0 && setenv PATH "$_OLD_VIRTUAL_PATH" && unset _OLD_VIRTUAL_PATH; rehash; test $?_OLD_VIRTUAL_PROMPT != 0 && set prompt="$_OLD_VIRTUAL_PROMPT" && unset _OLD_VIRTUAL_PROMPT; unsetenv VIRTUAL_ENV; unsetenv VIRTUAL_ENV_PROMPT; test "\!:*" != "nondestructive" && unalias deactivate'
-
-# Unset irrelevant variables.
-deactivate nondestructive
-
-setenv VIRTUAL_ENV "/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml"
-
-set _OLD_VIRTUAL_PATH="$PATH"
-setenv PATH "$VIRTUAL_ENV/bin:$PATH"
-
-
-set _OLD_VIRTUAL_PROMPT="$prompt"
-
-if (! "$?VIRTUAL_ENV_DISABLE_PROMPT") then
-    set prompt = "(.venv-coreml) $prompt"
-    setenv VIRTUAL_ENV_PROMPT "(.venv-coreml) "
-endif
-
-alias pydoc python -m pydoc
-
-rehash

.venv-coreml/bin/activate.fish

@@ -1,66 +0,0 @@
-# This file must be used with "source <venv>/bin/activate.fish" *from fish*
-# (https://fishshell.com/); you cannot run it directly.
-
-function deactivate  -d "Exit virtual environment and return to normal shell environment"
-    # reset old environment variables
-    if test -n "$_OLD_VIRTUAL_PATH"
-        set -gx PATH $_OLD_VIRTUAL_PATH
-        set -e _OLD_VIRTUAL_PATH
-    end
-    if test -n "$_OLD_VIRTUAL_PYTHONHOME"
-        set -gx PYTHONHOME $_OLD_VIRTUAL_PYTHONHOME
-        set -e _OLD_VIRTUAL_PYTHONHOME
-    end
-
-    if test -n "$_OLD_FISH_PROMPT_OVERRIDE"
-        functions -e fish_prompt
-        set -e _OLD_FISH_PROMPT_OVERRIDE
-        functions -c _old_fish_prompt fish_prompt
-        functions -e _old_fish_prompt
-    end
-
-    set -e VIRTUAL_ENV
-    set -e VIRTUAL_ENV_PROMPT
-    if test "$argv[1]" != "nondestructive"
-        # Self-destruct!
-        functions -e deactivate
-    end
-end
-
-# Unset irrelevant variables.
-deactivate nondestructive
-
-set -gx VIRTUAL_ENV "/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml"
-
-set -gx _OLD_VIRTUAL_PATH $PATH
-set -gx PATH "$VIRTUAL_ENV/bin" $PATH
-
-# Unset PYTHONHOME if set.
-if set -q PYTHONHOME
-    set -gx _OLD_VIRTUAL_PYTHONHOME $PYTHONHOME
-    set -e PYTHONHOME
-end
-
-if test -z "$VIRTUAL_ENV_DISABLE_PROMPT"
-    # fish uses a function instead of an env var to generate the prompt.
-
-    # Save the current fish_prompt function as the function _old_fish_prompt.
-    functions -c fish_prompt _old_fish_prompt
-
-    # With the original prompt function renamed, we can override with our own.
-    function fish_prompt
-        # Save the return status of the last command.
-        set -l old_status $status
-
-        # Output the venv prompt; color taken from the blue of the Python logo.
-        printf "%s%s%s" (set_color 4B8BBE) "(.venv-coreml) " (set_color normal)
-
-        # Restore the return status of the previous command.
-        echo "exit $old_status" | .
-        # Output the original/"old" prompt.
-        _old_fish_prompt
-    end
-
-    set -gx _OLD_FISH_PROMPT_OVERRIDE "$VIRTUAL_ENV"
-    set -gx VIRTUAL_ENV_PROMPT "(.venv-coreml) "
-end

.venv-coreml/bin/convert-caffe2-to-onnx

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from caffe2.python.onnx.bin.conversion import caffe2_to_onnx
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(caffe2_to_onnx())

.venv-coreml/bin/convert-onnx-to-caffe2

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from caffe2.python.onnx.bin.conversion import onnx_to_caffe2
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(onnx_to_caffe2())

.venv-coreml/bin/csv2rdf

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from rdflib.tools.csv2rdf import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/csvw2datasette

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from csvw.__main__ import csvw2datasette
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(csvw2datasette())

.venv-coreml/bin/csvw2json

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from csvw.__main__ import csvw2json
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(csvw2json())

.venv-coreml/bin/csvw2markdown

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from csvw.__main__ import csvw2markdown
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(csvw2markdown())

.venv-coreml/bin/csvw2sqlite

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from csvw.__main__ import csvw2sqlite
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(csvw2sqlite())

.venv-coreml/bin/csvwdescribe

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from csvw.__main__ import csvwdescribe
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(csvwdescribe())

.venv-coreml/bin/csvwvalidate

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from csvw.__main__ import csvwvalidate
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(csvwvalidate())

.venv-coreml/bin/espeak-phonemizer

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from espeak_phonemizer.__main__ import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/f2py

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from numpy.f2py.f2py2e import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/hf

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from huggingface_hub.cli.hf import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/huggingface-cli

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from huggingface_hub.commands.huggingface_cli import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/isympy

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from isympy import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/jsonschema

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from jsonschema.cli import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/normalizer

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from charset_normalizer.cli import cli_detect
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(cli_detect())

.venv-coreml/bin/phonemize

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from phonemizer.main import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/pip

@@ -1,8 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-# -*- coding: utf-8 -*-
-import re
-import sys
-from pip._internal.cli.main import main
-if __name__ == '__main__':
-    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
-    sys.exit(main())

.venv-coreml/bin/pip3

@@ -1,8 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-# -*- coding: utf-8 -*-
-import re
-import sys
-from pip._internal.cli.main import main
-if __name__ == '__main__':
-    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
-    sys.exit(main())

.venv-coreml/bin/pip3.10

@@ -1,8 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-# -*- coding: utf-8 -*-
-import re
-import sys
-from pip._internal.cli.main import main
-if __name__ == '__main__':
-    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
-    sys.exit(main())

.venv-coreml/bin/pyaml

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from pyaml.cli import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/pybabel

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from babel.messages.frontend import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/rdf2dot

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from rdflib.tools.rdf2dot import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())

.venv-coreml/bin/rdfgraphisomorphism

@@ -1,7 +0,0 @@
-#!/Users/mattmireles/Documents/GitHub/talktome/kokoro-coreml/.venv-coreml/bin/python3
-import sys
-from rdflib.tools.graphisomorphism import main
-if __name__ == '__main__':
-    if sys.argv[0].endswith('.exe'):
-        sys.argv[0] = sys.argv[0][:-4]
-    sys.exit(main())