LeetCodeAnimation keeps the animations on algomooc.com and the index on GitHub

GitHub holds the index, the website holds the player

The most important thing to understand about this repository is that it is not the product. Its own maintainer section states the division: GitHub stores historical content, the public index and the sync scripts, while the website side maintains the current animation pages. Interactive playback, step switching and the reading experience are all defined to follow the website version. The README says the same thing at the top, describing the GitHub copy as a public index and historical material, with the complete step-by-step, rewind, speed and voice narration available in the website edition.

The four preview GIFs at the top of the README are the honest illustration of the arrangement. They are frames lifted from the website player, and each one is a link through to the corresponding problem page. Two Sum is shown as a scan that maintains a hash table so you can see how the complement gets found. Trapping Rain Water uses a bar chart to break down the left and right boundaries. Number of Islands expands a DFS colouring the grid cell by cell. Linked List Cycle shows the fast and slow pointers moving together until they meet.

What this means for a reader is concrete. Cloning the repository gives you an index, some early material, and scripts. It does not give you a player, a step control, a speed control or narration, and it does not give you the current versions of these four animations, only frames of them.

256 and 299 count different sets, and the README refuses to merge them

The index table reports 256 LeetCode animations in the repository, broken down as 71 easy, 160 medium and 25 hard. A separate figure of 299 appears in the progress notes. The README spends a paragraph explaining that these are not the same measurement, and the distinction is worth internalising before you use either number.

The 256 is the count of animations synced into this repository, computed by a script from the website's study_index.js and written into docs/data/manifest.json. The 299 is the total animation content on algomooc.com, which includes advanced problems and topic collections, and it comes from a different single source of truth on the site, backfilled into the siteTotal field of docs/data/stats.json. The scope of the second is wider, so it is always the larger number.

A reader who quotes 299 as the repository's coverage will be wrong, and a reader who quotes 256 as the site's coverage will be wrong in the other direction. The distributions are worth reading too: with 25 hard problems out of 256, this is a collection weighted towards the middle of the difficulty range, which is where interview preparation actually spends its time, and not a sweep of the hardest end.

The README's numbers are injected, so editing the table by hand breaks the build

The index block sits between HTML comment markers labelled LCA-AUTOGEN:STATS, and the text above it says the figures are computed by tools/scripts/build-readme.js from docs/data/manifest.json and must not be edited by hand. The same instruction appears inside the block, and the progress notes repeat it for both 256 and 299: the numbers are taken over by scripts and hand-writing them is prohibited.

This is a small design decision with a large effect on how the repository can be trusted. Because docs/data/manifest.json is named as the single source of truth for the counts, and the README table, the question-number index, the topic index and the badges are all derived from it, none of them can drift. A contributor cannot accidentally claim 300 problems by editing a markdown table, and a reader who wants to know what is actually indexed reads the manifest rather than the prose.

The cost is that the repository is not a place to write documentation. Any explanatory text that contains a number is a number that will go stale the next time the sync runs, which is why the narrative content lives in docs/notes/ and the counts live in the injected block. Contributors who want to add a sentence about coverage should add it to the source of truth instead.

The sync pipeline is three commands, and the first one is a review step

The maintainer section documents the whole loop, and it begins with inspection rather than action. The website's problem index comes from study_index.js, and before anything is copied into the repository the maintainer is told to review what changed on the site:

npm run review:site

Only after confirming what should come across does the sync run, followed by validation and the regeneration of the README figures:

npm run sync        # 更新 manifest / 题号索引 / 专题索引 / 同步记录
npm run validate    # 校验 manifest
node tools/scripts/build-readme.js --write   # 把 README 数字段 + stats.json 重新注入

package.json marks the package private and defines those npm scripts plus three checking variants, sync:check, sync:check-generated and validate, so the pipeline can run in CI without writing. The five files a sync touches are listed explicitly: docs/data/manifest.json, docs/leetcode-animation-index.md, docs/index-by-topic.md, docs/sync-log.md, and docs/data/stats.json together with the marked region of the README. Longer rules, commit conventions and the mechanism for taking over the numbers are said to live in docs/sync-workflow.md and docs/HOW-TO-INTERACT.md.

Early articles and animation files sit per problem under problems/

The repository is not only an index. Older material is kept in a per-problem layout, with docs/notes/ holding early write-ups and a problems/ directory where each problem has its own Article/ and Animation/ subdirectories. The current preview frames live separately in docs/assets/previews/, which is where the README's GIFs come from. A reader looking for the original explanation of a specific problem is pointed at those paths rather than at the generated indexes.

There is a language detail here that the metadata and the README disagree about, mildly. The repository records Java as its primary language, and Java is one of the three reference implementations attached to each problem. The README's 2026 notes say the three implementations are Python, C++ and Java, with Python the default. Every script in tools/scripts is JavaScript, including review-site-changes.js, sync-algomooc-index.js, validate-manifest.js and build-readme.js. So the problem content and the tooling are written in different languages, and if you are looking for the Python version of a solution, the default the README names is not the one GitHub reports as dominant.

There is no licence file, which is the sharpest limit in the repository

The root of the repository contains .gitattributes, .gitignore, README.md, docs/, package.json, problems/ and tools/. There is no LICENSE file, and no licence is named anywhere in the README. Nothing in the repository states what you are permitted to do with the animations, the diagrams, the reference implementations or the prose.

For reading, this changes nothing. For anything else it matters a great deal. A repository with no stated licence grants no permission to copy, redistribute, translate or embed its assets, which means the obvious uses, putting an animation in a course, republishing a diagram in a slide deck, or forking the problem set for a bootcamp, are all questions you have to take to the maintainer rather than decisions you can make yourself. It also means the fork button on GitHub carries no accompanying rights, whatever the interface suggests.

The contrast with the rest of the project is sharp. This is a repository that goes to real lengths to make its numbers machine-verifiable, to document its sync workflow, to script its badges and to state exactly which of its two counts means what. None of that rigour is applied to licensing. If you intend to reuse anything here, get the answer in writing before you build a lesson plan around it.

The three headline features exist only on the website, and one of them is still in progress

The 2026 progress notes list four items and mark them with different statuses, which is more informative than the list of features usually given for a project like this. Three are done: reference implementations in Python, C++ and Java for every problem, an AI algorithm tutor called Xiao'ou that you can ask for hints and boundary cases when you get stuck, and spoken narration that runs alongside the animation, synthesised in a voice belonging to the maintainer with that voice licensed for the purpose. The fourth is still in progress: a full quality review across 299 animations, one problem at a time, reworked and released in batches, with the results synced back into the repository index.

Two things follow. The narration and the tutor are website features, so the repository cannot show you whether a given problem has them or how they sound, and the progress notes describe them at the level of the whole site rather than per problem. And the quality review is the reason the two counts are hard to reason about: 256 animations are synced while 299 exist on the site, and the gap is exactly the kind of backlog a per-problem reworking pass produces.

The repository's own status line is that this is not a one-off archive and that a major version upgrade is in progress during 2026, with only launched or in-progress items listed. The last push was on 2026-06-12, and there are no GitHub releases, so progress is tracked through the commit history and docs/sync-log.md rather than through version numbers.

Editorial conclusion

LeetCodeAnimation is worth your time if you learn algorithms by watching pointers move rather than by reading proofs, and if you can accept that the artefact you study lives on a website while GitHub gives you the index and the history. It is a poor fit for offline study, for a curriculum you need to pin to a specific problem set, and for anyone planning to reuse the animations, because the repository ships no licence file. Before you commit a week to it, open four problems on algomooc.com and confirm the playback controls work for the problem you are stuck on, since the single-step and rewind features exist only there and the repository cannot tell you whether a given animation has been remade.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository