Spec Kit CN: a Chinese working copy of GitHub Spec Kit

A translation of the upstream tool, not a replacement workflow

Spec Kit CN describes itself as an unofficial Chinese replica of GitHub Spec Kit, and the repository description says the same thing in one line. The differences table in its README is short enough to reproduce: the command is specify-cn instead of specify, the distribution package is specify-cn-cli instead of specify-cli, and the documentation is written in Chinese. There is no new idea about spec-driven development here. The concept it teaches, turning a written specification into an executable plan and then into tasks, comes from the original toolkit, and the fork keeps the same agent-facing command names so the slash commands stay recognizable.

That framing matters when you evaluate it. A mirror project is judged on translation fidelity, packaging reliability and how quickly it picks up upstream changes, not on original engineering. The project pins its correspondence explicitly, noting that it tracks upstream release v0.5.0, and it states that the team keeps the fork in sync with the original so Chinese-speaking users receive the same fixes and features. For a reader who wants to know what the fork actually changes, the answer is the surface language, the command name, the package name, and two initialization modes described later in this article.

How specify-cn init seeds a project with slash commands

The initializer is the entry point. Running specify-cn init against a directory writes a set of agent commands into that directory, and those commands drive the rest of the workflow. Most agents expose spec-kit style commands in the form of slash commands prefixed with /speckit., while Codex CLI in skill mode uses a skill-prefixed form instead. The initialization examples show three ways of pointing the tool at a target: a new project by name, the current directory with a dot, or the --here flag, each optionally combined with an agent selector such as --ai claude.

The workflow itself is a sequence of prompts rather than a script. You describe intent first, then stack, then let the agent break the plan into tasks, then run the implementation. The task and implementation steps are the only two that take no arguments:

/speckit.tasks
/speckit.implement

Everything earlier in the sequence expects prose. The constitution step defines the principles and guidelines that later work should follow, the specification step is supposed to describe what to build and why rather than which technology to use, and the plan step is where you hand over the stack and architecture choices. The design intentionally separates the what from the how, which is why the tool is an assistant-driven scaffold and not a generator with fixed inputs.

Installing the CLI and running a first project

A persistent install pinned to a release tag is the recommended path, and the README points to the Releases page for the current tag. The installer of choice is uv, and the package is specify-cn-cli:

uv tool install specify-cn-cli --from git+https://github.com/linfee/[email protected]

The same page also shows an unpinned variant that follows the main branch, with a comment warning that it may include unreleased changes. Once the tool is on your PATH, a first run is short. Create a directory for the work, then verify that the initializer and the agent integration are present:

specify-cn init <PROJECT_NAME>
specify-cn init . --ai claude
specify-cn init --here --ai claude
specify-cn check

If you would rather install nothing, the one-shot path runs the same command through uvx against the same tagged repository:

uvx --from git+https://github.com/linfee/[email protected] specify-cn init <PROJECT_NAME>

The persistent install suits daily work because the command stays available across shells, which the project lists alongside cleaner shell configuration and working tool management operations for listing, upgrading and uninstalling installed tools. The one-shot form suits a quick trial, but it resolves the package on every invocation, so it is the slower option for a team that will run the initializer repeatedly.

Offline init and the skills layout for Codex and Kimi

Two flags carry most of the fork's practical value. The first is --offline, which the docs recommend for users inside China and explain in plain terms: it initializes directly from resources bundled inside the package instead of downloading them from GitHub. The stated motivation is stability under poor network conditions, and template download timeouts, certificate validation failures and firewall interception are the specific failures it avoids. The second flag is --ai-skills, which installs the built-in commands as agent skills rather than as command files. It is framed for teams that have already moved to a skills-based workflow, and Codex, Kimi and Antigravity are singled out as agents where the older command layout causes compatibility trouble.

The combination is the interesting case:

specify-cn init my-project --ai claude --offline
specify-cn init my-project --ai codex --offline --ai-skills
specify-cn init my-project --ai kimi --offline --ai-skills
specify-cn init my-project --ai agy --offline --ai-skills

Note that the agent selector accepts several names, so the initializer is not locked to one assistant. The tradeoff is that --ai-skills and a plain command layout produce different directory shapes, and mixing them across projects in the same repository is the kind of inconsistency that costs time later. Pick one layout per project.

The wheel ships its own templates, which is what makes offline mode possible

Offline initialization works because the package embeds the assets it would otherwise fetch. The pyproject.toml lists the package name as specify-cn-cli with version 0.5.0, requires Python 3.11 or newer, and builds with hatchling from the src/specify_cli package directory. The dependency list is small and ordinary for a command line tool: typer and click for the interface, rich for output, httpx with socks support, platformdirs, readchar, truststore, pyyaml, packaging, pathspec and json5.

The important part is the wheel configuration. A force-include section maps the page templates directly into the built package, so specify_cli/core_pack/templates holds the agent file template, checklist template, constitution template, plan template, spec template and tasks template along with vscode-settings.json. Command templates are bundled separately into specify_cli/core_pack/commands, and the bash and powershell scripts directories are bundled under specify_cli/core_pack/scripts. A comment in the build file states the reason plainly: bundling core assets is what allows specify init to work without network access in air-gapped or enterprise environments.

This also tells you what a mirror cannot easily change. Templates are data, so translating them is straightforward, but any upstream feature that depends on new scripts or new command files has to be carried over by hand before it appears in an offline install.

Synchronization with upstream is the project's real constraint

A localized mirror inherits the pace of its source. The release list shows v0.5.0 on 2026-04-07, v0.4.0 on 2026-03-25 and v0.1.13 on 2026-03-07, and the project states that the fork corresponds to upstream release v0.5.0. The last push to the repository was on 2026-08-02, and the project is not archived. What that history means in practice is that the mapping between fork versions and upstream versions is a decision the maintainers make, and it is not always a same-day mirror.

This is the first thing to check before you plan around a feature. If your team needs a command that appeared upstream after v0.5.0, nothing in the release list shows the fork has it, and the pinned install command deliberately points at a tag rather than main, which means you would be pinned to whatever the fork has released. The docs also flag that installing from main can pull unreleased changes, a sensible warning for anyone who wants to track the fork closely.

The upgrade path is documented separately. Upgrading reuses the same installer with a force flag:

uv tool install specify-cn-cli --force --from git+https://github.com/linfee/[email protected]

The detailed upgrade guide lives in docs/upgrade.md, and the repository also carries a CHANGELOG.md, a DEVELOPMENT.md and a TESTING.md, which suggests the fork does version its own changes even while mirroring another project's direction.

The extension catalog mixes community code the project does not review

Spec Kit CN carries an extension mechanism and a catalog file, extensions/catalog.community.json, listing contributed extensions grouped into five categories: docs for reading, validating or generating specification artifacts, code for reviewing or modifying source, process for cross-stage workflow orchestration, integration for syncing with external platforms, and visibility for reporting project health or progress. Each entry is also labelled by effect, either read-only or read and write, so you can see before installing whether an extension will modify files.

The examples in the catalog make the range concrete. There is a seven-step process extension for structured greenfield workflow, an archive extension that folds merged features into the project's long-term memory, an Azure DevOps integration that syncs user stories and tasks with OAuth authentication, a checkpoint extension that commits changes during implementation to avoid one oversized commit at the end, and a cleanup extension that gates quality after implementation by reviewing changes, fixing small issues under a boy scout rule, creating tasks for medium problems and producing an analysis for large ones.

The disclaimer attached to the catalog matters more than the list itself. The extensions are written and maintained independently by their own authors, and the note states that maintainers may check pull requests only for format, directory structure and policy compliance, and do not review, audit, endorse or support the extension code. The extension site is described as a third-party resource as well, and the docs advise reviewing the source before installing and judging for yourself. Treat every entry as third-party code that will read and possibly rewrite your repository.

Licence, runtime cost and where the mirror is the wrong tool

The licence is MIT, and the fork's terms add nothing beyond the usual attribution and notice requirements for the code you take from it. Because the fork carries community extensions written by outside authors, licence terms for those specific extensions are a separate question the project does not answer for you, so check each extension's own licence before shipping it into a product.

The runtime requirements are light but not trivial: Python 3.11 or newer, uv for the recommended install path, and a network path to GitHub unless you use the offline flag. A machine that cannot reach GitHub and cannot be seeded from a wheel produced by pip download on a connected host sits outside the documented install options. The enterprise and air-gapped guide covers that case with pip download and OS-specific wheels, so the path exists, but it is a deliberate operational task rather than a single command.

Spec Kit CN is the wrong tool in two clear situations. The first is a team that reads English comfortably and wants zero drift from upstream, since tracking the original directly removes a translation and synchronization layer. The second is a team that wants to extend the tool itself: the fork bundles templates and command files as data for translation, but a genuine feature-level change to the toolkit means maintaining a fork of a fork. If your need is customization rather than translation, the upstream project and its own extension mechanism are the more direct path.

Editorial conclusion

Adopt Spec Kit CN if your team works in Chinese, sits behind a restrictive network, or already runs agents in a skills layout, and treat it as a localized mirror rather than a fork with independent development. Do not adopt it if you need upstream spec-kit features on day one, because the correspondence to upstream v0.5.0 is the only version mapping the project states. Before you commit, run specify-cn check in a scratch directory, compare the slash commands the initializer writes against the ones you expect, and confirm that a later uv tool install with the same release tag reproduces the same templates, since the project is only periodically synchronized with the original.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Linfee/spec-kit-cn on GitHub
4. README
5. Releases