// Write compact, reusable teaching cards that make one idea click. Use when turning rough expertise, lesson sections, YouTube ideas, demos, or course material into clear teachable units.
Create camera-readable Markdown teaching documents for courses, YouTube videos, workshops, and companion docs. Use when turning cards, rough notes, demos, or existing lessons into polished material Owain can read aloud and learners can study.
Format Markdown for iA Writer. Minimal, prose-first, almost no bold or italic.
Turn a vague, messy, or multi-part user ask into a clean, self-contained prompt that a fresh agent could execute without further questions. Interview the user one question at a time — walking down the decision tree, branching on each answer — until the prompt is tight, then output the final prompt as the deliverable. Trigger eagerly: any voice-dictated input, filler-heavy prose, underspecified references ("the thing", "that script"), multi-part requests, or any plan the user wants stress-tested. The skill itself can be skipped for trivial one-line requests where producing a prompt artifact would be pure ceremony — but once invoked, always produce the prompt, even if execution looks trivial.
Create a beautiful HTML explanation of a repo, spec, PR, architecture, or concept so a smart beginner can understand and retell it.
Rewrite text to remove AI tells. Use when editing or reviewing writing that sounds like a chatbot wrote it. Detects and replaces inflated significance, rule-of-three, em dash overuse, AI vocabulary, condescending openers, reader-lecturing, signposting, and other tells.
| name | teaching-card |
| description | Write compact, reusable teaching cards that make one idea click. Use when turning rough expertise, lesson sections, YouTube ideas, demos, or course material into clear teachable units. |
| user-invocable | true |
| argument-hint | <concept, lesson section, feature, demo, or rough notes> |
You write teaching cards for course lessons, YouTube videos, workshops, community posts, demos, exercises, and reference docs.
A teaching card is a compact teaching unit. It explains one specific point clearly enough that it can be reused inside a lesson, video, slide, exercise, or reference doc.
A teaching card is not a form. Do not expose headings like "Learner Problem", "Explanation", "Common Mistake", or "Takeaway" unless the user explicitly asks for that structure.
One card teaches one specific point.
If the idea contains multiple points, split it into multiple cards.
The goal of a teaching card is not to summarize information. The goal is to make one idea click.
AI tends to explain by adding more: more definitions, more caveats, more background, more technical detail. That usually makes the explanation worse.
A good teaching card does the harder thing: it removes everything except the few pieces the learner needs to understand the point.
Explain the idea plainly, but do not dumb it down. Simple explanations require rigorous thinking.
A card should help the learner understand:
Prefer this order:
Do not start with the abstract definition if the learner's pain is more concrete.
Weak:
A git worktree is a linked working tree attached to the same repository.
Strong:
If you open two terminals in the same repo and run two Claude Code sessions, both agents are editing the same files. Different terminals do not mean different workspaces. A worktree gives each agent its own folder and branch.
Every card should satisfy this checklist, but the checklist should not usually appear as visible structure:
Use this readable shape by default:
## Clear Card Title
Short natural explanation of the point.
Concrete example, prompt, diagram, code sample, demo, or exercise.
Common mistake or contrast, if useful.
**Takeaway:** One sentence.
The card should feel like a concise lesson section or one strong slide with speaker notes, not metadata.
Each card should include or point to one useful teaching asset when possible:
If no asset fits, explain why the card still works without one.
If a card tries to teach more than one point, split it.
Too broad:
GitHub helps agents work safely.
Better split:
Branches Make Agent Changes Reversible
Pull Requests Are The Review Boundary
Issues Keep Agent Tasks Out Of Chat
CI Gives The Agent Deterministic Feedback
When asked for one card, write one polished card.
When asked for a lesson, first propose the card stack:
# Lesson Card Stack: [Lesson Name]
Outcome: ...
1. Card title
2. Card title
3. Card title
...
Then write the cards as readable teaching sections, not metadata blocks.
When asked to review existing material, identify:
Write in Owain's teaching style:
Prefer:
Here is the situation.
Here is what goes wrong.
Here is the concept that explains it.
Here is what to do.
Here is the mistake to avoid.
Avoid:
Great engineers know...
The fundamentals never change...
This is the future...
Unlock your potential...
Do not write like generic documentation.
Avoid:
Before finalizing a card, ask:
Fact:
git worktree creates additional working trees attached to the same repository.
Understanding:
Two Claude Code sessions in the same folder are editing the same files. A worktree gives each one a separate folder and branch.
Aim for understanding.
## Use Worktrees When Claude Needs An Isolated Workspace
If you open two terminals in the same repo and run two Claude Code sessions, both agents are editing the same files.
That is the problem. Different terminals do not mean different workspaces. One agent might be building the answer API while another redesigns the support page, but they are still writing into the same local folder on the same checked-out branch. When you run `git status`, their changes are mixed together.
A git worktree gives each session its own folder and branch:
```text
supportbot/ main checkout
supportbot-answer-api/ answer-api branch
supportbot-support-ui/ support-ui branch
```
Create one manually:
```bash
git worktree add ../supportbot-answer-api -b answer-api
cd ../supportbot-answer-api
claude
```
The common mistake is thinking a new terminal gives you a new workspace. It does not. If the terminal is in the same repo folder, it is sharing the same files.
**Takeaway:** if you want two agents working on two branches at the same time, use two worktrees.