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: <subject>
• use pdf mlops explaining
• /pdf-mlops-explaining <subject>
• 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 <subject> 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/<slug>.json or a scratch dir). Shape:

{
  "title": "<the exact subject the user gave — becomes the PDF title>",
  "subtitle": "A personal MLOps reference guide",
  "author": "G",
  "triage": { "core": ["..."], "peripheral": ["..."] },
  "sections": [
    { "title": "<core sub-topic>", "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": "<topic>: 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:

python3 generate_pdf.py <content.json> --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/<subject-slug>.pdf — one file per subject, named after the subject, so files accumulate over time rather than overwriting. It prints OK: created <path> (<bytes>).

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.