Hello-AI: an LLM batch that maintains a GitHub project directory

A GitHub directory that rewrites itself from data files

Hello-AI is not a library you install and call. It is a small Node pipeline that keeps a JSON catalogue of AI repositories and turns that catalogue into a VitePress site. The scale it claims is large: 24567 projects collected, 13465 of them counted as active, thirteen categories running from foundation models to business and finance. A reader browses hello-ai.anzz.site/explore; a maintainer edits no page by hand. The design point is that discovery, judgement and publishing are one loop. New repositories are found, scored and written to disk by scripts, and the documentation pages are generated from the same files the crawler fills. Every description a visitor reads was written by a model rather than by a curator, and that single fact decides both what makes the project useful and where it misbehaves. Nothing in the repository claims a quality guarantee for those descriptions, so the star counts next to them are the only hard number on each card.

From topics.json to VitePress through four layers

Crawling starts from a seed list in `data/topics.json`. The crawler walks the GitHub API and deliberately favours topics it explored least recently, hunting for repositories with `Stars >= 500`. An unseen topic is never filed under a bucket the crawler made up: it is registered back into `data/topics.json` as a `Level 2` target, and the matching repositories are queued in `data/pending-projects.json`. The evaluation stage pops items off that queue, builds one combined prompt for a batch, and writes accepted projects into `data/projects.json`. Anything rejected goes to `data/rejected-projects/`, a separate directory rather than a deleted row. Publication comes last: `generate-docs.js` groups records by subcategory and the VitePress nav and sidebar read the category list back out of the same database file. Four stages, three JSON files, one generated site, and no human in the path between a GitHub API response and a published page.

One combined prompt carries ten repositories into the model

`discover-and-evaluate.js` does not ask the model about one repository at a time. It pops `EVALUATE_BATCH_SIZE` items, which the shipped configuration sets to 10, and concatenates them into a single prompt, so one request answers for ten projects. The stated reason is fewer API calls and reused token context. Batch sizes elsewhere are much larger: `DISCOVER_BATCH_SIZE=50` for fetching and `UPDATE_STATUS_BATCH_SIZE=50` for the health pass. Two loop modes keep the machine working unattended. `update-status.js --loop` and `loop-eval.js --tui` run until stopped, with `LOOP_INTERVAL_SECONDS=60` between passes, while `--consume-only` drains the pending queue without new discovery. `re-evaluate-all.js` is the repair path for a catalogue whose structure has drifted. The cost you inherit is token spend: every pass re-reads records the model has already judged, and the batching reduces request count without reducing the number of projects scored.

Categories come out of the database on every pass

No category list is hard-coded in the scripts. Before each evaluation the valid categories and subcategories are read out of `data/projects.json` and injected into the prompt, so routing happens against whatever the database currently holds. Two consequences follow. Renaming a category changes the routing rules on the very next run, and a project the model cannot place lands in `data/rejected-projects/` instead of a guessed category. `Trending` is the deliberate exception, and the exception is the most trustworthy row in the whole table. It is filled by an objective daily calculation of the 30 highest-star, recently updated projects, which overrides the model output. The other categories never get that correction. Two more scripts support the manual passes: `locate-sensitive-words.js` scans output for wording problems, and `extract-readmes.js --tui` reads repository text through `--input data/rejected-projects` so a human can inspect what the model threw away.

Copying the environment file and running one evaluation pass

The README documents no install command, so there is nothing to copy here. What it does give is a Node 18.x or newer badge, a `pnpm-lock.yaml` at the top level, and `.env.example`, which is the real starting point because the pipeline is useless without a model endpoint and a GitHub token.

# GitHub Token for extending Rate Limit (Optional)
GITHUB_TOKEN=

# LLM Provider Selection (Optional)
# Supported providers: openai, minimax, deepseek, ollama
LLM_PROVIDER=
LLM_API_KEY=
LLM_BASE_URL=
LLM_MODEL=
EVALUATE_BATCH_SIZE=10
DISCOVER_BATCH_SIZE=50

Set `LLM_MODEL` to a name the provider recognises, such as gpt-4o-mini, MiniMax-M2.5, deepseek-chat or llama3. Leave `LLM_PROVIDER` empty and the configuration is inferred from `LLM_BASE_URL` or the provider keys. With everything filled in, one evaluation pass and one documentation build look like this:

node scripts/discover-and-evaluate.js
node scripts/update-status.js
node scripts/generate-docs.js
node scripts/generate-explore-data.js
vitepress dev ./

The last command starts a local preview of the generated site. The `explore:generate-data` script feeds the browse page, and the README does not document what that file contains.

The active total does not match its own category table

Read the statistics block as two independent counts and it stops agreeing with itself. The line reporting `13465` active projects, updated within the last 6 months, sits directly above a table whose active column, added across all thirteen rows, comes out higher than 13465. The total column has the same problem in the opposite direction: the thirteen totals add past the 24567 collected figure printed beside them. A repository can legitimately sit in two categories, but nothing in the repository states whether the script counts unique identifiers or rows, so the gap cannot be resolved from the outside. One row is internally consistent. `Trending` reads 30 / 30, because the daily objective calculation rebuilds it from the 30 highest-star, recently updated repositories and therefore never carries a stale backlog. Elsewhere the six-month window bites unevenly: Desktop & OS Apps keeps 1319 of 1454 rows active, while Learning Resources holds 1504 of 4640 and Multimodal 1053 of 3207. A catalogue pruned by recency loses tutorials long before it loses tools.

Two recency windows decide which projects a reader ever sees

The headline figure treats a repository as active only when it was updated within the last 6 months, and the feature list describes purging stale entries while star counts and health status are refreshed through `update-status.js`. The documentation generator runs on a far longer horizon: `RECENCY_THRESHOLD_MONTHS=48` keeps anything touched in the past four years in the generated pages. A project can therefore be counted as stale in the statistics and still have its page published. The block is machine-written between `STATS_START` and `STATS_END` markers, stamped `Last Updated` on 2026-09-13, and only changes when a run rewrites it. The repository is not archived, it carries an MIT licence, and the last push landed on 2026-09-13, the same calendar date the statistics carry. The code that produces the catalogue and the catalogue itself have not moved apart since, which means anyone auditing the pipeline should compare the file dates before trusting the page counts.

Where a model-written catalogue is the wrong tool

Judgement belongs to the model and the audit trail is one directory. `data/rejected-projects/` holds what the model called unworthy or un-categorisable, and `extract-readmes.js --tui --input data/rejected-projects` is the way back in for a human verdict. A wrong call costs a re-run rather than a lost project, which is a fair trade for a discovery feed. The alternative the project sets up against is the hand-maintained link directory named in its own feature list, and the difference is concrete. A human writes one description and it stays put; this pipeline writes a description for all 24567 records and can rewrite every one of them when a full re-evaluation runs. No competing directory is named anywhere in the repository, so there is no documented comparison to check. Verify three things first. Whether generated Chinese descriptions are acceptable for your audience, since the evaluation step is built to produce them. Whether the published pages fit your own docs setup, because `docs:build` compiles this repository's VitePress configuration and nothing describes how to point it elsewhere. And whether an unaudited summary is acceptable next to the star counts it sits beside.

Editorial conclusion

Adopt the pipeline if you want a self-refreshing catalogue of AI repositories and accept that every description in it was written by a model you configure yourself. Skip it if your documentation needs reviewed prose or fixed categories, because `data/projects.json` is rewritten by each evaluation run and `data/rejected-projects/` is the only record of what was dropped. Before running anything, copy `.env.example`, set `LLM_PROVIDER` and `LLM_MODEL`, and check whether the `Stars >= 500` and `RECENCY_THRESHOLD_MONTHS=48` thresholds match the churn you want.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. xxxily/hello-ai on GitHub