Chubby Skills: a Chinese-language content ingestion pipeline for local knowledge bases

The gap Chubby Skills is aimed at: Chinese platforms that never reach your notes

Most capture tools assume the content you care about lives behind a clean RSS feed or an English-language page with stable markup. Chinese platforms do not work that way. Bilibili, Douyin, Xiaohongshu and WeChat public accounts each have their own access quirks, and the README's own comparison table positions Chubby Skills against feedgrab, RSSHub and commercial tools on the specific axis of Chinese platform breadth: it claims 10 platforms, versus 7 for feedgrab and subscription feeds rather than article extraction for RSSHub. Whether that table is fair is a separate question, but the framing tells you who the project is for. It is for people whose daily reading and watching happens on platforms that a generic RSS reader will not touch. The README lists four audiences: content creators building a topic bank from viral notes and videos, learners converting video and podcasts into notes and flashcards, researchers assembling a local corpus an agent can search, and agent users who want skills, CLI, MCP and vault wired into one workflow. The common thread is that the material is Chinese and the destination is a local vault rather than a cloud service.

Three layers, and the JSONL log that holds them together

The project describes itself as three layers. The capture layer converts platform content into unified Markdown. The knowledge layer files that Markdown into an Obsidian or local vault with indexing, search and semantic retrieval. The agent layer exposes the vault through Agent Skills and an MCP server so tools like Claude Code, Codex, OpenCode, OpenClaw and Hermes can read it. The mechanism that makes this more than a folder of scripts is tools/chubby.py. It maintains a queue with status, retries and a daily report, and it writes two things you should understand before trusting it. The first is .chubby/runs.jsonl, one line per source recording status, error, output path and run_id. The second is runs/YYYY-MM-DD.md, a per-day run report. Alongside those, each item carries schema v1 metadata: run_id, source_hash, captured_at, processed_at, content_type and assets. The source_hash is what lets a retry distinguish a genuinely new capture from a re-run of something already processed, and the assets field is what records downloaded images and media. This is a modest design, but it is the difference between a pipeline you can resume after a failure and a script that leaves you guessing which of forty links succeeded.

Subtitle-first transcription and what it costs you when no subtitle exists

The most consequential design choice is the transcription strategy. For Bilibili and YouTube, the documented default is subtitle-first: the skill pulls existing captions via yt-dlp, and only falls back to audio transcription when no subtitle is present. The README states plainly that the heavy dependencies (ffmpeg, funasr, torch, faster-whisper) are needed for video and podcast transcription, not for the light tier. That means a machine with no GPU and no torch installation can still transcribe any video that ships captions, which covers a large share of Bilibili uploads and most YouTube content. The fallback path is where the cost appears. Douyin, TikTok, Weibo and Zhihu list ffmpeg plus funasr as default dependencies with no subtitle-first shortcut documented, so those platforms put you on the heavy tier immediately. Podcasts use ffmpeg plus faster-whisper. If you are targeting Douyin specifically, the light install will not carry you. The README's platform table also lists a per-platform failure fallback, which is worth reading as an admission: when extraction fails, the documented answer is often a local file or a different link form rather than a fix.

Getting it running: quickstart first, then a tiered setup

The documented first move is deliberately offline. After cloning the repository and changing into it, you run python3 tools/chubby.py quickstart. The README is explicit that this does not fetch real platform content. It checks that configuration and run directories are writable, that X link dry-run routing resolves correctly, that sample Markdown conforms to the output protocol, that platform definitions and site templates are complete, that the sample vault can be indexed and semantically searched, and that MCP dependencies are available. Only after that should you install dependencies, and the recommended path is tiered: bash setup.sh for the light tier, setup.sh video, setup.sh podcast, setup.sh wechat or setup.sh all for heavier capabilities, and setup.sh doctor to run an environment check without installing. The README states that the light mode covers X image posts, Xiaohongshu image posts, basic WeChat processing, the industry intelligence radar, knowledge base health checks and content-enrich. For a single link the entry point is python3 tools/chubby_ingest.py with a URL and -o output/, with --skill youtube available when automatic platform detection fails. Enrichment needs DEEPSEEK_API_KEY exported. Vault filing is a flag: --vault ~/Documents/Obsidian/Inbox. Batch work goes through inbox/links.txt, one URL per line, driven by tools/chubby.py.

Cookie dependence, fallback flags and the failure modes the README admits

The honest reading of the platform table is that several skills are one anti-bot change away from breaking. Xiaohongshu image posts are listed as zero-dependency, but the README suggests XHS_COOKIE, and the documented fallback is --fallback-text for manually pasting the body. X ingestion is described as working without an API key, with the same --fallback-text escape hatch and ffmpeg plus funasr needed for video. Weibo's fallback is to prefer a mobile link or a local video. WeChat articles fall back to PDF or saved HTML when extraction fails, and PDF enhancement needs markitdown or pymupdf. The pattern is consistent: the project knows its extractors are brittle and gives you a manual path rather than pretending otherwise. That is a reasonable engineering posture, but it has a practical consequence. If you are ingesting at volume, a silent extraction failure produces a thin Markdown file rather than an error, and you will not notice unless you check .chubby/runs.jsonl or read the daily report. There is also a scope limitation worth stating: the project is Chinese-content-first. Its value proposition is Chinese platform coverage, and an English-first text workflow gains little from the platform-specific skills.

Where it sits against RSSHub and commercial capture tools

The README positions Chubby Skills against RSSHub and against commercial tools like Readwise, ima and NotebookLM. The distinction it draws is real. RSSHub generates feeds for sites that lack them; it is a subscription source, and the README's table marks it as not doing article body extraction. Chubby Skills is the opposite: it does not maintain a feed server, it extracts the body of a specific link you hand it, normalizes it to Markdown with schema v1 metadata, and files it into a vault you own. Against Readwise and NotebookLM the difference is locality and closure. Those products store your highlights in their cloud and expose them through their own interfaces; Chubby Skills writes Markdown files to a directory you choose and exposes them through an MCP server that any compatible agent can query. The trade-off is operational. A hosted product has someone else responsible for extractor breakage. With Chubby Skills, when Xiaohongshu changes its markup, the fix is a pull request or a --fallback-text paste, and the README's contributor tooling (tools/platform_adapter.py for new platform definitions, templates and skill scaffolds) is the project's answer to that.

Maintenance surface, licence and what to verify before adopting

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is a general description of the MIT terms, not legal advice; read the LICENSE file in the repository for the operative text. On maintenance cost, the material supports a few concrete observations. The version is 0.11.0, there are no retrieved releases, and the last push is dated 2026-08-19. The heavy dependency set (torch, funasr, faster-whisper, ffmpeg, yt-dlp) is the part that will demand attention, because yt-dlp in particular requires frequent updates as platforms change. The project ships quality tooling that suggests the maintainer expects this: tools/platform_health.py for platform health, tools/platform_smoke.py with --mode all --check, tools/golden_outputs.py against examples/outputs, and tools/mcp_workflow_demo.py. Running those four commands is the most direct way to learn whether the current extractors still work on your machine, since quickstart deliberately avoids real network capture. What quickstart and the smoke matrix cannot tell you is whether a specific Douyin or Xiaohongshu URL will resolve today. That is the first thing to verify with your own links before you build a workflow around it.

Editorial conclusion

Adopt Chubby Skills if your source material is mostly Chinese-language video, image posts and public accounts, and you already keep notes in a local vault you can point the ingest commands at. Skip it if your content is English-first text, if you need a hosted service with someone else on call, or if you cannot accept that platform extraction depends on cookie values and mobile-link fallbacks that the project itself documents as fragile. Before committing, run python3 tools/chubby.py quickstart to confirm the offline path works on your machine, then run bash setup.sh doctor to see which heavy dependencies are missing, and only after those two pass should you point a real URL at tools/chubby_ingest.py.

Official sources

1. chubbyguan/chubbyskills on GitHub
2. Issues
3. License: MIT
4. README