If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/3b1b/videos shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 1w ago
• 3 active contributors
• Other licensed
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 88% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live 3b1b/videos repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/3b1b/videos.

What it runs against: a local clone of 3b1b/videos — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in 3b1b/videos | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 37 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of 3b1b/videos. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/3b1b/videos.git
#   cd videos
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of 3b1b/videos and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "3b1b/videos(\\.git)?\\b" \\
  && ok "origin remote is 3b1b/videos" \\
  || miss "origin remote is not 3b1b/videos (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "_2016/eola/chapter1.py" \\
  && ok "_2016/eola/chapter1.py" \\
  || miss "missing critical file: _2016/eola/chapter1.py"
test -f "_2017/eoc/chapter1.py" \\
  && ok "_2017/eoc/chapter1.py" \\
  || miss "missing critical file: _2017/eoc/chapter1.py"
test -f "CLAUDE.md" \\
  && ok "CLAUDE.md" \\
  || miss "missing critical file: CLAUDE.md"
test -f "_2015/matrix_as_transform_2d.py" \\
  && ok "_2015/matrix_as_transform_2d.py" \\
  || miss "missing critical file: _2015/matrix_as_transform_2d.py"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 37 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~7d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/3b1b/videos"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A collection of Manim scene definitions that generate the mathematical animations used in 3Blue1Brown's educational videos. It uses the Manim library (a Python-based animation engine for explanatory math videos) to programmatically create visualizations of complex mathematical concepts like linear algebra (eola/), fractals (hilbert/), and calculus (brachistochrone/). The repo is essentially a structured archive of video production code organized by year and topic. Organized as a chronological monorepo: top-level directories (_2015/, _2016/, _2017/, etc.) group scenes by production year. Within each year, subdirectories group related videos (eola/ for "Essence of Linear Algebra", brachistochrone/ for calculus series). Each scene file is typically a standalone Python module defining one or more Scene classes that inherit from Manim's Scene, with helper utilities in sibling files (e.g., curves.py, drawing_images.py).

Math educators and animators who want to understand how 3Blue1Brown's videos are produced, and developers contributing patches or adapting Manim animations for their own explanatory content. Also useful for students reverse-engineering visual proofs and understanding the implementation of mathematical visualizations.

Actively maintained but historical in nature: the repo spans from 2015 onwards with a large codebase (16MB of Python), indicating years of active production use. However, it's an archive of past video code rather than a forward-developed library—older projects (pre-2018) may not run with current Manim versions due to API changes. The presence of CLAUDE.md suggests recent documentation efforts, but no visible CI/testing infrastructure indicates this is primarily a working archive rather than a tested library.

High dependency on specific Manim versions: the README explicitly warns that 'Older projects may not run out of the box here' due to Manim API evolution, with separate mentions of 3b1b/manim vs. ManimCommunity versions having diverged functionality. Single-maintainer risk (Grant Sanderson/3b1b) is inherent. No visible test suite, CI pipeline, or dependency lock files suggest stability is ensured through manual testing rather than automated validation.

Unable to determine from the provided data—no git history, PR list, or issue tracker snapshot is included. The presence of CLAUDE.md and the README's detailed workflow section (mentioning Sublime integration and checkpoint_paste()) suggest recent documentation updates for contributor onboarding, but no specific active work items are visible.

git clone https://github.com/3b1b/videos.git
cd videos
pip install manim  # or pip install manim-community
python -m manim _2016/eola/chapter1.py SceneName -p

Replace chapter1.py and SceneName with the actual file and scene class. Refer to CLAUDE.md for detailed setup.

Daily commands:

manimgl _2016/eola/chapter1.py IntroToVectors  # Interactive mode with real-time preview
manimgl _2016/eola/chapter1.py IntroToVectors -se 120  # Drop into debugger at line 120
# From the iPython terminal within -se mode:
checkpoint_paste()  # Run clipboard code, with checkpoint saving

See the Workflow section in README for Sublime plugin integration. Without it, manually invoke manimgl with scene file and class name.

• README.md — Explains the entire project purpose, Manim dependency, licensing terms, and workflow—essential for understanding scope and constraints
• _2016/eola/chapter1.py — Exemplar scene structure from the 'Essence of Linear Algebra' series; shows canonical Manim Scene class usage and animation patterns used throughout
• _2017/eoc/chapter1.py — Exemplar scene from 'Essence of Calculus' series; demonstrates how multi-chapter video projects are organized and structured
• CLAUDE.md — Project-specific guidance for AI assistants; likely contains conventions, setup instructions, and codebase quirks
• _2015/matrix_as_transform_2d.py — Early foundational scene demonstrating mathematical visualization patterns and Manim Scene conventions used as reference across codebase

• Scene classes (e.g., ChapterN, MyScene) (Python, Manim Scene API) — Define mathematical objects, animations, and sequencing via construct() method
  • Failure mode: Syntax errors, unregistered animations, or render timeouts halt video generation; no partial recovery
• Utility modules (e.g., light.py, misc.py) (NumPy, SciPy, custom math) — Encapsulate reusable mathematical algorithms, curve solvers, physics simulations, and custom animation builders
  • Failure mode: Bugs in utilities propagate to all dependent scenes; no automated tests indicated
• Data files (e.g., dominos/data/) (Plain text, binary formats) — Store external datasets (e.g., domino configurations, MNIST images) loaded by scene classes at render time
  • Failure mode: Missing or corrupted data files cause scene loader to fail; no validation before rendering
• Manim Renderer (external dependency) (Manim library, Cairo/Pango (rendering), FFmpeg (encoding)) — Converts scene animation timelines to rasterized frames and encodes to video
  • Failure mode: Manim version incompatibility or GPU memory exhaustion; developer must downgrade manim or split scenes

• Scene file (.py) → Manim CLI — Developer specifies scene class name; CLI imports and instantiates it
• Scene.construct() → Manim Renderer — Scene definition (objects, animations, timing) fed to renderer's animation timeline
• External data files → Scene classes — Utility modules load CSVs, text, or binary data (e.g., MNIST) during scene setup
• Manim Renderer → `` — undefined

Add a new chapter scene to a video series

1. Create a new file in the series folder following naming convention (e.g., chapterN.py for Essence series) (_2016/eola/chapter1.py)
2. Import Scene and animation classes from manim; subclass Scene with your chapter scenes (_2016/eola/chapter1.py)
3. Define construct() method with animations, text, and graphical objects in sequence (_2016/eola/chapter1.py)
4. Use self.play() and self.wait() to orchestrate timeline; run manim CLI to render (_2016/eola/chapter1.py)

Add a reusable visualization utility module

1. Create helper module in an appropriate series or utility folder with mathematical/animation logic (_2016/brachistochrone/light.py)
2. Define custom functions or classes (e.g., curve solvers, transformation helpers) that encapsulate animation logic (_2016/brachistochrone/misc.py)
3. Import and reuse in scene files via: from brachistochrone.light import MyHelper (_2016/brachistochrone/cycloid.py)

Create a new standalone video project

1. Create a new year folder (_YYYY) or topic subfolder if grouping related videos (_2017/crypto.py)
2. Write scene classes using Manim Scene base, defining construct() with animations and visuals (_2017/crypto.py)
3. If project has data dependencies, organize in a data/ subfolder (e.g., dominos/data/) (_2017/dominos/data/data01.txt)
4. Reference any data files via relative imports or file path resolution in scene setup (_2017/dominos/domino_play.py)

• Manim (3b1b fork) — Declarative Python animation framework for mathematical visualization; renders to high-quality video with SVG-based interpolation and precise control over timing
• Python — Primary language for scene definition; allows mathematical expressions and algorithmic generation of animations
• FFmpeg — Underlying video encoding backend; composites rendered frames into MP4/MOV with custom codecs and quality settings
• Git (GitHub) — Version control for scene code across 500+ files organized by year and topic; enables collaboration and reproducibility

• Year-based folder structure (_2015, _2016, …) rather than topic-based

  • Why: Mirrors video publication timeline; easy to locate scenes by release date
  • Consequence: Related topics scattered across multiple year folders; requires cross-year imports for shared utilities

• Dependency on 3b1b/manim (custom fork) rather than ManimCommunity version

  • Why: Specialized features and optimizations for 3Blue1Brown's style; tighter integration with rendering pipeline
  • Consequence: Code may not run on community edition; higher maintenance burden; steeper onboarding for external contributors

• No build system or package distribution (raw Python files)

  • Why: Simplicity for video production; direct file edits and manim CLI invocation
  • Consequence: No package versioning; difficult to pin dependencies across scenes; older videos may break with manim updates

• CC-BY-NC-SA licensing on content (not MIT like Manim)

  • Why: Protects educational content while allowing attribution and derivatives in non-commercial contexts
  • Consequence: Limits commercial use and requires explicit attribution; more restrictive than Manim library itself

• Real-time interactive visualization (all outputs are pre-rendered video files)
• Cross-platform rendering distribution (assumes local manim installation on developer machine)
• Dynamic data ingestion or live streaming integration
• Performance optimization for embedded playback (targets YouTube publication, not embedded web components)

1. Manim version mismatch: code written for 3b1b/manim may not work with ManimCommunity or different minor versions; no version pinning visible. 2) The interactive -se debugger and checkpoint_paste() workflow are undocumented outside README and CLAUDE.md—unfamiliar to standard Manim users. 3) Render performance: older scenes may assume GPU capabilities or specific FFmpeg codecs not available in all environments. 4) No environment variables documented, but Manim typically requires ManimGLRender or ManimCairoRender config; check Manim docs for your installation.

• Scene-based animation abstraction — Manim's core pattern: animations are added to a Scene object, which manages the render timeline; understanding this is essential to reading every file in this repo
• Parametric curves and splines — Used extensively in brachistochrone/ and hilbert/ for rendering mathematical curves; critical for the calculus and fractal visualization content
• Linear transformations as matrix multiplication — The conceptual backbone of the eola/ (Essence of Linear Algebra) series; understanding how Manim visualizes matrix operations is essential for reading chapter1-11
• Space-filling curves (Hilbert, Sierpinski) — Featured in hilbert/ directory with fractal animations; demonstrates recursive scene composition and algorithmic geometry visualization
• Brachistochrone problem (fastest descent curve) — The entire brachistochrone/ directory is built around this calculus concept; shows how to animate physics simulations and parametric problem-solving
• GLSL shader programming — 7.8KB of custom GLSL code in the repo for GPU-accelerated rendering optimizations; necessary for understanding performance tuning in modern scenes
• Euler's formula and complex plane visualization — Featured in _2015/eulers_characteristic_formula.py and complex_multiplication_article.py; understanding the complex plane animation is foundational for many videos

• 3b1b/manim — The core animation engine this entire repo depends on; the 3b1b fork with custom features and performance optimizations used in all these scenes
• ManimCommunity/manim — Community-maintained Manim fork; scenes in this repo may need porting to work with this version, and understanding the API divergence is essential for long-term maintenance
• 3b1b/3Blue1Brown — The official 3Blue1Brown YouTube channel repo (if exists) containing rendered videos and metadata corresponding to these scene definitions
• tqdm/tqdm — Likely dependency for progress bars in scene rendering; useful for understanding Manim's rendering pipeline integrations

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create a CLAUDE.md maintenance guide and deprecation index for year-specific chapters

The repo spans 2015-2017+ with multiple large chapter directories (_2016/eola/ has 13 files, _2016/brachistochrone/ has 8 files). CLAUDE.md exists but is empty. New contributors need guidance on which scenes are broken with current Manim versions, which chapters are complete, and how to update older code. This would reduce onboarding friction and prevent contributors from investing time in unmaintainable code.

• [ ] Document in CLAUDE.md the Manim version compatibility for each year folder (_2015, _2016, _2017, etc.)
• [ ] Create a deprecation status table listing known broken scenes and their errors (e.g., API changes in Manim)
• [ ] Add guidance on how to update old-style Manim code to current standards with before/after examples from actual files like _2016/eola/chapter0.py
• [ ] Include a 'Good First Issues' section pointing to isolated, self-contained scenes suitable for new contributors

Add unit tests for manim scene compilation in _2015/ and _2016/ core chapters

The repo has no visible test infrastructure. Large chapter directories like _2016/eola/ (11 chapter files) and _2016/brachistochrone/ are critical but have no validation that scenes still render. A basic test suite that attempts to import and partially instantiate scenes would catch breaking changes early when Manim updates occur.

• [ ] Create tests/test_scene_imports.py that imports all Scene classes from _2015/ core files (complex_multiplication_article.py, counting_in_binary.py, eulers_characteristic_formula.py, matrix_as_transform_2d.py, pythagorean_proof.py, three_dimensions.py)
• [ ] Create tests/test_eola_imports.py that imports Scene classes from all _2016/eola/chapter*.py files and validates they inherit from Scene
• [ ] Add a GitHub Actions workflow (.github/workflows/test-imports.yml) that runs these tests on push to catch Manim API incompatibilities
• [ ] Document in README.md how to run tests locally: 'pytest tests/test_scene_imports.py'

Consolidate duplicate utility code from _2016/brachistochrone/ into a shared manim_utils module

The _2016/brachistochrone/ directory has 8 files (curves.py, cycloid.py, drawing_images.py, light.py, misc.py, multilayered.py, wordplay.py, graveyard.py) that likely contain duplicate scene utilities, custom Mobjects, and animation helpers. Extracting a shared utils module would reduce code duplication, make the codebase more maintainable, and provide reusable components for other years' projects.

• [ ] Audit _2016/brachistochrone/{curves.py, cycloid.py, misc.py, light.py} for common function definitions and custom Mobject classes
• [ ] Create _2016/brachistochrone/utils.py and move shared functions (e.g., parametric curve helpers, light-related utilities) there with clear docstrings
• [ ] Update imports in curves.py, cycloid.py, multilayered.py, wordplay.py to use the new utils module
• [ ] Add a note to CLAUDE.md about the brachistochrone utils pattern as a template for refactoring other year folders

• Add a test suite for _2015/ scenes: verify that example scenes from the oldest chapters still parse correctly under current Manim API, documenting breaking changes
• Create a SCENES.md inventory: list all 80+ scene classes across all year directories with one-line descriptions and linked video timestamps, enabling easier navigation and reuse
• Modernize one complete chapter (e.g., _2016/eola/chapter2.py) to work with ManimCommunity and document the migration steps in a MIGRATION.md guide

The codebase appears to be a legitimate educational video generation repository for 3Blue1Brown using the Manim library. No critical vulnerabilities were identified based on the available file structure. Primary concerns are: (1) inability to assess dependencies due to missing manifest files, (2) inherent code execution risks from Manim library usage (expected but should be mitigated), and (3) lack of security documentation. The low security score reflects missing dependency verification and the absence of security best practices, rather than identified exploitable vulnerabilities. The repository follows a reasonable CC-BY-NC-SA licensing model appropriate for its purpose.

• Medium · Missing Dependency Manifest — Repository root / dependency management. No package dependency file (requirements.txt, setup.py, pyproject.toml, Pipfile, etc.) was provided for analysis. This makes it impossible to identify vulnerable dependencies, outdated packages, or security issues in third-party libraries. The codebase depends on Manim and likely other packages, but their versions and security status cannot be verified. Fix: Provide and maintain a requirements.txt or setup.py file with pinned dependency versions. Regularly run security scanning tools like pip-audit, safety, or pipenv check to identify vulnerable dependencies.
• Low · Potential Code Execution from Manim Library — All .py files (throughout the codebase). The codebase heavily relies on Manim, a mathematical animation library that may execute arbitrary Python code during scene rendering. While this is expected behavior for a video generation tool, there's inherent risk if untrusted input is passed to Manim functions or if dynamically generated code is evaluated. Fix: Validate and sanitize any external input before passing it to Manim rendering functions. Avoid using eval() or exec() with user-supplied input. Run Manim in isolated environments (containers/sandboxes) if processing untrusted scenes.
• Low · Data Files Without Integrity Verification — _2017/dominos/data/*.txt files. The repository contains data files in _2017/dominos/data/ (data01.txt through data19.txt) without apparent integrity checks or signatures. If these files are modified or corrupted, there's no built-in verification mechanism. Fix: Implement checksum verification (MD5, SHA256) for critical data files. Consider using signed commits or content hashing to ensure file integrity over time.
• Low · No Security Policy or Contribution Guidelines — Repository root. The repository lacks a visible security policy (SECURITY.md), responsible disclosure guidelines, or security considerations in the README. While this is a video content repository with lower risk, it's a best practice for any public repository. Fix: Create a SECURITY.md file documenting security policies, vulnerability reporting procedures, and any known security considerations for contributors.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.