iflytek/astronclaw-tutorial: a VitePress site that documents two AI assistants, not an SDK

What the repository actually is: a VitePress docs site for two hosted assistants

The name suggests a tutorial about a piece of software you install. The repository layout says otherwise. The README states the project is built on VitePress, and the local workflow is the standard VitePress one: clone, npm install, npm run docs:dev, npm run docs:build. There is no package published for AstronClaw or Loomy here, no library entry point described, and no runtime the tutorial asks you to embed. JavaScript is listed as the primary language, which is consistent with a static site generator project rather than an agent framework.

The subject matter is two products. AstronClaw is described as a cloud AI assistant built on OpenClaw core capabilities, reachable through enterprise messaging channels including WeCom, DingTalk and Feishu, with a claimed 130+ official skills and a skill marketplace. Loomy is described as a desktop AI work companion aimed at office scenarios, with directory-level authorisation for local files and support for custom model API providers. The tutorial's job is to walk a reader through both.

That distinction matters for anyone evaluating the repository. If you arrived expecting source code for an agent, you will find documentation and a static site build instead. If you arrived wanting structured onboarding material for those two products, the repository is exactly that, and the Apache-2.0 licence makes reuse of the text straightforward.

The audience the README names, and the audience it quietly excludes

The README is explicit about who the material targets: readers with no programming experience who want an always-available assistant, people who want to control an AI remotely through Feishu or DingTalk, and content or operations teams handling information collation and multi-tool workflows. The framing is usage-oriented throughout. Nothing in the described modules asks the reader to write code.

That is a coherent choice, and it also draws a boundary. A developer looking for the OpenClaw core, the skill manifest format, or the protocol AstronClaw uses to talk to DingTalk will not find it described in the README. The skill system is presented as a product feature (marketplace install, repository search, install through conversation, custom skills) rather than as a specification. The custom-skill path is the one place a technical reader might expect detail, and the README only names it as a capability.

The second boundary is language. The repository ships a README_EN.md and links to it, so an English README exists, but the primary README is Simplified Chinese and the tutorial content is aimed at Chinese office tooling. Loomy's listed scenarios (self-media operation, e-commerce, calendar and to-do management, remote mobile work) and the channel list (Feishu, DingTalk, WeCom) are all domestic-market oriented. An English-speaking team evaluating this as a general-purpose assistant guide should expect to translate, not just read.

How the tutorial is structured: two parts, cloud first then desktop

The README splits the material into two modules. Part one covers AstronClaw: quick start with one-click deployment, the skill system, and channel integration with enterprise collaboration platforms. Part two covers Loomy: positioning and characteristics, typical work scenarios, and security and privacy.

The ordering is deliberate. AstronClaw comes first because the cloud product removes local environment setup, which is the README's stated reason for leading with it: no local configuration, a service that stays online. A reader with no programming background can get a result before touching anything that runs on their own machine. Loomy comes second and is framed around local file access and system tools, which is where the authorisation model becomes relevant.

One structural detail worth noting is that the repository also points readers outward. The README links to an online reading site, a cloud trial page at agent.xfyun.cn, and a Loomy download page at loomy.xunfei.cn. The tutorial is therefore a companion to live products rather than a self-contained artefact. If either product's interface changes, the tutorial text and the product diverge, and the repository carries no version pinning that would make that divergence visible.

Running the docs locally: four commands and no configuration keys

The README gives four commands for local work. Clone the repository, install dependencies, start the preview server, build the static output:

git clone https://github.com/iflytek/astronclaw-tutorial.git cd astronclaw-tutorial npm install npm run docs:dev npm run docs:build

That is the whole setup surface described. There are no environment variables, no API keys, no config files named in the README, and no service the local build needs to reach. The build is a static site, so npm run docs:build produces files you can host anywhere.

The absence of configuration is a genuine advantage for a documentation project: a contributor can preview changes without credentials for AstronClaw or Loomy. It also means the repository cannot demonstrate the products. Reading the tutorial locally shows you the text and the screenshots, not a working assistant. Anyone who wants to follow along with the actual features has to go through the linked product pages, which sit outside the repository and outside its licence.

Deployment is handled in the repository: the README's badge points at a GitHub Actions workflow at .github/workflows/deploy.yml on the main branch. The push timestamp on the default branch is recent, so the site build is being maintained, though no releases have been published, which is normal for a docs repository.

Contributing means signing a CLA, and the licence covers the text

The README states that pull requests require reading CONTRIBUTING.md and that a CLA Assistant bot comments on a first pull request to guide the contributor through signing a contributor licence agreement. For a documentation project this is a heavier gate than many docs repositories impose, and it is worth knowing before you plan a translation or a correction. If you intend to fork and adapt the material inside a company, the CLA applies to contributions back to this repository, not to your fork.

The project is Apache-2.0. That permits reuse and modification with the usual obligations around attribution and notice retention, and it includes a patent grant. It does not, and cannot, grant you anything over AstronClaw or Loomy themselves, which are separate hosted products with their own terms. A fork of this tutorial is a fork of documentation. Nothing in the README suggests the products are open source, and the OpenClaw reference is described as a core capability the cloud assistant is built on, not as code shipped here. Treat the licence as covering the site and its text only.

Where this is the wrong tool: no runtime, no protocol, no offline path

The clearest failure mode is a mismatch of expectations. If your goal is to run an agent on your own infrastructure, this repository does not help. It documents two products that the README presents as hosted: AstronClaw as a cloud service and Loomy as a desktop application you download from a vendor site. There is no self-hosting path described, no container image, no server component in the repository.

A second limitation is depth on the parts a technical reader would probe. The skill system is described in product terms (130+ official skills, marketplace, repository search, conversational install, custom skills) without the mechanics. Channel integration names Feishu, DingTalk and WeCom without describing the setup handshake. Loomy's security model is summarised as directory-level authorisation without stating what the permission boundary actually enforces or where the model API calls are routed when a custom provider is configured. Those are exactly the questions a security reviewer would ask before letting a desktop assistant touch local files, and the README does not answer them.

A third limitation is that the material is unversioned against the products. There are no releases, so there is no changelog describing which product build a given tutorial revision matches. When a hosted product changes its UI, the tutorial's screenshots and steps age silently.

The alternative worth comparing: reading the products' own documentation

The obvious alternative is to skip the tutorial and work from the vendors' own material. The README links to an online version of this tutorial, a cloud trial page, and a Loomy download page, so the primary sources are one click away. The difference in approach is editorial rather than technical: vendor documentation is organised around features and reference behaviour, while this repository is organised around a learning path, taking a reader from first contact to a working setup across two products in a fixed order.

That ordering is the tutorial's actual contribution. A reader who does not know which product to start with gets an answer here (cloud first, because it avoids local setup), and the module split keeps the two products from being mixed together. A reader who already knows they want Loomy, or who only needs the DingTalk integration steps, gets less value from the sequence and should go straight to the product pages.

A second comparison point is the language of the surrounding ecosystem. Tutorials for comparable assistant tooling are predominantly English. This one is Chinese-first, with an English README but no indication in the README that the full tutorial is translated. For a team operating on Feishu, DingTalk or WeCom, that alignment is a reason to prefer it over a translated general guide; for anyone else it is friction.

Maintenance cost and what to check before you depend on it

The upkeep burden here is low in the technical sense and high in the editorial sense. Technically, a VitePress site needs dependency updates and a working deploy workflow, and the repository has both a build badge and a recent push to main. Editorially, the content tracks two live products, and every product change is a documentation change. There is no release process to signal when that work happens, so a reader has no version marker to check against.

The CLA requirement adds a small fixed cost to any contribution, and the Apache-2.0 licence keeps reuse simple as long as attribution and notices are preserved. Neither imposes an ongoing obligation on someone who only reads the site or forks it internally.

Before depending on this repository, check three concrete things. Open the online reading site and confirm the two-part structure still matches the README's module list. Open the Loomy download page and the AstronClaw trial page to confirm both products are still reachable, since the tutorial is useless without them. Then run npm run docs:dev against a fresh clone to confirm the site builds on your Node version, because a docs repository that no longer builds locally is a docs repository you cannot correct.

Editorial conclusion

Adopt this repository if you need a Chinese-language onboarding path for AstronClaw or Loomy and you are comfortable reading docs rather than code. Do not adopt it if you need an installable agent runtime, an English-first tutorial, or a self-hosted assistant, because the README describes hosted products and the repository itself is a VitePress site. Verify first that the two linked products still match the tutorial's module list, then run npm run docs:dev locally to confirm the docs build before you point anyone at a fork.

Official sources

1. iflytek/astronclaw-tutorial on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README