DEV Community: Haider Farooq

Claude Code Skills for Content: How I Make Khan Academy Style Videos for Free

Haider Farooq — Sun, 11 Oct 2026 00:27:42 +0000

I opened a LinkedIn post last week with "I think Claude Code skills are mostly useless." It got about 30,000 impressions and a lot of disagreement, so let me be precise about what I meant, and about the one skill that changed my mind.

A skill is a markdown file Claude Code reads when your request matches its description. Most of the ones I have seen are prompt shortcuts: a paragraph of instructions you would otherwise type again. Claude is already good enough to do that work from a plain sentence. Saving the sentence is not worth a repo.

The exception is a skill that ships something Claude cannot improvise in one shot. A renderer. A capture recipe that took a day to get right. A list of rules learned from thirty failed outputs. That kind of skill is a tool with a manual, and the manual is what the model reads. khan-explainer is that kind. I built it to make Khan Academy style explainer videos, where a pen draws on a blackboard while a voice explains, and the whole thing runs free on a laptop with no API keys. Two days after I published it, it had 58 stars, 16 forks and a merged pull request from someone I had never met.

Nobody is holding this pen. Claude Code drew this video from a prompt. The voice is ElevenLabs; everything else is free. Watch it on YouTube: https://youtu.be/JD9OirRC3YE

What it makes

Blackboard lessons. A diagram drawn stroke by stroke while the voice explains it. The original Khan Academy look.
Draw-over-UI tutorials. Arrows, circles and numbered steps drawn over your own product screenshots. "Press this, then this."
Real-audio clips. A YouTube video or podcast in, vertical shorts out. The speaker's own voice plays while the board is drawn to their words. It can also cut the speaker out of the frame and stand them in front of the board.

Every mode renders as chalk on a blackboard or marker on a whiteboard, landscape or vertical. One environment variable switches the theme, and a single beat can flip the board mid-video.

The same scene file, rendered dark and light. Colour names map to chalk on one and marker on the other.

The stack, and why it costs nothing

There is no video model anywhere in this. Four boring pieces do the work:

An HTML canvas draws the handwriting. Every letter and shape is a path, revealed a little more on each frame. A handwriting font plus progressive stroke drawing is enough to read as a hand.
Playwright opens that page in headless Chromium and screenshots it frame by frame. This is the same tool people use for browser tests. It is also a perfectly good frame grabber.
macOS say speaks each line to an audio file. It is robotic, but it is free, it is on every Mac, and it reports exactly how long each clause takes.
ffmpeg stitches the frames and the audio into an MP4.

That is the full bill of materials. The commercial tools that make this style of video charge monthly subscriptions. Manim can do it and is beautiful, but it is a library you learn, not a prompt you type. AI video generators bill per second and cannot draw a diagram that stays consistent for sixty seconds. For a teaching video, the pen is the point, and the pen is just canvas strokes.

The one idea that makes it work: the voice drives the clock

Every attempt at this that I have seen fails the same way. Someone writes a script, guesses that a sentence takes three seconds, animates to three seconds, and then the voice lands early or late. By the fourth sentence the pen is drawing the wrong thing.

khan-explainer never guesses. A scene is a list of beats. A beat is one spoken clause plus the drawing that happens while it is said. The renderer speaks each beat first, measures the audio, and gives that beat's drawing exactly that long. Nobody types a timestamp, so the pen cannot run ahead of the words.

scene({
  beats: [
    { say: 'What is an AI agent?', draw: p => {
        write('What is an AI agent?', 60, 85, p, { size: 56, color: C.yellow });
    } },
    { say: "It's software that uses a language model to think,", draw: p => {
        stroke(oval(300, 330, 155, 82), seg(p, 0, .4), { color: C.blue });
        write('1. THINK', 300, 328, seg(p, .4, 1), { size: 40, color: C.blue, center: true });
    } },
  ],
})

p runs from 0 to 1 while the clause is spoken. seg(p, 0, .4) spends the first 40% of the beat on the oval and the rest on the label. That is the entire timing model. Claude writes these scene files from a one-line prompt because the rules are short enough to hold in its head.

Using it

git clone https://github.com/haiderfarooq3/khan-explainer ~/.claude/skills/khan-explainer
cd ~/.claude/skills/khan-explainer/scripts && npm install && npx playwright install chromium

Then ask Claude Code for the video you want. "Make a 30-second Khan-style explainer on how DNS works." "Draw over these screenshots and show a new user how to send their first invoice." "Khanify this YouTube video, light and dark." Claude writes the scene, renders it, reads the contact sheet, fixes what is wrong, and hands you the MP4.

Tricks that transfer to any content skill

The renderer is maybe a third of the value. The rest is the rules in the skill file, and most of them apply to any skill that produces content, whether that is video, slides, ads or diagrams. These are the ones that earned their place.

1. Make the skill grade its own output

Every render prints a contact sheet: the board at the end of every beat, in one image, plus every beat full-size as b000.jpg, b001.jpg and so on. The renderer also prints WARN lines for text that runs off the board or one label sitting on another. Claude is told to read the sheet and fix every warning before showing you anything. A render takes seconds, so it iterates three or four times and you only see the last one. Whatever your skill makes, give the model a cheap way to look at the result. Without it, you are the QA department.

2. Lay out with the free voice, switch on the expensive one last

say is free and instant, so all the layout work happens with it. When the board is right, you add an ElevenLabs voice id to the scene. The whole script is read in one take so it sounds like one person talking, then cut back into beats at the character timestamps the API returns. Takes are cached by a hash of the script, so re-rendering the same words is free. Changing one drawing costs nothing. Changing one word buys a new take. Order the work so the paid step runs once.

3. Keep the units small enough to re-render

The most common question under the LinkedIn post was from a teacher: if one step in a worked solution is wrong, can I fix that step, or does it need a full rerun? The answer is that you edit one beat and re-render, and the new file exists a few seconds later. That is only possible because a beat is a few lines of JavaScript, not a timeline in an editor. Design the unit of content so a human can point at one of them and say "that one is wrong."

4. Measure, never eyeball

For draw-over-UI tutorials the skill captures screenshots with Playwright and saves getBoundingClientRect() for every button and field it will point at. It never reads coordinates off the image. It also measures again for every state, because elements move when they are focused, typed into, or when a menu opens over them. The view() helper maps capture pixels to board units so the rings land on the right button at any crop. The early tutorials where I let the model guess coordinates from the screenshot all circled the wrong thing.

5. Write the script once, theme-neutral, and cut everything from it

The video in this post exists in four cuts: dark and light, landscape and vertical. They share one voice take because the script never says "blackboard" or "left". The theme is a flag, the aspect ratio is a size, and the voice cache does not care about either. If your content needs variants, decide what the variants are before the first expensive step, and keep anything variant-specific out of the shared layer.

6. Hit a target length by changing words, not speed

A quick explainer runs about words ÷ 3 + beats × 0.15 + 1.3 seconds, within roughly 5%. A ten-second explainer is about 24 words in 5 beats. A 60-second tutorial is about 145 words in 15 beats. The skill file includes this formula so Claude can plan a 30-second video that is actually 30 seconds, instead of speeding up the voice until it fits. Speeding up the voice is how you get the "too AI" complaint.

7. Put the failures in the skill file

Every bad render taught the skill something, and the lesson went into SKILL.md where the model reads it. A few examples. ElevenLabs' multilingual model at speed 1.12 with style 0.35 sounded, in the words of the first person I showed it to, "too AI", so the skill now uses the v3 model and speeds the finished video with ffmpeg's atempo instead. Screenshots are dimmed towards the board colour so chalk stays readable on a busy screen. Private data is hidden in the page before any still is taken. Demos are never staged in a shared or public channel. One render stalled forever once, so the build script has a watchdog. None of this is clever. It is the difference between a skill that works on the second try and one that works on the tenth.

8. Real audio is a different product, not a feature

The clip mode downloads a video with yt-dlp, transcribes it locally with faster-whisper, and lets you mark the moments worth a board. Each clip gets its own scene drawn to the speaker's own words, and a macOS Vision cutout can stand the speaker in front of the board for the vertical version. One 20-minute talk became 22 clips in an afternoon. The reason to mention it here: the renderer did not change at all. Once timing comes from measured audio, the audio can come from anywhere.

Where it falls short

The default voice is robotic. For anything you publish, you will want ElevenLabs or a real recording.
It is macOS first. say and the Vision cutout are Apple APIs. The renderer itself is a browser page, and the first outside contribution (right-to-left writing for Arabic and Hebrew) was tested on Windows by driving board.html directly, but a Windows voice path does not exist yet.
The handwriting is a font drawn progressively, not a model of a hand. It reads well at normal speed and less well paused.
It is not affiliated with Khan Academy. The name describes the look.

Why this is a blog post and not just a LinkedIn post

Two days after the post went up, I ran a sweep of every public surface I could reach: X, Reddit, Hacker News, YouTube, newsletters, skill directories, package registries. Outside GitHub, not one human had mentioned the repo. The only pickups were two crawlers. Bing had not indexed the repository at all. The LinkedIn post itself, with its 30,000 impressions, is invisible to every search engine; the exact hook line returns nothing.

That is the deal with social: a day of reach, then nothing. A video you post to a feed is gone from the record in a week. A page on a domain you own is a search result for years, gets cited by AI answer engines, and is where the repo can point back to. This post is that page. If you build something and it does well on a feed, write it down somewhere with a URL you control, the same week, while the traffic is still there to link to it.

If you want to see the other formats I make this way, the content catalogue has one finished example of each. If you want this kind of pipeline built for your product, the usual place to start is the contact page. And if you just want the skill, it is on GitHub, MIT licensed. Go draw something.

Questions people asked

Is khan-explainer really free?

Yes. It renders with an HTML canvas in headless Chromium (Playwright), the voice built into macOS (say), and ffmpeg. There are no API keys, accounts, or usage limits. The only optional paid part is swapping the Mac voice for an ElevenLabs voice, and even that works on the free tier for short scripts.

Does it work on Windows or Linux?

The default voice and the talking-head cutout are macOS only. The renderer itself is a browser page driven by Playwright, so the first outside contributor tested their change on Windows by driving board.html directly. Linux works with espeak-ng in place of say. Full Windows support would need a different TTS call.

How long does a render take?

Seconds. The 65-second video in this post rendered in under a minute on a laptop. The voice is generated first, then each beat's drawing is fitted to it, then ffmpeg stitches frames and audio.

Can I fix one wrong step without re-rendering everything?

Yes. A scene is a list of beats. Edit the beat, re-render, and you have a new MP4 in seconds. If you are using an ElevenLabs voice, the take is cached, so changing only the drawing costs nothing.

Can it use my own voice or a real person's voice?

Yes. The real-audio mode takes a YouTube link or an audio file, transcribes it locally with faster-whisper, and draws the board to the speaker's words. One 20-minute video produced 22 clips. For a synthetic human voice, set an ElevenLabs voice id on the scene.

Is it affiliated with Khan Academy?

No. 'Khan Academy style' describes the look: handwriting on a dark board, drawn as it is explained. The project is independent and MIT licensed.

Originally published at haiderfarooq.dev.

RAG That Actually Works: A Practical Checklist

Haider Farooq — Fri, 21 Aug 2026 10:12:38 +0000

Retrieval-augmented generation is the most requested AI feature and the most commonly botched. The failure is almost never the generation step -- it's retrieval quietly returning the wrong context, and the model confidently summarizing garbage. This checklist comes from building research and analysis pipelines where wrong retrieval means wrong business decisions.

Chunking: respect the document's own structure

Fixed 512-token windows sliced mid-sentence are the default and the mistake. Chunk on semantic boundaries -- headings, paragraphs, table rows -- and prepend each chunk with its breadcrumb ("Annual Report 2025 > Risk Factors > Currency"). A chunk that can't be understood alone can't be retrieved reliably.

Hybrid search beats embeddings alone

Dense vectors miss exact identifiers -- SKUs, names, error codes -- that keyword search catches trivially. Run BM25 and vector search in parallel and fuse results (reciprocal rank fusion is fine). This one change fixes a huge share of "the answer was in the corpus but retrieval missed it" tickets.

Rerank before you generate

First-stage retrieval optimizes recall; a cross-encoder reranker optimizes precision on the top 30-50 candidates. Feeding the model 6 highly relevant chunks beats feeding it 20 mediocre ones -- better answers and lower token spend.

Metadata filters are half the battle

Store structured fields (date, source, doc type, customer) alongside every chunk.
Resolve filters before semantic search -- "latest pricing" should hard-filter on recency, not hope embeddings notice.
Let the LLM extract the filter from the question with a typed schema, then apply it in the database.

Answer honesty: refuse to guess

The system prompt must make abstention a first-class outcome: if the retrieved context doesn't contain the answer, say so and show what was found. Require citations to chunk IDs and render them in the UI. Users forgive "not found"; they don't forgive confident fabrication.

Evaluate retrieval separately from generation

Build a golden set of ~50 real questions with known source passages.
Measure retrieval hit-rate (is the right chunk in the top-k?) -- this isolates most failures.
Then grade end-to-end answers for faithfulness and completeness.
Re-run on every change to chunking, embeddings, or prompts.

RAG is a search-quality problem wearing an AI costume. Treat it with the same rigor as the rest of your production agent stack, and it stops being the feature users quietly distrust.

Originally published at haiderfarooq.dev.

7 Lessons from Building Agentic AI in Production

Haider Farooq — Fri, 21 Aug 2026 10:01:55 +0000

For the past year I've been a core engineer on TryCook.ai, an AI operating system that replaced a $3M/year fulfillment team and powers 348+ founders. That means agents doing real, billable work every day -- not demos. Here are the seven lessons that survived contact with production.

1. The agent is 20% of the system

The LLM call is the easy part. The other 80% is queues, retries, idempotency keys, state machines, audit logs, and rollback paths. If you architect the agent as a stateless function inside a boring, observable pipeline, failures become recoverable. If the agent is the pipeline, every hallucination is an outage.

2. Constrain outputs structurally, not rhetorically

Prompts that beg the model to "only respond with valid JSON" fail at scale. Schema-enforced outputs (tool calling, JSON mode, grammar constraints) fail approximately never. Every agent boundary in our stack is a typed contract -- if the model can't fill the schema, that's a retry, not a parse error downstream.

3. Design for the 2% failure case first

An agent that's 98% autonomous still fails dozens of times a day at volume. The difference between a product and a liability is what happens on failure: does the task land in a human review queue with full context, or does it silently vanish? Build the escalation path before you build the happy path.

4. Small models for routing, big models for judgment

Most agent steps are classification, extraction, or formatting -- cheap-model work. Reserve frontier models for the few steps that need actual judgment. This is the core of cost engineering for LLM products, and it routinely cuts spend 5-10x with no quality loss.

5. Memory is a database problem, not a prompt problem

Long-running agents need durable state: what they did, what they learned, what the customer prefers. Stuffing history into the context window doesn't scale and isn't queryable. Model agent memory as normal rows -- events, facts, preferences -- and retrieve selectively. Retrieval discipline is the same skill as building RAG that works.

6. Evals are your regression tests

Every prompt change ships against a fixed eval set of real (anonymized) cases with graded outputs. Without evals, prompt engineering is vibes; with them, it's engineering. Start with 30 cases and a pass/fail rubric -- you can grow sophistication later, but you can't retrofit confidence.

7. Humans are a feature, not a fallback

The systems that win don't remove humans -- they move humans up the stack. In a well-designed agentic system, one operator supervises the throughput that used to take a team, intervening only on flagged exceptions. Frame it that way and adoption stops being a fight.

Agents don't replace engineering discipline. They punish the lack of it, at machine speed.

Originally published at haiderfarooq.dev.

How to Get Cited by AI Search Engines: A Practical GEO Checklist

Haider Farooq — Fri, 21 Aug 2026 09:59:59 +0000

Search is splitting in two. Classic Google still matters, but a growing share of discovery now happens inside ChatGPT, Perplexity, Claude, and Google's AI Overviews. Those engines don't rank ten blue links — they synthesize an answer and cite a handful of sources. Getting cited is the new ranking. The practice of engineering for it is called Generative Engine Optimization (GEO), and this post documents the exact setup running on my site.

1. Let the AI crawlers in

Every AI engine has its own crawler, and many sites block them by accident with a blanket rule. Your robots.txt should explicitly allow the bots you want: GPTBot and OAI-SearchBot (OpenAI), PerplexityBot, ClaudeBot and anthropic-ai (Anthropic), Google-Extended (Gemini training), Applebot-Extended (Apple Intelligence), and CCBot (Common Crawl, which feeds many models).

User-Agent: GPTBot
User-Agent: OAI-SearchBot
Allow: /

User-Agent: PerplexityBot
Allow: /

User-Agent: ClaudeBot
Allow: /

Sitemap: https://haiderfarooq.dev/sitemap.xml

2. Ship an llms.txt

llms.txt is an emerging convention: a plain-markdown file at your site root that gives language models a compressed, structured summary of who you are and what your pages contain. Think of it as a sitemap for meaning rather than URLs. Keep it under a few hundred lines, lead with a one-sentence identity statement, and list your key pages with one-line summaries each. A fuller llms-full.txt can carry the long version.

3. Build an entity graph with JSON-LD

AI engines resolve entities, not keywords. Schema.org JSON-LD is how you declare them unambiguously. The minimum viable graph for a personal site: a Person node with @id, sameAs links to GitHub/LinkedIn/X, knowsAbout, and hasOccupation; a WebSite node; and CreativeWork or Article nodes for project pages. Crucially, use stable @id URIs and reference them across pages so crawlers can stitch the graph together.

{
  "@type": "Person",
  "@id": "https://haiderfarooq.dev/#person",
  "name": "Haider Farooq",
  "jobTitle": "AI Engineer & Data Scientist",
  "sameAs": [
    "https://github.com/haiderfarooq3",
    "https://www.linkedin.com/in/haiderfarooqdev/"
  ]
}

4. Write outcome-first copy

LLMs extract and repeat concrete numbers. "$12.1M in client revenue", "141 districts", "5,500+ patients" — figures like these survive summarization; adjectives don't. Put at least one hard number in the first 150 words of every page. Write bios in third person ("Haider Farooq is an AI engineer…") because that's the frame AI answers use when citing you.

5. Freshness and internal linking still matter

Update pages on a real cadence — stale lastmod dates in your sitemap depress recrawl priority.
Interlink related pages with descriptive anchor text; AI crawlers follow links to build context just like Googlebot does.
Use IndexNow to ping Bing (which feeds ChatGPT search and Copilot) the moment content changes.
Keep canonical URLs consistent — one host, one protocol, no trailing-slash ambiguity.

The checklist

robots.txt allows GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended, CCBot
llms.txt + llms-full.txt at site root
JSON-LD Person/WebSite/Article graph with stable @id URIs
One concrete metric in the first 150 words of every page
Sitemap with honest lastmod dates, submitted to Google Search Console and Bing
IndexNow key installed and pinged on every deploy

None of this replaces good content — it makes good content legible to machines.

Originally published at haiderfarooq.dev.