The OpenAI Cookbook grows through community contributions. If you’ve solved an interesting problem with the OpenAI API — optimized a retrieval pipeline, wired up a new tool, found a reliable prompting pattern — a cookbook notebook is the right way to share it. This guide walks through the full process from fork to merged PR.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/openai/openai-cookbook/llms.txt
Use this file to discover all available pages before exploring further.
Contributions are reviewed on a best-effort basis. There are no guaranteed timelines for review or merge. Check open issues and existing examples before starting to avoid duplicating work already in progress.
Contribution workflow
Fork and clone the repository
Start by forking the repository on GitHub, then clone your fork locally.Create a feature branch with a descriptive name that matches your notebook’s topic.
Set up your environment
Create a virtual environment and install Jupyter so you can develop interactively.Each example manages its own dependencies. Create a
requirements.txt inside your topic folder listing only what your notebook needs — do not modify the root requirements.txt.Create your notebook or article
Place new notebooks under Follow the naming convention: lowercase, dash-separated phrases that describe the content clearly.Keep markdown cells focused. Use numbered steps for multi-part workflows and explain why you’re making each API choice, not just what the code does.
examples/<topic>/ and longer narrative guides under articles/. Group related assets (images, helper scripts, data loaders) inside the same topic subfolder.Validate your notebook
Run the notebook top-to-bottom in a clean kernel to confirm it executes without errors. Then clear all output cells before committing so diffs stay readable.This script checks notebook structure and catches common formatting issues before CI runs them.
Add an entry to registry.yaml
Every piece of content must be registered in Run a YAML linter to catch syntax errors before pushing:
registry.yaml for it to appear on cookbook.openai.com. Add your entry at the top of the file (entries are ordered newest-first).Add or verify your author entry
If this is your first contribution, add yourself to Coordinate with existing contributors if you share a name to avoid duplicate slugs.
authors.yaml. Use a unique slug — typically your GitHub username.Open a pull request
Push your branch and open a PR against the In your PR description, include:
main branch of the upstream repository.- A short summary of what the notebook demonstrates
- The motivation — what problem it solves or pattern it illustrates
- Confirmation that you ran the notebook end-to-end and cleared outputs
- Screenshots or output snippets if the result is visual
- Checked boxes for the registry and authors checklist from the PR template
PR checklist
Before requesting review, confirm all of the following:- Notebook runs top-to-bottom in a clean environment with no errors
- Output cells are cleared before committing
- No API keys, credentials, or personal data are present in the notebook
- File and directory names are lowercase and dash-separated
- A
requirements.txtlists the notebook’s dependencies - An entry exists in
registry.yamlwith correctpath,slug,date, andtags - Author slug in
registry.yamlmatches an entry inauthors.yaml - Commit message is concise and imperative (e.g., “Add agent portfolio collaboration demo”)
- CI notebook validation passes locally (
python .github/scripts/check_notebooks.py)
Naming conventions
| Item | Convention | Example |
|---|---|---|
| Notebook file | Lowercase, dash or underscore separated | rag_with_reranking.ipynb |
| Directory | Lowercase, dash separated | examples/rag-with-reranking/ |
| Registry slug | Lowercase, dash separated | rag-with-reranking |
| Author slug | GitHub username or unique identifier | jdoe-oai |
What makes a good cookbook example
The strongest contributions share a few traits:- Runnable end-to-end. A reader should be able to clone the repo, install dependencies, and get output from the first to last cell without modification.
- Focused scope. Cover one technique or pattern well rather than surveying many superficially.
- Explained choices. Use markdown cells to explain why you structured the API calls the way you did — not just what they do.
- Real use case. Ground the example in a concrete task (summarization, entity extraction, semantic search) rather than a purely synthetic one.