> For the complete documentation index, see [llms.txt](https://docs.cherryai.com.cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cherryai.com.cn/docs/en-us/contribution/docs.md).
# 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
{% stepper %}
{% step %}
### 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.
{% endstep %}
{% step %}
### 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.
{% endstep %}
{% step %}
### 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].
{% endstep %}
{% step %}
### 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.
{% endstep %}
{% step %}
### 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.
{% endstep %}
{% step %}
### 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.
{% endstep %}
{% endstepper %}
## 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
{% hint style="danger" %}
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.
{% endhint %}
* 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.
{% hint style="success" %}
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.
{% endhint %}
## 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.cherryai.com.cn/docs/en-us/contribution/docs.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.