# Auto-Redbook-Skills: turning Markdown into Xiaohongshu card images

> A Python and Node skill set that renders a Markdown draft into themed 1080x1440 card images for Xiaohongshu, with an optional direct publish path.

**comeonzhj/Auto-Redbook-Skills** —  一个自动撰写小红书笔记，自动生成图片，自动发布的 Skills

- Repository: https://github.com/comeonzhj/Auto-Redbook-Skills
- Stars: 2,335 · Forks: 266
- Language: Python
- License: not declared
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/comeonzhj-auto-redbook-skills

## What the repository actually is

The name oversells it a little. The repository is a set of Agent skills plus two rendering scripts and a publish script, aimed at producing image cards for Xiaohongshu, the Chinese social platform also known as RED or Rednote. The description says it writes notes, generates images and can publish them, but the code that ships is mostly about turning a Markdown file into a series of PNG images at 1080 by 1440 pixels, which is the ratio the platform recommends.

The tree is small and readable at a glance: `SKILL.md` is the instruction file an Agent reads, `assets/` holds two HTML templates plus a shared stylesheet, `assets/themes/` holds one CSS file per skin, `scripts/` holds the renderers, `vendor/xhs_publish_runtime/` holds the publishing runtime, `references/params.md` documents every flag, and `demos/` holds committed sample output you can compare against. There is a `STYLES.md` at the root as well. The top level also contains `package.json`, `requirements.txt` and `env.example.txt`, so both a Python and a Node install path are expected.

There are no releases published on the repository, and the last push was 2026-08-13, on a project with about 2,300 stars and 266 forks. The MIT license is stated in the README and in `package.json`, though the repository has no separate LICENSE file at the root of the tree.

## Installing it as a Claude Code plugin, a git clone, or a copy

Three install routes are documented and they are genuinely different. The preferred one registers the repository as a plugin marketplace for Claude Code and installs it from there:

```bash
/plugin marketplace add comeonzhj/Auto-Redbook-Skills
/plugin install auto-redbook-skills@comeonzhj-Auto-Redbook-Skills
```

After that, a reload of the plugin list makes the skill available. The second route is the one that generalises beyond Claude Code: tell your Agent to fetch the repository URL and install the skills it contains. The third is a plain clone, which is what you want if you only care about the renderers and do not use a Skills-aware client.

```bash
git clone https://github.com/comeonzhj/Auto-Redbook-Skills.git
cd Auto-Redbook-Skills
```

The README notes the directories that Skills-aware clients read from, for instance `~/.claude/skills/` for Claude and `~/.config/Alma/skills/` for Alma. Dependencies come next, and the project asks for both ecosystems because the Python renderer needs Playwright while the Node side also handles request signing for the publish path.

```bash
pip install -r requirements.txt
playwright install chromium

npm install
npx playwright install chromium
```

Node 18 or newer is required, and the reason given is concrete: it is used for both image rendering and the built-in Xiaohongshu creator request signing.

## Four pagination modes and the problem each one solves

This is the part of the project worth understanding before anything else. A Xiaohongshu note is a fixed aspect ratio, but the text you want to put in it is not a fixed length. Auto-Redbook-Skills offers four ways to resolve that, selected with the `-m` flag.

`separator` is manual: you put `---` in your Markdown and the renderer cuts there. It gives you exact control and no surprises, which is what the default invocation uses. `auto-fit` keeps a fixed 1080 by 1440 canvas and scales the content down until it fits, trading type size for layout. `auto-split` is the one the README recommends, because it measures the rendered height and emits as many cards as the content needs. `dynamic` lets the image height grow up to a ceiling, which suits content that is short enough that slicing would leave a mostly empty final card.

```bash
python scripts/render_xhs.py demos/content.md

python scripts/render_xhs.py demos/content.md -m auto-split

python scripts/render_xhs.py demos/content.md -t playful-geometric -m auto-split
```

The output is a `cover.png` followed by `card_1.png`, `card_2.png` and so on. Sizing is controlled with `--width`, `--height`, `--max-height` and `--dpr`, where the device pixel ratio of 2 is the default that produces the sharp 1080 by 1440 samples committed under `demos/`.

## Eight theme skins are pure CSS over two HTML templates

The rendering architecture is pleasantly simple. There are exactly two templates, `assets/cover.html` for the cover image and `assets/card.html` for body cards, and one shared stylesheet that defines the container structure. The card structure is three nested layers: an outer light grey `card-container`, an inner `card-inner` that carries the theme background, and a `card-content` layer that holds only typography.

Each theme file under `assets/themes/` is scoped to the inner layer, so skins never fight over layout. The README lists eight names: `default`, `playful-geometric`, `neo-brutalism`, `botanical`, `professional`, `retro`, `terminal` and `sketch`. Cover background, title gradient and body card background are matched per theme, which is why the cover and the body read as one set rather than a cover stapled onto unrelated cards. Committed samples exist for `playful-geometric`, `retro`, `Sketch`, `terminal` and `auto-fit`, and the demos directory is the fastest way to judge whether the aesthetic lands.

There is also a second Python renderer, `scripts/render_xhs_v2.py`, described in the tree as offering seven gradient colour styles, and `STYLES.md` at the root. The README's parameter table documents `render_xhs.py` flags such as `-t` and `-m`; `references/params.md` is where the full parameter reference lives.

## A Node renderer exists, but package.json points somewhere else

A Node version of the renderer is documented with roughly the same flags as the Python one:

```bash
node scripts/render_xhs.js demos/content.md

node scripts/render_xhs.js demos/content.md -t terminal -m auto-split
```

Here is the sort of small inconsistency that only shows up when you read the repository rather than the README. The npm manifest declares `"main": "scripts/render_xhs_v2.js"` and a `render` script pointing at the same file, and its `install-browsers` script is `npx playwright install chromium`. The documented Node renderer, however, is `scripts/render_xhs.js`, and the documented Python renderer is `scripts/render_xhs.py`, with `render_xhs_v2.py` sitting alongside it. If you plan to run `npm run render`, check which file is actually present in your checkout first.

The dependency lists are small and readable. `package.json` pins `crypto-js`, `js-yaml`, `marked` and `playwright`, and describes the package as `md2redbook` at version 2.0.0 with keywords for xiaohongshu, markdown, image generation and social media. `requirements.txt` adds `markdown`, `PyYAML`, `playwright`, `PyExecJS`, `curl_cffi` pinned at 0.15.0, `loguru`, `opencv-python`, `numpy`, `python-dotenv` and `requests`. The presence of `curl_cffi`, `opencv-python` and `PyExecJS` is a hint about how the signing step works: it is a pure HTTP path, not a browser driving a page.

## Publishing directly, and the cookie it depends on

Publishing is optional and clearly separated from rendering. You configure a creator cookie first, by copying the example environment file and filling in a value you copied out of your browser's network panel while logged in to the creator platform:

```bash
cp env.example.txt .env
```

The variable is `XHS_CREATOR_COOKIE`. The README's cautions about it are the honest part of this section: do not commit `.env` or share it, and expect publishing to start failing when the cookie expires, which is normal and fixed by capturing it again. It also advises against publishing frequently in a short window so the platform's risk controls do not trigger.

The publish command takes a title, a description and an ordered list of image files, and the ordering matters because the cover has to come first:

```bash
python scripts/publish_xhs.py \
  --title "note title" \
  --desc "note description" \
  --images cover.png card_1.png card_2.png
```

The optional flags cover visibility, scheduled publishing in local time or as a 13 digit millisecond timestamp, topics without the hash character, a location, an HTTP proxy, and `--dry-run`, which validates arguments locally without logging in, uploading or publishing. That last flag is the sensible first thing to try. The README states that the publishing script has a built-in pure HTTP signing, upload and publish chain with no browser automation and no external service dependency, and the acknowledgements credit the Spider_XHS project as the reference for that runtime, which is vendored under `vendor/xhs_publish_runtime/`. The README also opens by pointing to a platform governance announcement about AI-run accounts, which is worth reading before you automate anything at volume.

## Conclusion

This is a rendering tool with a publishing attachment, not an agent that writes for you. Its strongest part is the theme and pagination layer: eight CSS skins and four pagination strategies in `assets/themes/` and `scripts/render_xhs.py`, which solve the real problem of fitting arbitrary note length into a fixed card. The publishing path is narrower, depends on a hand-copied creator cookie that expires without warning, and the README asks you to keep request volume low to avoid platform risk checks, which tells you what kind of service it expects to sit on. Start by rendering `demos/content.md` in the default theme and comparing it to the samples in `demos/`, then decide whether the theme list or the publish script is the part you actually need.

## FAQ

### Does Auto-Redbook-Skills write the note content for you, or do I supply the text?

You supply the text. The rendering scripts take a Markdown file such as `demos/content.md` and turn it into card images, so the writing happens wherever you already draft. The package is packaged as an Agent skill, so an Agent can draft the Markdown for you and then call the renderer, but the code itself is a renderer.

### Which pagination mode should I use for a long note?

`auto-split` is the one the README recommends when content length is unpredictable, because it measures the rendered height and emits as many cards as needed. Use `separator` when you want to control the cuts yourself with `---`, `auto-fit` when the type size can shrink to keep one fixed canvas, and `dynamic` when the note is short enough that slicing would leave a near-empty final card.

### How does the publish step authenticate, and how long does it last?

It authenticates with a `XHS_CREATOR_COOKIE` value that you copy from the request headers of the creator platform while logged in, placed in a `.env` file. The README says an expired cookie makes publishing fail, which is expected, and that you simply capture a new one.

### What are the actual dependencies for rendering images?

Playwright plus a Chromium install, with Markdown parsing from `marked` on the Node side and `markdown` on the Python side. Playwright is what does the actual rendering: the themes are CSS applied to HTML templates, then screenshotted.

## Sources

- [comeonzhj/Auto-Redbook-Skills on GitHub](https://github.com/comeonzhj/Auto-Redbook-Skills)
- [Issues](https://github.com/comeonzhj/Auto-Redbook-Skills/issues)
- [README](https://github.com/comeonzhj/Auto-Redbook-Skills/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/comeonzhj-auto-redbook-skills