laabidi-ahmed-ai Anki Cards
Activation rule (read first)
Only run this skill when the user explicitly invokes it by name. Valid triggers:
anki cards: <topic or source>use anki cards/anki-cards <topic>- any equivalent phrasing where the user clearly names "anki cards".
If the user just asks a question in normal conversation without naming this skill, do not activate. Never fire automatically on topic match.
Audience calibration
The user is an MLOps engineering student: solid on software basics, ML/DL, FastAPI/Django, Python, and end-to-end pipelines, but still learning Docker, Kubernetes, and CI/CD. Pitch cards at mid-course understanding and interview readiness — test the reasoning and the "why", not just definitions. When cards cover Docker/K8s/CI-CD, keep them conceptual/interview level.
What the source can be
- A topic the user names (e.g. "gradient clipping", "Docker basics for ML serving").
- An existing PDF or document the user points to (e.g. one of their revision guides) — read it, then make cards from its content.
- The user may specify how many cards; default to 15–25 focused cards.
How to write good flashcards (this is the important part)
Anki works through active recall, so card quality is everything:
- One fact per card. Split anything compound. A card that asks two things trains neither.
- Ask a question, don't state a topic. Front = a specific question or prompt; back = the concise answer. Avoid "Docker layers" as a front; use "Why does editing app.py sometimes bust the whole Docker build cache?"
- Keep the back tight — one or two sentences, the answer you'd want to produce in an interview. Not a paragraph.
- Prefer "why / how / what happens when" over "what is". Understanding-level cards beat definition-recall cards for your goals.
- Make it unambiguous. The front should have one clearly correct answer, so you can honestly grade yourself.
- Add a few applied/interview cards ("You get a shape-mismatch at the first Linear layer — what's the usual cause?") alongside the conceptual ones.
- Tag each card with 1–3 short tags (e.g.
docker,serving) so decks stay filterable.
Steps when triggered
- Gather the content: use the topic, or read the source PDF/document the user pointed to.
- Write 15–25 cards following the rules above (or the count the user asked for).
- Assemble them into a JSON file matching the schema at the top of
generate_deck.py:
{
"deck": "<topic — becomes the deck name and file name>",
"cards": [
{"front": "…question…", "back": "…concise answer…", "tags": ["…"]}
]
}
Write it to a temp path (e.g. ./output/<slug>.json).
- Run the bundled script from the skill folder:
python3 generate_deck.py <cards.json> --output-dir ./output
It writes ./output/<deck-slug>.txt — a tab-separated file with Anki header lines (#separator:tab, #html:true, #tags column:3, #deck:) so import needs no manual field mapping. It prints OK: created <path> (<n> cards). (Pure standard library — nothing to install.)
- Confirm the file was created and how many cards it has, then deliver it (SendUserFile) and tell the user how to import it (below). If generation fails, fix the JSON and re-run before finishing.
How the user imports it (include this in your reply)
In Anki: File → Import, pick the .txt. The header lines make Anki auto-detect the tab separator, treat fields as HTML, and read the tags column — so they just click Import. Cards land in a deck named after the topic. (--demo on the script renders a sample deck to sanity-check the setup.)
Style
Cards should be crisp, unambiguous, and understanding-focused. Quality over quantity — 18 sharp cards beat 40 vague ones.