agentleFS
aayushostwalaayushostwal/nexus/skills/tutorial/SKILL.md

tutorial

Skill19 starsChanged 3 months agoMITView on GitHub

Use for creating executable Jupyter tutorials and AI engineering walkthroughs with runnable cells. Trigger on requests for step-by-step guides, notebook-based teaching, or shareable code-first learning content. Prioritize reproducibility, clarity, and copy-paste-ready outputs.

  • Installs packages

10 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use update.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • AnthropicSkill

    update

    Sync tasks and refresh memory from your current activity. Use when pulling new assignments from your project tracker into TASKS.md, triaging stale or overdue tasks, filling memory gaps for unknown people or projects, or running a comprehensive scan to catch todos buried in chat and email.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 10 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Create a Pydantic BaseSettings class to validate all environment variables on startup

    line 32
  2. Distinctive:

    Document every production failure mode: missing keys, rate limits, model errors, network timeouts

    line 34
  3. Distinctive:

    Create Markdown cells with headers H1–H3:

    line 37
  4. Very specific:

    Never hardcode credentials.

    line 49
  5. Distinctive:

    Use bold text and tables in Markdown cells for key terms — they render on GitHub's notebook viewer

    line 59
  6. Distinctive:

    Add a final cleanup cell: close connections, delete temp files, spin down local model instances

    line 60
  7. Very specific:

    Never hardcode API keys, tokens, or credentials in any cell — use python-dotenv + Pydantic.

    line 90
  8. Distinctive:

    Never write a code cell longer than ~30 lines — split into named functions.

    line 91
  9. Distinctive:

    Never skip the reproducibility block — a notebook without setup instructions cannot be shared.

    line 92
  10. Distinctive:

    Never omit expected output description before a long-running LLM call — readers don't know if it's working.

    line 93
  11. Distinctive:

    Never use vague prerequisites like "install the usual libraries" — list every package with its version.

    line 94
  12. Distinctive:

    Never leave error cells in a saved notebook — clear all outputs and re-run clean before saving.

    line 95
  13. Distinctive:

    Before writing any code, search for the latest stable version of all libraries used.

    line 126
  14. Very specific:

    Use f-strings for all logging and print statements so readers can trace agent thought processes.

    line 129

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Tutorial Generation Protocol

Produce complete, executable Jupyter Notebooks that work on the first run.


Compatibility

  • Language: Python 3.10+
  • Output: .ipynb file + Makefile
  • Style: PEP 8, GitHub-renderable Markdown, clean saved outputs

Workflow

Step 1 — Reproducibility Block

Begin every notebook with:

  1. Shell commands cell: python -m venv .venv && source .venv/bin/activate
  2. pip install cell with all required libraries (pin versions: langchain==0.2.0)
  3. Kernel check instructions as a Markdown cell
  4. Makefile with make jupyter target and Python version pin (e.g. .python-version file)

Step 2 — Production-Ready Configuration

  1. Create a Pydantic BaseSettings class to validate all environment variables on startup
  2. Load secrets with python-dotenv; raise an explicit ValueError with a helpful message if a key is missing
  3. Document every production failure mode: missing keys, rate limits, model errors, network timeouts

Step 3 — Structural Outline

Create Markdown cells with headers H1–H3:

  • H1 — Title: What the tutorial builds in one sentence
  • H2 — Objective: One paragraph "what you will build and why"
  • H2 — Prerequisites: List exact API keys, GPU requirements, or account setup steps
  • H2 — Architecture Diagram: Mermaid diagram showing end-to-end system flow

Step 4 — Code Implementation

Rules for every code cell:

  • Self-contained or explicitly references previously defined variables
  • Python type hints on all function signatures
  • Comments explain why — not what (bad: # create list, good: # dedup before sending to avoid API double-charge)
  • One concept per cell; max ~30 lines per cell — split into functions if longer
  • Never hardcode credentials; always use settings.api_key from the Pydantic config

Step 5 — Explanatory Narrative

Between every pair of code cells, add a Markdown cell that:

  1. States the "why" behind the implementation choice (e.g., "We use a ReAct loop here because it lets the agent decide when to call tools vs. answer directly")
  2. Describes the expected output when the cell runs
  3. Lists one or two common errors with their fixes (e.g., "RateLimitError → add time.sleep(1) between calls")

Step 6 — GitHub Optimization & Cleanup

  1. Save notebook with clean, representative outputs (no error cells, no partial outputs)
  2. Use bold text and tables in Markdown cells for key terms — they render on GitHub's notebook viewer
  3. Add a final cleanup cell: close connections, delete temp files, spin down local model instances

Output Format

A complete .ipynb file with this cell sequence:

[Setup: venv + pip install]
[Config: dotenv + Pydantic BaseSettings]
[H1: Title + one-sentence summary]
[H2: Objective]
[H2: Prerequisites]
[H2: Architecture Diagram (Mermaid)]
[H2: Step 1 — Name]
  [Markdown: why + expected output + common errors]
  [Code cell]
[H2: Step N — Name] × N steps
[H2: Cleanup]

Plus a Makefile:

jupyter:
	source .venv/bin/activate && jupyter lab

Anti-Patterns

  • Never hardcode API keys, tokens, or credentials in any cell — use python-dotenv + Pydantic.
  • Never write a code cell longer than ~30 lines — split into named functions.
  • Never skip the reproducibility block — a notebook without setup instructions cannot be shared.
  • Never omit expected output description before a long-running LLM call — readers don't know if it's working.
  • Never use vague prerequisites like "install the usual libraries" — list every package with its version.
  • Never leave error cells in a saved notebook — clear all outputs and re-run clean before saving.

Examples

Input: "Write a tutorial on building a ReAct agent with LangChain and OpenAI."

Output structure:

[pip install langchain==0.2.0 openai==1.30.0 python-dotenv pydantic-settings]
[Pydantic: class Settings(BaseSettings): openai_api_key: str]
[H1: Build a ReAct Agent with LangChain]
[H2: Objective — build a tool-using agent that reasons before acting]
[H2: Prerequisites — OpenAI API key, Python 3.10+]
[H2: Architecture — Mermaid: User → Agent Loop → Tool Call / Direct Answer → User]
[H2: Step 1 — Define Tools]
  [Why: tools give the agent the ability to act in the world beyond text]
  [Code: @tool def search(query: str) -> str: ...]
[H2: Step 2 — Initialize Agent]
  [Why: ReAct = Reason + Act, enables multi-step problem solving]
  [Code: agent = create_react_agent(llm, tools, prompt)]
[H2: Step 3 — Run and Inspect Traces]
  [Why: tracing the chain of thought reveals whether the agent is reasoning correctly]
  [Code: result = agent.invoke({"input": "What is the capital of France?"})]
[H2: Cleanup — close any open clients]

Tutorial Specialization

  • Before writing any code, search for the latest stable version of all libraries used.
  • For AI agent tutorials: always include a Mermaid sequence diagram showing the agent decision loop.
  • For API tutorials: include an auth flow cell and a rate-limit retry example with exponential backoff.
  • Use f-strings for all logging and print statements so readers can trace agent thought processes.
  • For long-running cells: add a %%time magic and note typical expected duration.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.