Contribute documentation

Document contributions include fixing incorrect paths, adding tutorials for new features, improving screenshots and examples, adjusting the table of contents, and translating. The goal is not to “write more,” but to make it possible for readers to complete tasks by following the page steps.

Document contributions should also stay narrowly scoped; submit the Change Request after the preview passes.

Choose a submission method

• If you already have GitBook editing permission: create a Change Request in the corresponding language space;
• If you do not have editing permission: open Cherry Studio and go to [Settings] → [About Us] → [Feedback], then explain the page URL, the issue, and your suggestion;
• If the documentation issue is related to a code change: check the documentation item in the code PR and attach the corresponding Change Request, or note that no update is needed.

GitBook modification process

1

1. Create a Change Request

Enter the correct language space and create a draft; do not edit published content directly. Make the title clearly state the module involved and the purpose.

2

2. Check the current product first

Use the current Cherry Studio interface to verify the entry points, buttons, default values, and expected results. If the old page structure does not match the current product, reorganize the table of contents instead of just replacing a few terms.

3

3. Write pages according to user tasks

Start by explaining what can be accomplished, then provide the exact path, numbered steps, expected results, configuration instructions, real examples, and common questions. For configuration tutorials, you can first guide users to let the Agent assist in [Work], then provide the manual path in [Settings].

4

4. Use GitBook native content blocks

Use Callout for tips, Stepper for consecutive actions, collapsible blocks for common questions, and Cards for related pages. Do not leave {% hint %}HTML tags or Markdown markers as plain text on the page.

5

5. Add real screenshots

Screenshots should come from the current product interface, use Simplified Chinese, a light theme, and consistent sizing. Only mark the locations the reader needs to click or observe, and hide API keys, email addresses, local paths, and user data.

6

6. Preview and submit for review

Check each page for titles, navigation, links, images, Callouts, Steppers, tables, and collapsible blocks. After confirming the draft has no unrelated page changes, submit it for review and have it merged by a maintainer.

Page writing requirements

Content	Requirements
Action path	Use names visible in the interface, for example [Work] → [Add Agent]
Terminology	Explain the Chinese meaning and function the first time it appears
Parameters	Distinguish the product default value from the recommended starting point, and explain the purpose and risks
Examples	Use specific roles, goals, inputs, and results
Screenshots	Taken from the real interface, with alt text and numbered annotations
Link	Point to the current page or official source, and open each one before submitting

Screenshot notes

Do not fabricate successful results just to make things “look complete.” For features that require an external API key, a paid service, or a real account, you may show the configuration entry and prerequisites, but you must not invent a successful connection, message delivery, or model output.

• Capture the app content area without relying on the window decorations of any particular system;
• The numbering in the image should correspond one-to-one with the explanations in the text;
• One image should serve one main task; avoid filling the screen with annotations;
• Keep the key steps on the same page; do not take a screenshot for every ordinary click;
• After uploading, confirm in Preview that the image is actually displayed, not just the file name or placeholder text.

Reader validation

Ask someone who did not participate in the writing to complete one operation using only the tutorial. Record where they got stuck, which term they did not understand, and which image was unhelpful, then revise it. Passing a grammar check does not mean readers can actually complete the task by following it.

The ideal result of a one-page tutorial is: the reader knows when to use it, where to start, what they will see at each step, what to check first if something fails, and how to confirm the result after finishing.

Self-checklist

• There are no old entry points, old names, or outdated features;
• There are no hard-coded unstable model rankings, prices, or “best configuration” claims;
• There are no version numbers, verification dates, or internal implementation paths that interrupt reading;
• Interface names use [ ] consistently;
• The text reads like a product editor writing for users, not like a generated report;
• Each step can find the corresponding entry point from the current interface;
• Images, links, and GitBook native content blocks render correctly in Preview.

Can I directly edit a published page?

No. Use a Change Request to keep the scope of changes and the review process, and have someone with permission merge it after confirming it is correct.