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
- egregore-labs/egregoretheir own version, first seen Nov 6, 2026
- Ivan-n-Beliaev/claude-skillstheir own version, first seen Oct 17, 2026
- apify/apify-docstheir own version, first seen Oct 8, 2026
- me2resh/apexyardtheir own version, first seen Oct 8, 2026
- Q00/ouroborostheir own version, first seen Jul 31, 2026
- LilithLabs/liliththeir own version, first seen Jun 20, 2026
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.
AnthropicSkillupdate
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
Other versions10 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 10
- Q00/ouroboros★ 6.3ksame name
- agenticnotetaking/arscontexta★ 3.5ksame name
- bitwize-music-studio/claude-ai-music-skills★ 589same name
- me2resh/apexyard★ 542same name
- egregore-labs/egregore★ 293same name
- apify/apify-docs★ 88same name
- renatoworks/strudel-claude★ 61same name
- NoaiRox/specialist-agent★ 2same name
- LilithLabs/lilith★ 1same name
- Ivan-n-Beliaev/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- debuggingSkill
- nexusSkill
- observabilitySkill
- performanceSkill
- reliabilitySkill
- shortsSkill
- skill-writerSkill
- software-engineerSkill
- testingSkill
- token-optimizerSkill
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
- Very specific: line 32
Create a Pydantic BaseSettings class to validate all environment variables on startup
- Distinctive: line 34
Document every production failure mode: missing keys, rate limits, model errors, network timeouts
- Distinctive: line 37
Create Markdown cells with headers H1–H3:
- Very specific: line 49
Never hardcode credentials.
- Distinctive: line 59
Use bold text and tables in Markdown cells for key terms — they render on GitHub's notebook viewer
- Distinctive: line 60
Add a final cleanup cell: close connections, delete temp files, spin down local model instances
- Very specific: line 90
Never hardcode API keys, tokens, or credentials in any cell — use python-dotenv + Pydantic.
- Distinctive: line 91
Never write a code cell longer than ~30 lines — split into named functions.
- Distinctive: line 92
Never skip the reproducibility block — a notebook without setup instructions cannot be shared.
- Distinctive: line 93
Never omit expected output description before a long-running LLM call — readers don't know if it's working.
- Distinctive: line 94
Never use vague prerequisites like "install the usual libraries" — list every package with its version.
- Distinctive: line 95
Never leave error cells in a saved notebook — clear all outputs and re-run clean before saving.
- Distinctive: line 126
Before writing any code, search for the latest stable version of all libraries used.
- Very specific: line 129
Use f-strings for all logging and print statements so readers can trace agent thought processes.
“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.
Files
Tutorial Generation Protocol
Produce complete, executable Jupyter Notebooks that work on the first run.
Compatibility
- Language: Python 3.10+
- Output:
.ipynbfile +Makefile - Style: PEP 8, GitHub-renderable Markdown, clean saved outputs
Workflow
Step 1 — Reproducibility Block
Begin every notebook with:
- Shell commands cell:
python -m venv .venv && source .venv/bin/activate pip installcell with all required libraries (pin versions:langchain==0.2.0)- Kernel check instructions as a Markdown cell
Makefilewithmake jupytertarget and Python version pin (e.g..python-versionfile)
Step 2 — Production-Ready Configuration
- Create a Pydantic
BaseSettingsclass to validate all environment variables on startup - Load secrets with
python-dotenv; raise an explicitValueErrorwith a helpful message if a key is missing - 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_keyfrom the Pydantic config
Step 5 — Explanatory Narrative
Between every pair of code cells, add a Markdown cell that:
- 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")
- Describes the expected output when the cell runs
- Lists one or two common errors with their fixes (e.g., "RateLimitError → add
time.sleep(1)between calls")
Step 6 — GitHub Optimization & Cleanup
- Save notebook with clean, representative outputs (no error cells, no partial outputs)
- Use bold text and tables in Markdown cells for key terms — they render on GitHub's notebook viewer
- 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 labAnti-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-stringsfor all logging and print statements so readers can trace agent thought processes. - For long-running cells: add a
%%timemagic and note typical expected duration.
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
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.

