docs: suggest a short PR opener with the long description folded

AGENTS.md

@@ -26,6 +26,13 @@ package at `plugins/<github-username>/<plugin-id>/`; the rest change the checks
 4. Add one row to the table in both root READMEs.
 5. Run `npm run check`. Done when it reports no errors and every warning is either fixed or
    explained in the PR description.
+6. Open the PR with a short opener: one to three sentences on what changed and why, plus a
+   screenshot when the page looks different. Keep these visible below it: the tested environment
+   and results, what you did not verify, each remaining `npm run check` warning with its reason,
+   and any new access or higher minimum client version. Put the rest of a long description inside
+   `<details><summary>Written by <model></summary> … </details>`, with a blank line after
+   `</summary>`; without it GitHub shows the Markdown inside as plain text. Ask the person you work
+   for to read and edit the opener before you submit.
 
 ## Hard rules
 
@@ -90,6 +97,8 @@ suggestion.
 - CI validates every package under `plugins/`. A new error must leave existing packages at zero
   errors; otherwise ship it as a warning first.
 - Keep contract changes in their own PR, apart from package updates.
+- Describe the PR as in step 6 of "Add or update a Mini App": a short opener, what was and was
+  not verified in view, the rest folded.
 
 ## Navigation
 

CONTRIBUTING.md

@@ -14,6 +14,6 @@ The plugin directory name must match `name` in `.minimax-plugin/plugin.json`. **
 
 Submit ready-to-run files. If the app requires a build step, include its source and build instructions. Do not commit `node_modules/`, credentials, real session records, personal data, or runtime caches. Use synthetic or thoroughly anonymized data in screenshots and examples.
 
-Before submitting, install the app in MiniMax Code, open it, and check its main features. Include your test environment and results in the pull request, and state any unverified behavior. When updating an existing app, keep its plugin ID and update the version and usage instructions as appropriate.
+Before submitting, install the app in MiniMax Code, open it, and check its main features. Include your test environment and results in the pull request, and state any unverified behavior. If an AI agent wrote the description, write its first one to three sentences yourself, keep the test results and unverified behavior visible, and fold the rest into `<details><summary>…</summary> … </details>`, leaving a blank line after `</summary>` so the Markdown inside still renders. When updating an existing app, keep its plugin ID and update the version and usage instructions as appropriate.
 
 Working with an AI coding agent? It reads `AGENTS.md` automatically; `docs/` holds the same rules for people.

CONTRIBUTING.zh-CN.md

@@ -14,6 +14,6 @@
 
 提交可直接运行的文件；如果需要构建，附上源码和构建说明。不要提交 `node_modules/`、密钥、真实会话记录、个人数据或运行缓存。截图和示例请使用合成数据或充分脱敏的数据。
 
-提交前在 MiniMax Code 中手动安装、打开并检查主要功能，在 PR 中写明测试环境和结果；未验证的部分如实说明。更新已有作品时，保留插件 ID，并按改动更新版本与使用说明。
+提交前在 MiniMax Code 中手动安装、打开并检查主要功能，在 PR 中写明测试环境和结果；未验证的部分如实说明。如果 PR 描述是 AI 写的，请自己写开头一到三句，测试结果和未验证的部分保持可见，其余内容放进 `<details><summary>…</summary> … </details>` 折叠起来；`</summary>` 后要空一行，否则里面的 Markdown 不会渲染。更新已有作品时，保留插件 ID，并按改动更新版本与使用说明。
 
 使用 AI 编码助手时，它会自动读取 `AGENTS.md`；`docs/` 里是同一套规则的人类可读版本。