Kaku Product Docs

Use this skill to write or update the user-facing product documentation on the Kaku website. The site is the deliverable; this skill is the repeatable flow for keeping it correct and adding the next feature without drift.

The audience is normal users, not contributors. Explain what each page/button/shortcut is, how to reach it, and what happens after you use it. Avoid implementation detail. No em dashes, no emoji (project + global rules).

Where things live

• Site worktree: ~/www/kaku-site on the vercel branch (NOT main). Vercel serves kaku.fun by pushing that branch. git worktree list confirms the path.
• Design system: Kami parchment system. Read ~/www/kaku-site/DESIGN.md before any visual change. Match the existing pages; do not invent new components.
• Doc pages (EN under docs/, ZH under zh/docs/, kept in lockstep): Install (index.html), Guide (guide.html), Features (features.html), CLI Reference (cli.html), Configuration (configuration.html), Keybindings (keybindings.html), FAQ (faq.html), Contributing (contributing.html).
• Guide vs Features: Guide is the narrative onboarding walkthrough (first launch → tabs/panes → shell → AI → tools → settings). Features is feature-by-feature reference. Keep the Guide short and link out to the reference pages; do not duplicate config tables there.
• Screenshots: shots/kaku-dark.webp and shots/kaku-light.webp (1920x1192). Reuse them with <figure class="shot">. Kaku is a native terminal, so CDP/browser screenshots do not apply to the app; only capture new app shots if the maintainer explicitly asks (build make app or use /Applications/Kaku.app, then screencapture).

Source of truth: verify, never infer

User-facing docs are public. Do not copy feature claims from a subagent summary or from a feature's name. Confirm each claim against the running code before publishing: