yinguangyao/blog, a repository with one file and eighty four links in it

The repository root holds one file and no licence

The entire tree is a single markdown document. There is no source directory, no package manifest, no test suite, no continuous integration configuration, and no build script, because there is nothing in the repository to build. GitHub cannot detect a primary language for it, and it detects no licence either, since the tree contains no licence file. The default branch is still called master, and there are no releases and no tags.

The last push to that branch is 11 July 2026. The repository is not archived, so nothing about it is closed, but a push that changes one markdown file is a push that changes one markdown file.

What that shape means is that there is no clone step worth doing. A reader who wants the writing fetches a page, and a reader who wants the tooling finds none here. The single file is doing the work of a site, a sitemap, an archive, and an about page at the same time, which is why it starts with a paragraph about the author rather than a sentence about the project.

Fifty seven of the entries are issue numbers, not files

Every article in the index is a link, and the links do not all point into the repository. Fifty seven of the eighty four entries address the project's own issue tracker by number, and those numbers run from 34 to 100 with no number used twice. The remaining twenty seven resolve somewhere else, which is the subject of the next section.

So the content lives in the tracker. An issue is a reasonable home for a long essay: it has a number, a title, a body, comments, and a permalink, and it can be closed without being deleted. It is a poor home for a body of work, because the index has no way to know whether issue 56 still exists, and nothing in the file is generated from the tracker, so the two drift apart independently.

The tracker holds at least a hundred items and the index names fifty seven of them by number. Nothing in the file accounts for the rest, which means the numbering contains gaps the reader cannot interpret: a missing number might be a closed issue, a draft, or a private note.

A quarter of the entries resolve through a trailing block of labels

Twenty five entries use reference style links, which means the visible line carries a bracketed integer instead of an address. The definitions sit in a block at the very bottom of the file, after the last section, and they are not related to the issue numbers. Label 1 points at issue 7, label 2 at issue 15, and label 3 at issue 16, so the label is a citation number in a sequence of its own rather than a pointer into the tracker.

That is fine for a reader clicking through and awkward for anyone who wants to cite a specific part. To name the fifth article of the oldest eight part series you have to resolve label 5 first, and the mapping exists only at the bottom of the page. The labels are also sparse: the sequence jumps from single digits into the teens and then into the twenties and thirties, so the missing numbers are not a signal that entries were deleted.

Two entries do not resolve to the tracker at all. A 2020 piece on how React hooks work and a 2021 piece on managing front end projects in a single repository both point at a different writing platform instead. The index is therefore a partial mirror, and for those two subjects the mirror is not the original.

Only the newest series is numbered in both its titles and its issues

Three entries in the index are multi part series, and only one of them is safe to read in order. The newest series has eight parts whose titles are numbered one through eight, and they occupy eight consecutive issue numbers, 93 through 100. Title order, part number, and issue number all agree, so nothing can go missing without it being obvious.

The two older series do not have that property. A two part architecture analysis of a code editor sits at issues 86 and 87, which is consecutive, but the titles carry no part numbers, so a reader arriving at part two has no way to confirm it is part two. The eight part Underscore series is the worst case: every part is dated 2018, every part is a reference label, and the visible definitions send the first three to issues 7, 15, and 16, which are not adjacent and not in ascending order.

The general rule for this index is that the newest work is navigable and the archive is a flat list. Fifty seven of the eighty four entries are single essays with no ordering information at all beyond a year.

Every entry has a year, and the sections are sorted by nothing

All eighty four entries carry a year, rendered as small type after the link. Within each section the years descend, so the newest item in a group is at the top, and that convention holds without exception across all twelve sections.

The sections themselves are ordered by something else. The first three hold work from 2026 and 2025. The fourth is a React group whose newest entry is from 2022, and it is followed by a work-notes group whose newest entry is from 2023. So the sequence runs 2026, 2026, 2025, 2022, 2023, and then a canvas group that also starts in 2023. The descending order resumes further down and then breaks again at the end.

The last group is a catch-all with five entries spanning 2022 down to 2018, and it opens with a compilation of answers posted on another platform. Its final three entries are a set of notes on a book about writing readable code, a summary of a personal finance book, and a short piece on learning to program. A technical index that ends with a summary of a personal finance book is telling you something about how the file is maintained: new work goes to the top, and anything that fits nowhere goes to the bottom.

The newest eight entries build an agent that could actually be run

The first group in the file is five pieces about agents written in 2026 and 2025, and the second group is eight more. Together they are the most current work in the index and the only part of it that describes something rather than explains something.

The eight part series takes a coding agent apart in a fixed order: a single call to a language model, streaming responses, tool calls, a reasoning and acting loop, tools that touch a real codebase, parallel tool calls, a skills mechanism, and finally session persistence across more than one conversation. Read in order they describe an agent being assembled from nothing, and the eighth entry implies a program that can be started and stopped.

The three entries above it are shorter and referential. One claims to have packed five coding agents into a single npm package, one is about redesigning a command line for an agent, and one reads the core design of one agent implementation through the source of another. Those three are announcements and commentary; the eight are a build. The index offers no link between the two groups, and no way to tell from the titles whether the npm package in the first entry contains the agent from the second.

Two list styles and two indented headings in the same file

The formatting records the file's history more precisely than the dates do. The first three sections set their bullets flush against the left margin. The remaining nine indent every bullet by a single space. Two of the twelve headings carry leading spaces of their own, one of them two spaces, while the ten headings around them carry none. One entry separates its link from its year with two spaces where the other eighty three use one.

None of that breaks anything. All of it still renders as a heading and a list, which is the point: a file assembled by hand for eight years accumulates small inconsistencies that no tool complains about and nobody has reason to fix, because each change is one line and the file has no formatter attached to it.

The consequence for a reader is that the file cannot be parsed by anything except a markdown renderer. There is no front matter, no table of contents, no tags, and no machine readable index. If you want the eighty four titles as data, you have to scrape them, and the two entries that live on another platform will come back as bare labels rather than as addresses.

The file opens with a column, a book, and a contact handle

Before the first heading there are three lines of prose. The author introduces himself by the name null, describes the areas he works in as mobile web development, the React family of tools, front end build practice, and web rendering, and then points at a column he writes on a different platform, a book he wrote for a course platform, and a messaging handle with an invitation to add him.

That paragraph is the only prose in the file, and it establishes where the writing actually lives. The column and the book predate the repository, and two of the eighty four entries still resolve to that earlier platform rather than to the tracker. So the relationship between the index and the body of work is the reverse of what a repository normally implies: the writing came first, the tracker was used to store it later, and the readme is a hand maintained list of links into storage that was never designed to be a publication.

It also explains the catch-all at the end. A file that begins as a personal index and grows by appending has no rule that says a piece of notes on a book does not belong in a front end engineering archive.

Editorial conclusion

Treat this repository as a reading list rather than a codebase, and expect nothing to install. Before you point anything at it, check three things. That the article you want still resolves, because the index points at an issue tracker where entries can be closed or renamed without the index changing. That you follow the trailing reference labels when a title does not carry a visible link, since a quarter of the entries resolve only through a block of definitions at the bottom of the file. And that you look for the article off-repository where the link points to another platform, because the readme is a partial mirror of a body of writing that started somewhere else.

Frequently asked questions

Official sources

1. Issues
2. README
3. yinguangyao/blog on GitHub