ChinaGodMan/UserScripts: a Tampermonkey collection for GitHub, ChatGPT and GreasyFork

What ChinaGodMan/UserScripts actually is

This is not a library you import. It is a collection of standalone userscripts, each living in its own top-level directory: chatgpt-code-hightlight, github-file-size-viewer, github-folder-downloader, greasyfork-link, csdn-blocker, google-advanced-search, and dozens more. Each directory holds a script that a userscript manager injects into matching pages. The README describes the project as "一些修改自网络的油猴脚本", scripts modified from the internet, and states plainly that the author only made small changes to other people's work and will remove anything on request.

The audience is narrow and specific. If you want GitHub's file list to show sizes, or ChatGPT's code blocks to be highlighted and copyable, or GreasyFork pages to link somewhere useful, you install one file and stop thinking about it. There is no plugin API, no shared runtime, and no configuration layer that spans scripts. The repository is a distribution shelf, not a framework.

How the scripts run, and why the repo layout matters

Userscripts execute inside the page context through a manager such as Tampermonkey or Violentmonkey. The manager reads a metadata block at the top of each file to decide which URLs to match, then injects the script. Everything here follows that model, which is why the repository is organised as one directory per script rather than as modules.

The tooling around that is a normal JavaScript project. package.json lists eslint, prettier, husky, lint-staged and cz-git as devDependencies, with eslint-plugin-userscripts in the mix, which suggests the metadata blocks are linted too. The build script is a PowerShell invocation:

pwsh -noprofile -command buildscript

A separate Python utility bumps versions:

python utils/update_version.py

That combination (PowerShell for the build, Python for version bumps, Node for linting) is the clearest signal of how the project is maintained. It is a personal publishing pipeline, not a toolchain designed for outside contributors to run on a clean machine.

Installing a ChinaGodMan userscript

The README points readers to GreasyFork, where the author's scripts are published under user 1169082. That is the intended install path: you need a userscript manager first, then you install from the GreasyFork listing rather than from the repository source.

If you prefer to work from the repository, clone it with git clone and open the directory for the script you want, for example github-file-size-viewer. The repository does not document a per-script install command, so the only thing the tree tells you is where each script lives.

Once you have the file, open it, check the metadata block for the @match rules, then load it into your manager as a local file. A first real use looks like this: install github-file-size-viewer, open any GitHub repository file listing, and the file sizes appear in the list. If they do not, the @match pattern does not cover the page variant GitHub served you, which is the most common failure with any userscript.

For the ChatGPT scripts, the same pattern applies with a different target. Install chatgpt-copy-code-button, open a conversation containing a code block, and a copy control should appear on the block. The README does not document per-script options, so treat each script as having no configuration surface unless its own metadata says otherwise.

The licence question the repository does not settle

This is the part to read carefully. The repository metadata reports a licence of NOASSERTION, meaning GitHub could not classify the file. package.json declares "license": "MIT". The README states that the scripts come from other people on the internet, that the author made only small changes, and that infringing content will be deleted on request. Those three statements do not agree with each other.

A fork of someone else's userscript can only be relicensed as MIT if the original permitted it. The repository does not document the provenance of individual scripts, so you cannot tell from the tree which ones are clean. For personal use this is mostly an academic problem. For anything you redistribute, bundle into a product, or ship to a client, it is the first thing to resolve, and the answer lives in LICENSE.md plus the original script's own metadata, not in package.json. Nothing here is legal advice; the point is that the declared licence and the stated origin story conflict, and you should not paper over that.

Where this collection is the wrong tool

Userscripts are injected into pages you do not control, and that shapes every limitation. A GitHub redesign breaks a script until someone updates the @match pattern or the DOM selectors. The repository does not document a compatibility policy, a supported browser matrix, or a testing process, so a broken script is discovered by users, not by CI.

There is also a maintenance asymmetry. The last push to the repository was on 2026-09-08, so the project is being touched, but the tree mixes scripts for GitHub, ChatGPT, GreasyFork, CSDN, Google and a category the topics list only as missav-downloader. Those targets change at different rates. A script for a fast-moving chat interface will rot faster than one that adds a button to a static page, and nothing in the repository signals which is which.

If you need a guaranteed behaviour on a page you depend on, a userscript is the wrong layer. It has no contract with the site, no error reporting, and no way to fail loudly. It fails by doing nothing.

The alternative: writing your own single script

The honest comparison is not another userscript collection. It is writing the one script you actually need. A userscript that adds a file size to a GitHub listing is a few dozen lines of DOM manipulation plus a metadata block, and you own the @match rules, the update path and the licence outright.

The trade-off is real in both directions. Adopting a script from this collection costs you nothing today and gives you a feature that already handles edge cases the author hit. Writing your own costs an afternoon and gives you something you can fix the day GitHub changes its markup, without waiting for an upstream you do not control. For a script you use daily and would miss, the second option ages better. For a one-off convenience on a site you visit twice a month, take the existing script.

Upgrades, and what to check before you rely on a script

Because each script is installed independently through a manager, upgrades are per script and depend on where you installed it from. GreasyFork installs can update through the manager when the published version changes. Local file installs from a clone do not update themselves; you re-copy the file after a git pull.

The version bump path in the repository is the Python utility referenced in package.json:

python utils/update_version.py

That tells you versions are managed centrally by the maintainer, not by contributors sending patches. If you fork a script and change it, you are outside that flow and will need to track upstream by hand.

The practical check before relying on any script here: open the file, read the @match block, confirm it targets the exact URL pattern you use, and note the @version. That is the whole audit, and it takes a minute.

Editorial conclusion

Use this collection if you live in GitHub, ChatGPT or GreasyFork and want small page-level fixes without writing them yourself, and if you accept that each script is a fork of someone else's work with an unclear upstream. Do not adopt it as a base for anything you ship to customers: package.json declares MIT, the repository metadata reports NOASSERTION, and the README states the scripts come from other people and that the author only made small changes. Verify first by reading LICENSE.md against the specific script directory you intend to use, then install one script from GreasyFork and confirm it survives a Tampermonkey update.

Frequently asked questions

Official sources

1. ChinaGodMan/UserScripts on GitHub
2. Issues
3. Project website
4. README