From autopilot
Produce a flight-podcast episode that steelmans a repo on engineering merits, then critiques it on file-pinned tensions. Local orchestration — research + dialogue happen under Claude Code supervision; render + Telegram delivery reuse the existing Pimsleur dispatch path. Invoked as `/autopilot podcast steelman OWNER/REPO`.
How this skill is triggered — by the user, by Claude, or both
Slash command
/autopilot:podcast-steelmanThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
An adversarial-angle flight-podcast episode done the honest way: read enough of the repo to genuinely advocate for it first, then identify engineering tensions pinned to specific files and mechanisms. Fits into the existing `flight-podcast-2026-04-ext` series (ep 44+) at the currently scheduled `japanese_ratio`.
An adversarial-angle flight-podcast episode done the honest way: read enough of the repo to genuinely advocate for it first, then identify engineering tensions pinned to specific files and mechanisms. Fits into the existing flight-podcast-2026-04-ext series (ep 44+) at the currently scheduled japanese_ratio.
This skill does not replace /podcast or /autopilot podcast pimsleur. It is a specific rhetorical mode for repo critique episodes — when the interesting thing about the repo is not "look how it's built" but "look at the seam between what it claims and what it does."
Use when the user says /autopilot podcast steelman <OWNER/REPO> or asks to "critique," "tear down with respect," or "do an adversarial episode on" a specific GitHub repo. Do not use for:
/autopilot podcast pimsleur)./podcast.These are why earlier attempts at this format produced cheap takes. Do not:
agent/prompts/system.ts:L142 as a regex match on user input before the LLM call, which fails under paraphrase" is pinned./autopilot podcast pimsleur) or gets dropped from the queue. Do not manufacture tensions.Argument shape: OWNER/REPO (required). Optional second argument: EP=NN to pin the episode number; otherwise read data/japanese/profile.yaml.episodes_completed + 1.
Confirm with the user: repo + episode number + scheduled japanese_ratio (read from data/japanese/schedule.yaml for that ep slot if it exists). If the ep slot doesn't exist in schedule.yaml, ask the user to either append one or re-run with an existing slot.
Spawn a general-purpose subagent with a prompt that includes, verbatim:
Research
OWNER/REPOthoroughly enough to advocate for it on engineering merits. You are writing a steelman, not a critique. Any critique belongs in a later pass.Required sources (use
gh apivia Bash):
gh api repos/OWNER/REPO/readme --jq .content | base64 -dgh api repos/OWNER/REPO/git/trees/main --jq '.tree[] | select(.type=="tree") | .path'- Read 3–5 key source files. Pick by informed guess based on the tree. Prefer files that encode the architectural thesis (runtime loop, agent core, prompt layer, plugin loader, memory store).
- Docker / compose / CI if present.
Walk the six axes as an advocate: compute topology, LLM locus, tool mechanics, extension loading, context & memory strategy, scaling topology. For each axis, state what the repo does well and why that choice is reasonable given its constraints. Cite real file paths.
Write the output to
research/<slug>_steelman.mdwith frontmatter:repo,slug,sources(list of real file paths consulted), and sections:What this repo actually achieves,Six-axis walk (advocating),The contribution(one paragraph on what the repo adds to the field that wasn't there before).Do NOT identify tensions, flaws, or critiques in this pass. The steelman must stand on its own.
Slug: lowercased OWNER-REPO with / replaced by -.
After the subagent returns, open research/<slug>_steelman.md. Read it end-to-end. Spot-check at least one cited file path via gh api to confirm the subagent isn't inventing.
Show the user a one-paragraph summary of the steelman plus the three most-cited file paths. Ask:
Does this repo have a real engineering tension worth an episode on, or should it become a straight deep-dive / drop from the batch?
Wait for an explicit answer. Acceptable replies: proceed / tension: <one-line description> / straight deep-dive / drop.
If drop: remove the ep slot from schedule.yaml if one was created for this run, commit, done.
If straight deep-dive: hand off to /autopilot podcast pimsleur with the existing ep slot. Do not proceed through this skill.
If proceed or tension: ...: continue to Step 3. If the user named a specific tension, pass it to the tells subagent as a hypothesis to verify (not to assume).
Spawn a second general-purpose subagent:
You have access to
research/<slug>_steelman.mddescribing whatOWNER/REPOachieves. Your job is to identify engineering tensions — places where the architecture strains or the claims don't fully land. Every tension must be pinned to a specific file (with path) and a specific mechanism.Hypothesis to verify (if provided):
<user's one-line tension description or "none — open search">. If provided, investigate it first. If the code does not support the hypothesis, say so clearly and report what the code actually shows.Research method: read the files cited in the steelman more carefully, plus 2–5 additional files the steelman didn't cover. Look at: prompt files (system prompts, guardrails), executor boundaries (where LLM output becomes action), error handling paths, test coverage on the riskiest mechanisms, config surface (what users can change vs. what's hardcoded).
For each tension, write:
- What the repo does (one sentence, neutral)
- The file + mechanism (path + function/section + quoted snippet if short)
- Why this is a tension (one paragraph — the engineering argument, not a vibe)
- What the authors probably intended (steelman the choice)
- The calibrated critique (one or two sentences — where this breaks, under what conditions, how a listener could verify)
Forbidden: star counts, analogy without code, generalization without repo-specific evidence, debasing framing.
If after honest research you find no tension that survives file-level scrutiny, write
NO_TENSION_FOUNDas the first line of the file and a paragraph explaining what you looked for and why it didn't land. Do NOT manufacture a tension to fill the file.Output:
research/<slug>_tells.md.
After return, read the file. If NO_TENSION_FOUND, fall back to the drop / straight-deep-dive paths from Step 2 and inform the user.
Spawn a third subagent (dialogue writer). It receives both artifacts and writes briefs/2026-04-22-flight-podcast/ep_NN.md.
Prompt includes the standard TEMPLATE-DEEP-TECHNICAL preamble from automations/flight-podcast/TEMPLATE-DEEP-TECHNICAL.md plus the steelman-format overlay below.
5-segment structure (modified):
Rhetorical guardrails for the dialogue subagent:
research/<slug>_tells.md. No new paths invented in dialogue.Run the standard density + pairing verifier on briefs/2026-04-22-flight-podcast/ep_NN.md:
python3 /home/clsandoval/.claude/skills/autopilot/scripts/verify-dialogue.py <path>
Additionally grep for debasing vocabulary:
grep -niE '\b(slop|farm|fake|junk|garbage|trash|debasing)\b' briefs/2026-04-22-flight-podcast/ep_NN.md
Any hit = flag to user, do not auto-rewrite. User decides whether the usage is warranted.
Show the user: density report, pairing report, grep results, and the --- [synthesis] --- segment verbatim (since the "principle" beat is the rhetorical load-bearing one). Ask for approval to dispatch.
Hand off to the existing script:
EP=NN bash automations/flight-podcast/dispatch-ep.sh
The script handles upload + session creation + brief. Session ID appends to .superpowers/autopilot-sessions.json. Steelman format requires no changes to the render path — it's pre-written dialogue mode.
Commit both research artifacts (research/<slug>_steelman.md, research/<slug>_tells.md) alongside the dialogue. These are the evidence trail; future episodes can cite them as prior-art when a repo comes up again.
Commit message: podcast: ep NN steelman+tells+dialogue for OWNER/REPO.
research/<slug>_steelman.md — advocacy artifactresearch/<slug>_tells.md — file-pinned tensions (or NO_TENSION_FOUND)briefs/2026-04-22-flight-podcast/ep_NN.md — dialogue.superpowers/autopilot-sessions.jsongh api per research pass. If inventions found, re-dispatch with stricter "cite only files you actually read" prompt.Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub clsandoval/claude-autopilot