# PDF Mlops Explaining > Explains ANY MLOps-engineer-path subject (a tool, concept, stage, or comparison) at calibrated depth — full treatment for core topics, one or two sentences for peripheral ones — and renders it as a downloadable PDF saved to ./output/.pdf so the user builds a personal reference library. ONLY trigger on explicit invocation by name — e.g. "pdf mlops explaining: X", "use pdf mlops explaining", or "/pdf-mlops-explaining X". Do NOT activate for general questions on these topics: if the user hasn't named this skill, do not use it. - Skill: `laabidi-ahmed-ai/pdf-mlops-explaining` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add laabidi-ahmed-ai/pdf-mlops-explaining` - Raw SKILL.md: https://api.skillmd.com/api/skills/laabidi-ahmed-ai/pdf-mlops-explaining/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: laabidi-ahmed-ai (https://skillmd.com/u/laabidi-ahmed-ai) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/laabidi-ahmed-ai/pdf-mlops-explaining --- # PDF MLOps Explaining ## Activation rule (read first) Only run this skill when the user **explicitly invokes it by name**. Valid triggers: - `pdf mlops explaining: ` - `use pdf mlops explaining` - `/pdf-mlops-explaining ` - any equivalent phrasing where the user clearly names "pdf mlops explaining". If the user just asks about an MLOps topic in normal conversation **without** naming this skill, do **not** activate. Never fire automatically on topic match. The `` is whatever the user gave — a tool, concept, pipeline stage, comparison, anything on the MLOps engineer path. If none was given, ask for one in a single line. ## Audience calibration The user is an **MLOps engineering student**: solid on software basics, ML/DL, FastAPI/Django, Python, and end-to-end pipelines (data → notebook → deployment → CI/CD). They are **still learning Docker, Kubernetes, and CI/CD** — so cover those at a conceptual / interview level, clearly, without assuming hands-on fluency, but don't dumb down the ML/DL fundamentals they already know. ## Step 0 — template check If the user has previously created PDFs in a specific style/template, ask them (one short line) to share or describe it so you can match it. Otherwise use the default clean technical-guide layout produced by `generate_pdf.py` (consistent fonts/colors for headers vs body vs code). Only ask once per session; don't block if they don't answer — fall back to the default. ## Step 1 — triage the sub-topics (the important rule) Before writing anything, split the subject's sub-topics into two buckets and **do not explain them at the same depth**: - **Core** to the MLOps engineer domain — data pipelines, ML/DL fundamentals, model serving, FastAPI/Django, Docker, Kubernetes, CI/CD, monitoring, and software-engineering practices for shipping ML systems. These get the **FULL treatment**. - **Peripheral / tangential** — mentioned in passing, background context, adjacent but not something an MLOps engineer must master. These get **one or two sentences max**, plain language, no code, no deep breakdown. State the triage explicitly at the top of the output (it becomes the "Depth triage" box in the PDF), so the user sees why the depths differ. Never pad the PDF with equal-depth coverage of non-central topics. ## Step 2 — write the content For **each core sub-topic**, include: - a **simple explanation** (a few sentences, no jargon overload), - a short **real-world example or analogy**, - a **tiny code/config snippet** where relevant, annotated simply, - **one interview-style question + a concise answer**. For each **peripheral** sub-topic: one or two plain sentences only. ## Step 3 — build the content JSON Assemble everything into a JSON file matching the schema documented at the top of `generate_pdf.py`. Write it to a temp path (e.g. `./output/.json` or a scratch dir). Shape: ```json { "title": "", "subtitle": "A personal MLOps reference guide", "author": "G", "triage": { "core": ["..."], "peripheral": ["..."] }, "sections": [ { "title": "", "blocks": [ {"type": "paragraph", "text": "simple explanation ..."}, {"type": "callout", "text": "Real-world example: ..."}, {"type": "code", "lang": "python", "caption": "...", "text": "..."}, {"type": "interview", "q": "...", "a": "..."} ]}, { "title": "Peripheral topics (brief)", "blocks": [ {"type": "paragraph", "text": ": one or two sentences."} ]} ] } ``` Block types available: `paragraph`, `subheading`, `bullets` (`items: [...]`), `code` (`text`, optional `lang`, optional `caption`), `interview` (`q`, `a`), `callout`. Keep code snippets short and use real newlines inside the `text` string. ## Step 4 — render the PDF Run the bundled script from the skill folder: ```bash python3 generate_pdf.py --output-dir ./output ``` The script (reportlab; `pip install reportlab --break-system-packages` if missing) produces: - a **title page** using the subject as the title, - a **depth-triage box** (core vs peripheral), - a **table of contents** when there is more than one section, - clear **section headers** and **monospace-styled code/config blocks**, - a page footer with the subject and page numbers. It saves to `./output/.pdf` — **one file per subject**, named after the subject, so files accumulate over time rather than overwriting. It prints `OK: created ()`. ## Step 5 — confirm and deliver Confirm the file was created (check the script's `OK:` line and that the file exists with non-zero size). Then deliver the PDF to the user (SendUserFile) and tell them where it was saved. If generation fails, report the error and fix the content JSON or the environment before finishing — don't claim success without a real file. ## Notes - `python3 generate_pdf.py --demo` renders a built-in sample to sanity-check the environment. - The script is self-contained in this skill folder; it only depends on `reportlab`.