The guide says it deleted parts of the document it came from

A derivative that admits it is incomplete

The most useful line in the feature list is the one about deletion. The guide states that some content was removed and that readers who need it should consult the original document, and it names that document: the guide derives from Arch Linux 安装使用教程, the ArchLinuxTutorial project. That single admission tells you more about how to use the site than any amount of praise in the same list. The positive claims are that details and principles are explained thoroughly, with the stated intent that you understand why rather than only how, and that more visual material was added to make it vivid. The third claim is a stance: the guide follows what it calls Arch's practicality principle, avoids ideological questions, and is described as more tolerant of non-free software. That is a real editorial position on a distribution whose official repositories exclude such software, and it means this is a companion to Arch rather than a replacement for it.

Badges tell you the branch and the audience, not much else

The header is a wall of badge markup, which is worth reading as a description of how this project is maintained rather than as decoration. There is a build status badge whose image is served by an actions-badge endpoint with a ref parameter set to main, so the status describes the default branch rather than a published artifact. There is a hit counter pointed at a third-party counter service, a GitHub last-commit badge, a stars badge, a terms badge linking to the LICENSE file, and a Contributor Covenant badge reading version 2.0, with the corresponding text hosted as a page under the project's own domain. Two of those are for humans and two are for tooling. The last-commit badge is the one with practical value: on a documentation project whose commands can drift, knowing how recently the branch moved is more useful than knowing how popular the repository is.

The terms are a documentation license rather than a software one, CC-BY-SA-4.0, which suits a guide whose deliverable is prose and which readers are expected to translate or fork.

It is a documentation site, not a package

Understanding what this repository is saves confusion. The primary language recorded for the repository is Dockerfile, which is an artifact of how the project is structured rather than a statement about its subject matter. What it actually is, is a VitePress documentation site, and the build badge comes from an actions-badge endpoint pointing at the main branch. The published site lives at arch.icekylin.online, the README logo links there, and there is a separate page under that domain for the contributor covenant, which is also shown as a badge. The feature list describes the format work as VitePress driven with optimized formatting, and the contributing section is referenced as a place to find what still needs improving. So the repository holds markdown sources, a VitePress configuration and public images, and the deliverable is a website. There is no binary to install and nothing to add to a system.

Scoop is documented too, in a PowerShell block

The presence of a third platform is the detail that says the audience is wider than Arch users. Alongside the pacman and Homebrew routes the README includes a Scoop route written as a PowerShell block, which places the site in front of Windows users who intend to read the guide before installing anything. That reading matters for the project's shape. The site is a static documentation build that runs anywhere Node runs, so nothing about it is Arch-specific except its subject, and the three installation routes differ only in how they obtain pnpm. It also means a reader can clone the repository and read the markdown directly without the site at all, which is the more reliable fallback when a page is half written or a command is out of date.

The three routes converge on the same pnpm install and the same dev script, so there is no platform-specific configuration described beyond the prerequisite.

Two ways to get pnpm, then the same three commands

Running the site locally takes one prerequisite and three commands, and the prerequisite varies by platform. On Arch, which is fitting given the subject:

sudo pacman -S nodejs pnpm
git clone https://github.com/nakanomikuorg/arch-guide.git
cd ./arch-guide
pnpm i
pnpm docs:dev

The Homebrew route installs pnpm alone and then runs the identical clone, install and dev commands. A third route is documented for Scoop in PowerShell, which matters because the guide's audience is not confined to Arch and the site is a general web development stack. Node itself comes along with pnpm in the pacman line, while the Homebrew line does not mention node, which is a small difference between the two instruction sets that will surface as a missing binary rather than as a clear error. The script name, docs:dev, confirms this is a documentation site with its own dev server.

What the guide claims to cover

The scope statement is in the repository description and repeated in the README: Arch Linux installation, configuration and maintenance, with the aim of helping a newcomer get started quickly, and the description extends that to graphics drivers, everyday software configuration, multimedia production and programming. That is an unusually broad claim for a single handbook, and it is the reason the site is organized as a site rather than as a single document. A reader arriving from a Windows or macOS machine is the implied audience, which matches the stated purpose of letting Arch become a daily system rather than a weekend project. The page also carries a construction notice, meaning parts of the site are still being written, so a reader arriving from a search engine may land on a section that is outlined rather than finished.

Where this guide is the wrong source

Four cases. The first is an English reader. The content is written in Chinese, the README offers no English version, and the site is hosted on a domain whose subject is the distribution rather than the language, so there is no obvious translated edition to fall back on. The second is anyone treating it as the canonical Arch documentation. The Arch project publishes its own wiki, and this site describes itself as a derivative with deletions, which means a command you find here may be a simplification of the official guidance rather than a restatement of it. The third is a machine where you cannot run a Node build. The site is served, so reading it needs nothing, but contributing to it needs Node, pnpm and a working VitePress toolchain, which is a real barrier for a handbook whose stated goal is to be improved by readers. The fourth is time. The guide describes itself as having many places that need improvement, its build status points at the main branch, and the last push to that branch was on 2026-06-09, so a command that was correct when written may have drifted from what the current repositories do. Reading it is still worthwhile; treating it as authoritative is not.

Editorial conclusion

arch-guide suits a Chinese-speaking reader setting up Arch Linux who wants one page covering installation, drivers and daily configuration instead of searching a wiki for each step. It does not suit an English reader, and it is a curated derivative rather than a complete reference. Before adopting, check the section list against your own setup, keep the upstream ArchLinuxTutorial open for anything the site has removed, and read any command against the current Arch documentation before you run it.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. nakanomikuorg/arch-guide on GitHub
4. Project website
5. README