1.6k stars, 1.2k forks, one commit: what GitHub counters do not tell you

GitHub's page for Binaryify/open-kimi-ppt-skill shows a repository that was archived and made read-only after its contents were cleared for copyright reasons ^[1]. What remains is a file listing containing README.md and a single commit, sitting under counters that still read 1.6k stars and 1.2k forks ^[2][3].

The listing's own description is intact and still specific: an unofficial Kimi Slides skill for AI agents that generates editable PPTD and PPTX files and ships a local browser editor ^[5]. As dev.to notes, those are load-bearing claims rather than decoration, since "editable" is what separates a structured deck from a flattened image export, a browser editor implies an iteration path after generation, and two output formats bear on interoperability ^[6]. None of it can be checked. There is no implementation left to show what a "skill" meant here, how an agent invoked it, whether PPTD and PPTX were produced directly or by conversion, or what the local editor could actually do ^[7], and the README carries no documentation beyond the clearance notice, in Chinese and English ^[4][8].

Run the arithmetic on the counters and the mismatch is the whole story. The repository holds roughly 1,600 stars per commit ^[15] and three forks for every four stars ^[14]. Those are not signals of a maintained dependency; they are signals that a lot of people once saw a good description. The dev.to writeup makes the same point more plainly: the figures lend the page an appearance of maturity while being historical markers attached to a repository whose substantive contents no longer exist ^[16].

This is where the practical damage sits. Assessing an open-source dependency normally means reading the code, enumerating bundled assets and transitive dependencies, reviewing the license, reproducing a build, and deciding whether you could maintain the thing yourself; a copyright clearance removes every link in that chain at once ^[11]. A prospective user cannot pull a normal source distribution from the page, and a prospective contributor has nothing to review ^[13]. The six listed issues and the absence of visible pull requests do not change the position ^[10].

The forks are not a workaround either. The count suggests copies existed somewhere on the network, but the page does not establish what any fork contains, whether it is still reachable, whether it is current, or whether it carries the same copyright problem it was cleared over ^[12]. Cloning a fork of a repository that was emptied for rights reasons is not diligence, it is inheriting an unexamined liability.

Note also what is not asserted: the page does not say what material triggered the issue, who claimed rights, whether the disputed content was code, assets, documentation or a further dependency, or whether anything will replace it ^[9]. Anyone filling that in is guessing.

What to watch: whether a named rights holder or a takedown record ever surfaces to explain which layer was infringing ^[9], whether any fork publicly claims to hold the cleared code and on what license basis ^[12], and whether the six open issues get a maintainer response now that the repository is read-only ^[10]. For internal tooling policy, the more useful watch item is closer to home: if your intake checklist for a new dependency accepts star and fork counts as evidence of anything other than past attention, this repository is the counterexample to point at ^[2][3][16].