WAIT — Single-maintainer risk — review before adopting

• Last commit 2w 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
• ⚠ Scorecard: default branch unprotected (0/10)

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

A collection of manim scene definitions and helper code that generates the animated explanatory math videos published on 3Blue1Brown. It uses the manim visualization library (custom 3b1b fork) to procedurally render geometric animations, transformations, and mathematical visualizations as video content, with specific scenes organized by video release year (2015 onwards). Flat year-based file organization (/_2015, /_2016, /_2017, etc.) with thematic subdirectories for major video series (eola/ for 'Essence of Linear Algebra', brachistochrone/, hilbert/). Each scene is typically a standalone Python file inheriting from manim's Scene class; shared utilities likely imported from a common manim library. No monorepo infrastructure, no package/module separation—this is a collection of scene scripts organized by publication date.

Math educators and visualization developers who want to create animated mathematics explanations using manim. Specifically: contributors to 3Blue1Brown who generate new video scenes, and developers studying how to structure large manim projects with reusable scene patterns across multiple videos.

Actively developed and production-deployed: code generates videos published on a major educational channel (3Blue1Brown). The repo spans 2015–present with consistent updates, but many older scenes (pre-2016) may not run without legacy manim versions. No public issue tracker or test suite visible in file listing, suggesting internal-team-focused maintenance rather than community-driven open development.

High dependency on a custom manim fork (3b1b/manim) that diverges from the community edition—upgrading or switching to ManimCommunity will likely break scenes. Version constraints are not visible in this snapshot, and dependency lockfiles are absent from the file list. Single-maintainer risk (Grant Sanderson) means onboarding friction and slow response to external PRs; no visible CI/CD automation in the file structure. Older scenes are brittle and require specific manim versions.

Repository state visible from file listing shows completed scenes up through at least 2016 (eola chapters 0–11, brachistochrone, hilbert fractals). Exact current activity cannot be inferred from static file list alone—check the repo's git log, recent commits, and YouTube upload schedule for current work. The presence of CLAUDE.md suggests active refactoring or documentation work.

Clone the repo, install the 3b1b fork of manim, and render a scene: git clone https://github.com/3b1b/videos.git && cd videos && pip install -e /path/to/manim && manimgl _2015/inventing_math.py InvokingMathScene -se 0. (Exact manim installation path and version dependencies are not specified in README snippet provided; see the manim repo for setup.)

Daily commands: Render a single scene to video: manimgl _2016/eola/chapter1.py Chapter1Scene. For interactive/debugging mode at a specific line: manimgl _2016/eola/chapter1.py Chapter1Scene -se 42. For high-quality file output (used for final videos): adjust manim config flags and render resolution in the scene or via command-line args (see manim docs).

• README.md — Essential entry point explaining the project is a Manim-based math animation codebase for 3Blue1Brown videos with CC-BY-NC-SA licensing constraints.
• _2016/eola/chapter1.py — Representative scene file demonstrating the standard Manim scene structure and animation patterns used across the entire codebase.
• _2017/eoc/chapter1.py — Core example of multi-chapter video organization showing how complex mathematical concepts are broken into animated scenes.
• _2015/matrix_as_transform_2d.py — Foundational linear algebra visualization demonstrating the core use-case of transforming 2D objects with animations.
• CLAUDE.md — Project-specific guidelines and conventions that all contributors should follow when adding new scenes.

• Scene (Python class) (Python, Manim API) — Defines mathematical objects, animations, and timing logic; user-written code that drives all animation content
  • Failure mode: Malformed scene (missing construct() method, infinite loops) halts rendering; crashes are unrecoverable within single render pass
• Manim Renderer (Manim, Cairo/OpenGL, FFmpeg) — Converts scene object graph into rasterized frame sequence; handles camera, lighting, object hierarchies, and interpolation
  • Failure mode: Rendering errors (OOM on high-resolution output, unsupported object types) produce partial/corrupt video; restart required
• Data loaders (Python, file I/O, NumPy) — Load precomputed datasets (MNIST, domino chain data) into Python data structures for scene consumption
  • Failure mode: Missing or corrupted data files cause scene initialization failure; graceful fallback not implemented
• Video output (FFmpeg, H.264 codec) — Final MP4 file generated by FFmpeg encoder; consumed by YouTube/3Blue1Brown platform
  • Failure mode: Encoding failure produces unwatchable video; no automatic retry logic present

• Developer → Python Scene file — Writer defines Scene class with animations and objects
• Scene file → Manim Renderer — Scene instantiation triggers construct() which registers animations and objects
• Data files (_2017/dominos/data/*.txt, MNIST loader) → Scene instantiation — Precomputed data loaded and passed to animation objects (e.g., domino positions, digit images)
• Manim Renderer → FFmpeg — Rasterized frame sequence (PNG or raw pixel data) piped to FFmpeg for video encoding
• FFmpeg → Output MP4 — Encoded video file written to disk, ready for upload or playback

Add a new video scene animation

1. Create a new Python file in the appropriate year folder (e.g., _2024/topic_name.py) (_2024/new_topic.py)
2. Define a Scene class inheriting from Manim's Scene, implementing construct() method with animation code (_2024/new_topic.py)
3. Use standard Manim objects (Circle, Square, Text, etc.) and add() / play() methods for animation sequences (_2024/new_topic.py)
4. Reference CLAUDE.md for naming conventions and ensure scene is self-contained or imports from shared modules (CLAUDE.md)

Add a multi-chapter video series

1. Create a new subdirectory under the year folder (e.g., _2024/series_name/) for the series (_2024/series_name/__init__.py)
2. Create chapter files following the naming convention (chapter1.py, chapter2.py, etc.) (_2024/series_name/chapter1.py)
3. Implement Scene classes in each chapter file, reusing common utilities if needed (_2024/series_name/chapter2.py)
4. Optionally add a thumbnails.py or footnote.py file for supplementary content (reference _2016/eola/thumbnails.py) (_2024/series_name/thumbnails.py)

Add computation-heavy data generation

1. Create a dedicated subdirectory with topic-specific data folder (e.g., _2024/physics/data/) (_2024/physics/data/precomputed.txt)
2. Add Python loader/generator module (e.g., physics_loader.py) similar to _2017/nn/mnist_loader.py (_2024/physics/physics_loader.py)
3. Store precomputed results as text/binary files to avoid expensive runtime computation during animation (_2024/physics/data/precomputed.txt)
4. Import and use the loader in scene files to feed animation data (_2024/physics/main.py)

• Manim (3b1b fork) — Purpose-built library for mathematical animations; provides Scene abstractions, object rendering, and interpolation; community edition available but 3b1b version has extended features
• Python — Manim is Python-based; allows procedural scene definition with expressive syntax for mathematical transformations
• FFmpeg — Manim's default backend for encoding frame sequences into final video files with quality control
• Flat file storage (TXT data files) — Precomputed expensive calculations (domino chains, neural network data) cached locally to avoid recomputation on each render

• Single Manim dependency rather than custom animation framework

  • Why: Manim provides 80% of needed functionality (camera control, object hierarchy, interpolation); building from scratch would be prohibitive
  • Consequence: Codebase is tightly coupled to Manim API; older projects may break with Manim version upgrades (acknowledged in README)

• Organize by year and topic rather than by mathematical domain

  • Why: Reflects actual production workflow where videos ship in temporal order, not by subject
  • Consequence: Linear algebra, calculus, and statistics concepts are scattered across folders; harder for topic-focused learners to navigate

• CC-BY-NC-SA license for content while Manim itself is MIT

  • Why: Protects original educational work from commercial reuse while encouraging community adaptation
  • Consequence: Repo cannot be used directly in proprietary products; requires explicit licensing negotiation

• Does not provide a UI/web interface for scene editing or preview
• Does not support real-time interactive animation (all videos are pre-rendered)
• Does not include video hosting, streaming, or distribution logic
• Does not provide automated testing or validation of scene correctness
• Does not handle audio synchronization or voiceover generation

• Tight coupling to Manim API version — _2015/*.py, _2016/eola/*.py: undefined

1. Custom manim fork required: the repo uses 3b1b/manim, not ManimCommunity—swapping to the community edition will fail on 3b1b-specific APIs. 2) No requirements.txt or Pipfile visible: manim version pinning must come from the manim repo itself; old scenes may require outdated manim tags. 3) Interactive workflow assumes manimgl binary and iPython REPL: the checkpoint_paste() debugging flow is a non-standard manim feature not in community edition. 4) Sublime-specific keyboard shortcuts mentioned in README require additional custom plugin setup (sublime_custom_commands/) to replicate; no VSCode equivalent documented. 5) No explicit guidance on which manim commit each video was rendered with, risking bit-rot and version mismatch across years.

• Scene-based procedural animation — The entire repo is structured around manim's Scene abstraction; understanding how Scenes compose animations, manage the rendering state, and interpolate between keyframes is essential to reading and writing any scene in this codebase.
• Matrix transformations and linear algebra visualization — The eola/ series and many other scenes rely heavily on animating matrix operations, eigenvector decomposition, and coordinate system transformations; this is a central pedagogical pattern in the repo.
• Custom GLSL shaders for real-time rendering — 7.8 KB of GLSL code in the repo indicates custom shader pipelines for specific visual effects or performance optimizations in interactive/streaming mode; understanding shader integration is needed for graphics-heavy scenes.
• Calculus of variations and brachistochrone problems — The brachistochrone/ subdirectory represents a complete case study in visualizing optimization problems and parametric curves; these scenes demonstrate advanced mathematical exposition and multi-layer animation composition.
• Checkpoint/state rollback in interactive debugging — The checkpoint_paste() mechanism described in README is a non-standard debugging workflow unique to this repo; it allows iterative refinement of animations with scene state rollback, critical for efficient scene development.
• Fractal generation and Hilbert curves — The hilbert/ series demonstrates recursive geometry and space-filling curve animations; these scenes require careful construction of recursive scene graphs and performance optimization for deep recursion depth.

• 3b1b/manim — The custom manim fork that is a hard dependency for all scenes in this repo; without it, no scene will render.
• ManimCommunity/manim — Community-maintained fork of manim; potential long-term migration target if 3b1b fork diverges too much, but currently incompatible with custom 3b1b-specific features.
• 3b1b/manim_projects — If it exists, likely contains supplementary project files, asset libraries, or build scripts used alongside this videos repo.
• 3b1b/3Blue1Brown — Likely the main 3Blue1Brown organization repo or website source; may contain video metadata, transcripts, or links to which scenes generate which videos.

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 migration guide and compatibility layer for manim version upgrades

The README explicitly states 'Older projects may have code dependent on older versions of manim, and so may not run out of the box here.' This is a significant friction point for contributors and users trying to run videos from different years (_2015, _2016, _2017, etc.). Creating a structured migration document with version-specific compatibility helpers would dramatically improve usability.

• [ ] Create MANIM_MIGRATION.md documenting breaking changes between manim versions used in each year folder
• [ ] Add a compatibility.py module at the repo root with version-detection and compatibility shims for common API changes
• [ ] Add docstrings to each year's init.py indicating which manim version that folder targets
• [ ] Include a requirements-by-year.txt or similar versioning guide so contributors know which manim version to install

Add pytest test suite for scene rendering and validation

With hundreds of scene files across _2015-_2017+ folders, there's no validation that scenes actually render or that refactors don't break existing animations. A lightweight test suite checking scene instantiation and basic rendering would catch regressions early.

• [ ] Create tests/ directory with conftest.py to set up manim rendering environment
• [ ] Add tests/test_scene_import_validation.py that imports and instantiates all Scene classes from _2015/, _2016/, _2017/ folders
• [ ] Add tests/test_manim_compatibility.py that renders a sample scene from each year folder to validate manim version compatibility
• [ ] Add a GitHub Actions workflow (.github/workflows/test-scenes.yml) to run these tests on pull requests

Consolidate and document shared utilities across year folders into a common library

Looking at the folder structure, files like _2016/eola/chapter*.py, _2016/brachistochrone/*.py, and _2017/dominos/ likely contain duplicate utility functions for common patterns (custom shapes, animations, data loaders). Extracting these into a shared library would reduce code duplication and make it easier for new contributors to reuse existing patterns.

• [ ] Create manim_utils/ folder with submodules: custom_mobjects.py, animation_helpers.py, data_loaders.py
• [ ] Audit _2016/eola/ and _2016/brachistochrone/ folders for duplicate helper functions and move shared ones to manim_utils/
• [ ] Update _2017/dominos/data/*.txt loading pattern to use a standardized data loader from manim_utils/data_loaders.py
• [ ] Add docstrings and type hints to exported utility functions, and document them in CONTRIBUTING.md with examples

• Add a missing init.py and shared utilities module: review _2015/, _2016/, and _2017/ to identify repeated helper functions (e.g., custom animation presets, color palettes, matrix formatting) and refactor into a shared utils/ package to reduce duplication and improve maintainability.
• Write inline docstrings and type hints for major scene classes: pick a series like eola/ (chapters 0–11) and systematically add PEP 257 docstrings and Python 3 type hints to Scene subclasses, init methods, and key animation methods to improve onboarding and IDE support.
• Create a scenes_index.json or VIDEOS.md catalog: map each .py file to its corresponding 3Blue1Brown video URL, publication date, and description. This will help new contributors understand the repo's coverage and identify which scene files are actively used vs. archived.

This is an open-source educational/video generation repository with relatively low security risk. The codebase primarily contains animation and scene definitions using the Manim library, with no exposed web services, APIs, or database interactions detected. No hardcoded secrets, credentials, or obvious injection vulnerabilities are apparent from the file structure. However, the analysis is limited by missing dependency information and package lock files. The main concerns are: (1) unverified dependency versions, (2) potential unsafe processing of data files, and (3) lack of formal security documentation. The project appears well-maintained and reputable (3Blue1Brown is a legitimate educational channel), but dependency management practices should be strengthened to ensure long-term security.

• Low · Potential Code Execution via Data Files — _2017/dominos/data/ and _2017/dominos/domino_play.py. The repository contains data files in _2017/dominos/data/ (data01.txt through data19.txt) that may be processed programmatically. If these files are deserialized or evaluated without proper validation in domino_play.py, they could pose a code execution risk. Fix: Validate and sanitize all data file inputs. Use safe deserialization methods (e.g., JSON parsing instead of pickle/eval). Document the expected format and implement schema validation.
• Low · Missing Dependency Lock File — Project root. No package lock file (requirements.txt, Pipfile.lock, poetry.lock, or setup.py) was provided for analysis. This makes it difficult to verify if the project uses secure, vetted versions of dependencies like Manim and its transitive dependencies. Fix: Create and maintain a requirements.txt or equivalent dependency lock file with pinned versions. Regularly audit dependencies using tools like 'pip audit' or 'safety' to detect known vulnerabilities.
• Low · Insufficient Documentation on External Dependencies — README.md and project structure. The README indicates heavy reliance on the Manim library (both the 3b1b fork and community versions), but no security guidance or version constraints are documented. Older projects may use outdated versions with unpatched vulnerabilities. Fix: Document minimum required versions for Manim and other critical dependencies. Include a migration guide for updating legacy code. Consider using automated dependency scanning in CI/CD pipelines.

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

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

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.

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 ≤ 44 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 "_2015/matrix_as_transform_2d.py" \\
  && ok "_2015/matrix_as_transform_2d.py" \\
  || miss "missing critical file: _2015/matrix_as_transform_2d.py"
test -f "CLAUDE.md" \\
  && ok "CLAUDE.md" \\
  || miss "missing critical file: CLAUDE.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 44 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~14d)"
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).

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