diff --git a/.claude/commands/mock-sql-audio.md b/.claude/commands/mock-sql-audio.md deleted file mode 100644 index ed5cfe1..0000000 --- a/.claude/commands/mock-sql-audio.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -description: Generate a FULL simulated SQL mock interview as an MP3 you listen to as an observer (local two-voice TTS) -argument-hint: "[N questions] [straight|tough] [archetype focus] [male|mixed] [--play]" -allowed-tools: Bash, Read, Write, ToolSearch, mcp__plugin_voicemode_voicemode__service ---- - -Generate a **fully-simulated, listen-as-an-observer SQL mock interview** and render it to a single **MP3** using Kyle's local Kokoro TTS — interviewer in one voice, ideal candidate in another. This is the audio counterpart to `/mock-sql-interview` (voice, Kyle performs) and `/mock-sql-demo` (text self-play). Target: the **STEAMe Data Analytics Engineer** Postgres SQL screen. The point is for Kyle to **internalize what a strong candidate's think-aloud sounds like** by ear (commute/walk listening, spaced repetition). - -## Parse `$ARGUMENTS` -- Integer → number of SQL questions (default **4**, escalating Easy→Hard). Add a short verbal/behavioral or modeling question only if asked. -- `straight` (default) | `tough` → interviewer probing intensity. -- An archetype/topic (e.g. "window functions", "retention", "rates") → bias question selection. -- `male` → both-male voices (interviewer `am_adam`, candidate `bm_george`); `mixed` (default) → `am_adam` interviewer + `af_bella` candidate. -- `--play` → also play it locally with `afplay` after rendering. - -## Steps -1. **Pre-flight:** ensure Kokoro is up — load the voice tool (`ToolSearch` → `select:mcp__plugin_voicemode_voicemode__service`) and `service(kokoro, status)`; if stopped, `service(kokoro, start)`. Ensure `~/steame-sql-practice/audio/` exists. -2. **Write the script** to `~/steame-sql-practice/audio/script-.txt`, every line tagged `INTERVIEWER:` or `CANDIDATE:` (the renderer ignores blank lines and `#` comments). Content rules: - - Realistic, concise STEAMe interviewer (Thien-An Bui / Scharf vibe). **Postgres** throughout. - - The candidate is the **model to emulate**: runs the **5-beat loop** out loud — CLARIFY (restate + ask grain/ties/NULLs/dialect) → ASSUMPTIONS → SKETCH (names the archetype) → WRITE → TEST EDGES (ties, NULLs, `100.0 *`/`NULLIF`, window frame, fan-out). Tight, no rambling. This is exactly the habit Kyle is training. - - **Speak the SQL, don't dump code.** Expand into natural speech so it's listenable: `SELECT *` → "select star"; `COUNT(*)` → "count star"; `||` → "concatenated with"; `100.0 *` → "a hundred point zero, times"; `GROUP BY` → "group by"; `EXTRACT(YEAR FROM tweet_date) = 2022` → "where extract year from tweet date equals twenty twenty-two". Keep each spoken line a sentence or two. - - **Escalate** across distinct archetypes (rate/conditional-aggregation, top-N per group, nth-per-entity/ROW_NUMBER, MoM-or-YoY growth via LAG, retention/cohort, dedup, gaps-and-islands). Use STEAMe's **learner domain** (programs→cohorts→students→enrollments→placements) when natural; classic tables (`tweets`, `employees`) are fine for canonical ones. - - For each question: interviewer asks → candidate clarifies → candidate solves aloud → interviewer probes once → candidate handles it. - - End with a **spoken DEBRIEF** (interviewer voice): 4-6 "key takeaways for Kyle" — the archetypes covered, the Postgres gotchas, and the narration phrasing to steal. -3. **Render:** run - `cd ~/steame-sql-practice && VOICE_INTERVIEWER= VOICE_CANDIDATE= ./render-dialogue.sh audio/script-.txt audio/mock_sql_.mp3` - (set the two voice env vars per the `male`/`mixed` choice). -4. **Deliver:** `SendUserFile` the MP3 (status proactive) with a one-line caption (length + topics). Tell Kyle it's a normal MP3 — AirDrop it or drop it in Drive for phone listening. If `--play`, run `afplay `. -5. Keep scripts + MP3s in `~/steame-sql-practice/audio/` (ISO-dated; add `_v2`/`_HHMMSS` if regenerating same day). - -## Notes -- This is **local, free, repeatable** — regenerate a fresh interview anytime; no quota. -- For a *conceptual* prep podcast instead (two hosts discussing how to ace the screen), that's NotebookLM's job — use the `interview-prep` skill, not this command. NotebookLM cannot perform a script verbatim, so it's the wrong tool for faithful role-play. diff --git a/.claude/commands/mock-sql-demo.md b/.claude/commands/mock-sql-demo.md deleted file mode 100644 index 83babd9..0000000 --- a/.claude/commands/mock-sql-demo.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -description: Text self-play mock SQL interview — Claude plays interviewer + ideal candidate, then debriefs you -argument-hint: "[observe|full] [straight|tough] [N questions] (or just: go)" -allowed-tools: Bash, Read, Write ---- - -You are running a SQL technical-interview **training simulation** for Kyle (the user). You play **BOTH roles in text** — Interviewer and an Ideal Candidate — and then debrief him. The goal is for Kyle to **learn the patterns and what a "concise, senior" answer sounds like** by watching, then optionally take over. This is the text counterpart to `/mock-sql-interview` (the live voice version where Kyle performs). - -## Context to use -- **Real interview:** STEAMe (Chicago workforce-development B2B SaaS; ex-NowPow team). Role: **Data Analytics Engineer**. Format: **30-min, primarily-SQL, Zoom**. Interviewers: Thien-An Bui + Scharf. Database: **PostgreSQL**. -- **Domain (use when possible — it mirrors theirs):** learners moving through training → jobs. Tables: `programs(program_id, provider_id, name, track)`, `cohorts(cohort_id, program_id, name, start_date, end_date)`, `students(student_id, first_name, last_name, signup_at, status)`, `enrollments(enrollment_id, student_id, cohort_id, enrolled_at, status['completed'|'dropped'|'active'], completed_at)`, `attendance(enrollment_id, session_id, present)`, `assessments(enrollment_id, score, max_score)`, `placements(student_id, employer_id, job_title, placed_at, starting_wage)`, `employers(employer_id, name, industry)`. Use classic tables (`tweets`, `employees`) for canonical problems. These tables are **live in the local practice DB** (`~/steame-sql-practice`, Postgres :5433) — see below. -- **Kyle:** healthcare data analyst, 2+ yrs production **T-SQL** (Epic Clarity, millions of rows), dbt, window functions; pivoting into analytics engineering. Coach two things hard: (1) he **rambles** under open-ended questions — model tight, structured narration; (2) he's **converting T-SQL → Postgres** — use Postgres idioms (`LIMIT`, `||`, `EXTRACT`, `::`, `FILTER (WHERE …)`, `NULLIF`, `DATE_TRUNC`) and flag where a T-SQL habit (`TOP`, `GETDATE`, `DATEDIFF`, `ISNULL`, `IIF`) would bite. - -## Parse `$ARGUMENTS` -- Mode: `observe` (default) or `full`. Difficulty: `straight` (default) or `tough`. An integer = number of questions. -- `go` (or empty) → Mode 1 (observe), straight, starting with the DataLemur **"Histogram of Tweets"** problem (`tweets(tweet_id, user_id, msg, tweet_date)`; histogram of tweets-per-user in 2022). If empty, first ask Kyle: mode, difficulty, how many questions — unless he said "go". - -## Bonus you have here that the pasteable version doesn't -Because this runs in Claude Code with a live DB, the **Ideal Candidate may verify its SQL** by running it against the local practice DB (`cd ~/steame-sql-practice && ./db.sh run "…"`) for domain questions — a nice "and here's the actual output" touch. Keep it snappy; don't let verification stall the demo. - -## MODE 1 — OBSERVE PER QUESTION -For each question do all four, then **STOP and wait** for Kyle to say `next` (or `let me try`): -1. **Interviewer:** ask ONE realistic question (state it like a human; don't dump the schema unless the candidate asks). -2. **Ideal Candidate:** answer with full think-aloud using the **5-beat loop** — CLARIFY (restate + ask grain/ties/NULLs/dialect) → ASSUMPTIONS → SKETCH (name the archetype out loud) → WRITE (clean Postgres in a code block, CTEs over nesting) → TEST EDGES (ties, NULLs, divide-by-zero, window frame, fan-out). -3. **Interviewer probes** once or twice; candidate responds crisply. -4. **DEBRIEF — "Key takeaways for Kyle":** 3–5 bullets — what made it strong, the underlying **pattern/archetype**, the **Postgres gotcha**, and **one phrase he should steal** for his own narration. - -## MODE 2 — FULL INTERVIEW -Run a complete ~30-min mock end-to-end, both roles inline, no stopping: ~5 SQL questions escalating Easy→Hard, plus one short **behavioral/verbal** ("walk me through a time you defined a metric others relied on") and one **modeling** question ("how would you build curated tables for a placement-outcomes dashboard?"). THEN one consolidated **DEBRIEF**: per-question takeaways + an overall scorecard (Correctness / Communication / Edge-cases / Postgres fluency, 1–5 each) + **his top 3 things to drill next**. - -## Question coverage -Spread across the high-frequency archetypes: conditional-aggregation rate (CTR/completion %), top-N per group, nth-per-entity (ROW_NUMBER), MoM/YoY growth (LAG), retention/cohort, dedup (ROW_NUMBER=1), anti-join, rolling average, gaps-and-islands. - -## Rules -- The Ideal Candidate must MODEL the habits Kyle lacks: short sentences, names the archetype immediately, states assumptions, always checks ties/NULLs/`100.0 *`/`NULLIF`. **No rambling** — show what "concise and senior" sounds like. -- Keep Interviewer turns short and realistic. Show all SQL in Postgres syntax in code blocks. -- If Kyle says **`let me try`**, flip roles: he becomes the candidate, you become Interviewer + grader — give the question, let him answer, then score him on the rubric and contrast with the ideal answer. -- `harder`/`easier` → adjust difficulty; `my domain` → use the STEAMe learner tables; `debrief` → summarize takeaways so far. -- Log anything Kyle should drill to `~/steame-sql-practice/MISS-LIST.md` (create if missing). diff --git a/.claude/commands/mock-sql-interview.md b/.claude/commands/mock-sql-interview.md deleted file mode 100644 index 9a3d52e..0000000 --- a/.claude/commands/mock-sql-interview.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -description: Live VOICE mock SQL interview — Claude is the interviewer, you write & run real SQL out loud -argument-hint: "[problem name | datalemur url | random | miss-list] [straight|tough] [text]" -allowed-tools: Bash, Read, Write, WebFetch, ToolSearch, mcp__plugin_voicemode_voicemode__converse, mcp__plugin_voicemode_voicemode__service ---- - -You are running a **live, one-problem-at-a-time mock technical interview** for Kyle (the user). This is the "Option 1" voice workflow: **you are the interviewer**, Kyle is the candidate who thinks aloud and writes/runs real SQL in this terminal. Default target is the **STEAMe Data Analytics Engineer** 30-minute, primarily-SQL, **PostgreSQL** screen (interviewers Thien-An Bui + Scharf). Kyle's known weak spot: he **rambles under open-ended questions** and is **converting from T-SQL → Postgres** — coach toward tight narration and Postgres idioms. - -## Parse `$ARGUMENTS` -- A problem name, a `datalemur.com/...` URL, `random`, or `miss-list` → which problem to run. If empty, pick the next sensible one (start Easy, escalate). `miss-list` = pull from `~/steame-sql-practice/MISS-LIST.md` if it exists. -- `tough` → probe harder, fewer hints, add a curveball follow-up. `straight` (default) → fair, supportive senior-engineer tone. -- `text` → skip voice, run the whole thing in text (fallback). - -## Pre-flight (do this silently, then a 1-line ready check) -1. **Load the voice tools** (deferred): `ToolSearch` → `select:mcp__plugin_voicemode_voicemode__converse,mcp__plugin_voicemode_voicemode__service`. -2. **Verify services**: `service(whisper,status)` and `service(kokoro,status)`. If either is stopped, `start` it. If voice is unavailable, fall back to text mode and say so. -3. **Verify the practice DB**: `cd ~/steame-sql-practice && ./db.sh status` — if down, `./db.sh start`. The DB is local Postgres on port 5433, db `steame_practice`, controlled via `./db.sh {psql|run|file}`. -4. **Set up the problem's data** if it isn't already in the DB: - - DataLemur problems → fetch the page with `WebFetch`, get the exact schema + sample rows + expected output, and `CREATE`+`INSERT` a mirror table so Kyle can run it locally. Silently self-check that your mirror reproduces DataLemur's stated expected output before starting. - - STEAMe-domain problems → already loaded (programs→cohorts→students→enrollments→attendance→assessments→placements→employers). See `~/steame-sql-practice/README.md`. -5. **Ready check (one line):** remind Kyle to put **headphones on** (so your TTS doesn't feed back into his mic) and confirm he's somewhere he can talk. Wait for "go". - -## Voice settings for `converse` -- `tts_provider: kokoro`, high `listen_duration_max` (e.g. 150–180) so you never cut him off mid-thought, `listen_duration_min: 2`. Keep your spoken turns **short** — real interviewers don't monologue. - -## The interview loop (per problem) -1. **Mic check** (first call only): short converse — "Mic check for your STEAMe SQL mock. If you hear me, say you're ready." Confirm the round-trip works. -2. **Pose the question by voice** — state it like an interviewer (no schema dump unless asked; make him ask for grain/columns). Then listen for **clarifying questions**. -3. **Answer clarifiers aloud.** Reward him for asking about grain, ties, NULLs, date range, dialect. If he asks none, note it. -4. **Let him solve in the terminal.** He narrates the **5-beat loop** (clarify → assumptions → sketch → write → test edges) while typing and running SQL via `./db.sh psql`. Silent typing gaps are fine; he cues you by speaking ("okay, running it"). Do **not** give the answer; offer a hint only if he's stuck and asks. -5. **React to his actual result** (you can see the query + output in this terminal). Probe by voice: ties? NULLs? divide-by-zero / `100.0 *` / `NULLIF`? window frame? wrong ranking fn? join fan-out/grain? In `tough` mode add one curveball ("now do it without window functions" / "what if a user tweeted 0 times — should they appear?"). -6. **Score aloud + in text** on five dimensions (1–5 each), with specifics: - - **Correctness** (right rows, right grain) - - **Approach/efficiency** (named the archetype; clean CTEs) - - **Communication / think-aloud** ← his focus area; call out any rambling vs. crisp narration - - **Edge-case handling** (ties, NULLs, 0-division, frame, dialect) - - **Postgres fluency** (LIMIT, `||`, EXTRACT, `::`, FILTER — not T-SQL reflexes) -7. **Log a miss** if anything was wrong/slow → append a one-line entry to `~/steame-sql-practice/MISS-LIST.md` (create if missing) so it feeds spaced repetition. -8. Ask if he wants **another problem** (and at what difficulty), or to stop. - -## Style -Concise, fair, a little pressure. Don't coach mid-solve beyond a real interviewer would; save the teaching for the score. Reference his prep when useful (`~/steame-sql-practice/PREP-PLAN.md`, `problems.md`, `solutions.sql`, and the dossier at `~/Cowork/second-brain/30-job-search/dossiers/steame/`). Keep it to one problem unless he asks for a full sequence. diff --git a/CLAUDE.md b/CLAUDE.md index 7c8cee0..ea36c81 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -145,9 +145,6 @@ Global commands (`.claude/commands/`) and skills (`.claude/skills/`) vendored fr - 💻 `/envsetup` — open `.env` in the editor + the credential's generation page in Chrome, with a key stub pre-added. - ✅ `/explore-plan` — explore → plan → confirm before any code; proposes 2–3 ranked approaches and waits for a pick. - ✅ `/handoff` — generate a paste-ready handoff prompt for a fresh session; captures lessons + plan state. (Optional audio is local-only.) -- 💻 `/mock-sql-audio` — full simulated SQL mock interview as an MP3 (local two-voice TTS). -- ✅ `/mock-sql-demo` — text self-play mock SQL interview (interviewer + ideal candidate), then a debrief. -- 💻 `/mock-sql-interview` — live voice mock SQL interview (local voice mode). - ✅ `/prompt-optimize` — one-shot prompt rewrite: diagnose, pick a workflow archetype + model + effort, return a ready-to-paste prompt. Advisory only. - ✅ `/reframe-orchestrator` — reframe `.claude/orchestrator.md` into a mode-independent invariants & gates doc; docs-only. - 💻 `/screenshot-iterate` — visual loop: implement against a mock, screenshot the running app, compare, iterate.