feat(github-copilot-sdk): release v0.10.0 with native prompt restoration and live todo widget

- Restore native Copilot CLI prompts for authentic Plan Mode behavior - Add SQLite-backed session management for state persistence via system prompt - Implement Adaptive Autonomy (Agent chooses planning vs direct execution) - Fix OpenWebUI custom tool context injection for v0.8.x compatibility - Add compact Live TODO widget synchronized with session.db - Upgrade SDK to github-copilot-sdk==0.1.30 - Remove legacy mode switch RPC calls (moved to prompt-driven orchestration) - Fix intent status localization and widget whitespace optimization - Sync bilingual READMEs and all documentation mirrors to v0.10.0
2026-03-07 04:30:15 +08:00
parent 35dec491de
commit f5a983fb4a
44 changed files with 5993 additions and 489 deletions
--- a/.github/gh-aw/review-mirrors/aw-ci-audit.zh.md
+++ b/.github/gh-aw/review-mirrors/aw-ci-audit.zh.md
@@ -0,0 +1,249 @@
+# aw-ci-audit 中文对照
+
+对应源文件：`.github/workflows/aw-ci-audit.md`
+
+用途：这是一份给维护者 review 用的中文对照说明，不是 gh-aw 工作流源文件，也不参与 `gh aw compile`。
+
+## 工作流定位
+
+这个工作流的目标是做“CI / 自动化健康审计”。
+
+它不是日志转储器，也不是自动修复器，而是用于：
+
+- 检查近期仓库自动化是否出现可重复的失败模式
+- 分析 release、publish、stats 等关键工作流的薄弱点
+- 只在有新且可操作的诊断结论时，创建一条维护 issue
+
+如果没有新的可操作诊断，或者问题已经被现有 issue 覆盖，就执行 `noop`。
+
+## Frontmatter 对照
+
+### 触发方式
+
+- `schedule: daily`
+- `workflow_dispatch`
+- `roles: all`
+- `skip-bots`
+  - `github-actions`
+  - `copilot`
+  - `dependabot`
+  - `renovate`
+
+说明：这套设计更适合“定期体检 + 手动补查”，而不是直接绑到不确定的 workflow failure 事件上。
+
+### 权限
+
+当前设计为只读：
+
+- `contents: read`
+- `issues: read`
+- `pull-requests: read`
+- `actions: read`
+
+说明：工作流只做诊断分析，不改代码、不发 release、不创建 PR。
+
+### Safe Outputs
+
+已配置：
+
+- `create-issue`
+  - 标题前缀：`[ci-audit] `
+  - labels：`ci-audit`、`maintenance`
+  - 不自动关闭旧 issue
+
+最终只能二选一：
+
+- 有新且可操作的诊断时执行 `create_issue`
+- 无新问题时执行 `noop`
+
+### 工具
+
+- `github`
+  - `repos`
+  - `issues`
+  - `pull_requests`
+- `bash`
+  - 仅开放只读类命令，如 `pwd`、`ls`、`cat`、`rg`、`git diff`、`git show`
+
+## 正文指令对照
+
+## 主要目标
+
+要求代理审计：
+
+- release 相关 workflow 的失败或波动
+- 插件发布失败
+- 社区统计更新回归
+- 重复出现的 workflow 脆弱点
+- 维护者真正可以执行的下一步动作
+
+明确限制：
+
+- 只做诊断
+- 不改文件
+- 不推代码
+- 不开 PR
+- 不发 release
+
+## 高优先级依据文件
+
+在形成结论前，优先把这些文件当成“自动化规则源”：
+
+- `.github/copilot-instructions.md`
+- `.github/workflows/release.yml`
+- `.github/workflows/publish_plugin.yml`
+- `.github/workflows/publish_new_plugin.yml`
+- `.github/workflows/plugin-version-check.yml`
+- `.github/workflows/community-stats.yml`
+- `docs/development/gh-aw-integration-plan.md`
+- `docs/development/gh-aw-integration-plan.zh.md`
+
+## 重点关注的目标工作流
+
+优先检查：
+
+- `release.yml`
+- `publish_plugin.yml`
+- `publish_new_plugin.yml`
+- `plugin-version-check.yml`
+- `community-stats.yml`
+- `deploy.yml`
+
+如果这些没有明显问题，不要无限扩大范围。
+
+## 审查范围
+
+聚焦“近期失败或可疑自动化信号”，并优先给出基于本仓库结构的诊断，而不是泛泛的 CI 建议。
+
+它应该像“在看仓库自动化健康趋势的维护者”，而不是普通日志摘要机器人。
+
+## 重点检查项
+
+### 1. Release 与 Publish 失败
+
+检查近期失败是否指向这些可操作问题：
+
+- 版本提取或比较逻辑漂移
+- release note 打包缺口
+- publish 脚本的认证或环境问题
+- workflow 中的结构假设已经不匹配当前仓库
+- 如果不改仓库逻辑，就可能持续复现的失败
+
+### 2. Stats 与定时任务稳定性
+
+检查定时维护任务是否出现这些脆弱点：
+
+- community stats 该提交时不再提交
+- badge / docs 生成逻辑过时
+- 依赖外部 API 的任务反复因同类原因失败
+- schedule 驱动任务制造低价值噪音
+
+### 3. 维护者信号质量
+
+只有当结论“真的值得维护者处理”时，才创建 issue。
+
+适合开 issue 的情况：
+
+- 同类失败在多次运行中重复出现
+- workflow 逻辑与当前仓库结构不匹配
+- 大概率缺 secret / 权限 / 路径假设过时
+- 重复出现的低信号失败值得过滤或加固
+
+不要为一次性噪音失败开 issue，除非它很可能复发。
+
+### 4. 已有 Issue 感知
+
+在创建新 issue 前，先判断是否已有 open issue 覆盖同一类 CI 问题。
+
+如果已有 issue 已经足够覆盖，就优先 `noop`，避免制造重复单。
+
+## 严重级别
+
+只允许三档：
+
+- `High`
+  - 高概率重复发生，且会持续影响仓库自动化
+- `Medium`
+  - 建议尽快修，以降低维护成本或 workflow 漂移
+- `Low`
+  - 可选的稳健性增强或清理建议
+
+并且明确要求：
+
+- 不要为了开 issue 而硬造问题
+
+## Issue 格式
+
+如果要创建 issue，必须只有一条维护 issue。
+
+要求：
+
+- 英文
+- 简洁
+- 先写 findings，不写空泛表扬
+- 带可点击路径引用
+- 不用嵌套列表
+- 不要粘贴大段原始日志，除非短摘录确实必要
+
+固定结构：
+
+```markdown
+## CI Audit
+
+### Summary
+Short diagnosis of the failure pattern or automation risk.
+
+### Findings
+- `path/to/file`: specific problem or likely root cause
+
+### Suggested Next Steps
+- concrete maintainer action
+- concrete maintainer action
+
+### Notes
+- Mention whether this appears recurring, new, or already partially mitigated.
+```
+
+补充规则：
+
+- 正常情况下控制在约 300 词以内
+- 如果是相关联的问题，合并成一个 issue，不要拆多个
+- 优先提交“单个可执行诊断”，而不是大杂烩
+
+## No-Issue 规则
+
+如果没有值得报告的新诊断：
+
+- 不要创建状态汇报型 issue
+- 不要复述 workflows 看起来健康
+- 直接走 `noop`
+
+示例：
+
+```json
+{"noop": {"message": "No action needed: reviewed recent repository automation signals and found no new actionable CI diagnosis worth opening as a maintenance issue."}}
+```
+
+## 建议执行流程
+
+1. 检查近期仓库自动化上下文
+2. 优先检查目标工作流
+3. 识别可重复或仓库特定的失败模式
+4. 判断该问题是否已被 open issue 覆盖
+5. 只有在诊断“新且可操作”时，才起草最短有用的维护 issue
+6. 最终只执行一次 `create_issue` 或一次 `noop`
+
+## 额外约束
+
+- 不要为单次低信号瞬时失败开 issue
+- 除非失败模式非常明确，否则不要顺势要求大规模重构
+- 优先给出仓库特定原因，而不是泛泛的“重试试试”
+- 如果根因不确定，要把不确定性写明
+- 如果现有 issue 已经覆盖，优先 `noop` 而不是重复开单
+
+## 最终要求
+
+必须以且仅以一次 safe output 结束：
+
+- 有新且可操作的诊断：`create_issue`
+- 无新问题：`noop`
--- a/.github/gh-aw/review-mirrors/aw-pr-maintainer-review.zh.md
+++ b/.github/gh-aw/review-mirrors/aw-pr-maintainer-review.zh.md
@@ -0,0 +1,268 @@
+# aw-pr-maintainer-review 中文对照
+
+对应源文件：`.github/workflows/aw-pr-maintainer-review.md`
+
+用途：这是一份给维护者 review 用的中文对照说明，不是 gh-aw 工作流源文件，也不参与 `gh aw compile`。
+
+## 工作流定位
+
+这个工作流的目标是对触发 PR 做一次“维护者语义审查”。
+
+它不是通用 code review 机器人，也不是自动修复器，而是用来检查以下问题：
+
+- 是否违反本仓库插件开发规范
+- 是否缺失应同步更新的 README / README_CN / docs 镜像文件
+- 是否存在发布准备层面的遗漏
+- 是否引入明显的高风险行为回归
+
+如果 PR 已经足够合规，没有可操作的维护者反馈，就不评论，而是执行 `noop`。
+
+## Frontmatter 对照
+
+### 触发方式
+
+- `pull_request`
+  - 类型：`opened`、`reopened`、`synchronize`、`ready_for_review`
+  - 路径限制：
+    - `plugins/**`
+    - `docs/**`
+    - `.github/**`
+    - `README.md`
+    - `README_CN.md`
+- `workflow_dispatch`
+- `roles: all`
+- `skip-bots`
+  - `github-actions`
+  - `copilot`
+  - `dependabot`
+  - `renovate`
+
+### 权限
+
+当前设计为只读：
+
+- `contents: read`
+- `issues: read`
+- `pull-requests: read`
+
+说明：工作流不会直接改代码，也不会提交 review comment 之外的写操作。
+
+### Safe Outputs
+
+已配置：
+
+- `add-comment`
+  - 目标：当前触发 PR
+  - 最多 1 条
+  - 隐藏旧评论
+  - 不加 footer
+
+同时要求最终必须二选一：
+
+- 有问题时执行 `add_comment`
+- 无问题时执行 `noop`
+
+### 工具
+
+- `github`
+  - `repos`
+  - `issues`
+  - `pull_requests`
+- `bash`
+  - 仅开放只读类命令，如 `pwd`、`ls`、`cat`、`rg`、`git diff`、`git show`
+
+## 正文指令对照
+
+## 主要目标
+
+要求代理审查：
+
+- 仓库标准合规性
+- 缺失的同步更新文件
+- 发布准备缺口
+- 文档漂移
+- 插件代码中的高风险回归
+
+明确限制：
+
+- 只做 review
+- 不改文件
+- 不推代码
+- 不创建 PR
+
+## 高优先级依据文件
+
+在形成结论前，优先把这些文件当成“本仓库规则源”：
+
+- `.github/copilot-instructions.md`
+- `.github/instructions/code-review.instructions.md`
+- `.github/instructions/commit-message.instructions.md`
+- `.github/skills/release-prep/SKILL.md`
+- `.github/skills/doc-mirror-sync/SKILL.md`
+- `docs/development/gh-aw-integration-plan.md`
+- `docs/development/gh-aw-integration-plan.zh.md`
+
+## 审查范围
+
+- 先看 PR diff 和 changed files
+- 只有在验证一致性时，才扩展读取关联文件
+- 优先遵循“仓库特定规则”，而不是泛泛的最佳实践
+
+换句话说，它应该像“熟悉本仓库的维护者”，而不是通用 lint bot。
+
+## 重点检查项
+
+### 1. 插件代码规范
+
+当 `plugins/**/*.py` 变化时，重点看：
+
+- 是否保持单文件 i18n 模式
+- 用户可见文本是否进入翻译字典
+- 是否使用 `_get_user_context` 和 `_get_chat_context`
+- `__event_call__` 的 JS 执行是否具备 timeout 防护和前端兜底
+- 是否引入 `print()` 到生产插件代码
+- emitter 是否安全判空
+- filter 插件是否把请求级可变状态塞到 `self`
+- Copilot SDK / OpenWebUI tool 定义是否仍符合仓库规范
+
+### 2. 版本与发布卫生
+
+当 `plugins/**/*.py` 改动时，检查是否“应该同步但没同步”：
+
+- 插件 docstring 的 `version:`
+- 插件目录下 `README.md`
+- 插件目录下 `README_CN.md`
+- `docs/plugins/**` 下的镜像页面
+- `docs/plugins/{type}/index.md` 等索引文件
+- 如果是明显 release-prep 类型 PR，再看根 `README.md` 和 `README_CN.md` 日期 badge
+
+这里的关键语义是：
+
+- 不是每个 PR 都必须当发布处理
+- 只有在“用户可见行为、元数据、版本化文档、发布面内容”发生变化时，才提示缺失同步
+
+### 3. 文档同步
+
+当插件 README 改动时，检查是否应同步 docs 镜像：
+
+- `plugins/actions/{name}/README.md` -> `docs/plugins/actions/{name}.md`
+- `plugins/actions/{name}/README_CN.md` -> `docs/plugins/actions/{name}.zh.md`
+- `plugins/filters/{name}/README.md` -> `docs/plugins/filters/{name}.md`
+- `plugins/filters/{name}/README_CN.md` -> `docs/plugins/filters/{name}.zh.md`
+- `plugins/pipes/{name}/README.md` -> `docs/plugins/pipes/{name}.md`
+- `plugins/pipes/{name}/README_CN.md` -> `docs/plugins/pipes/{name}.zh.md`
+- `plugins/pipelines/{name}/README.md` -> `docs/plugins/pipelines/{name}.md`
+- `plugins/pipelines/{name}/README_CN.md` -> `docs/plugins/pipelines/{name}.zh.md`
+- `plugins/tools/{name}/README.md` -> `docs/plugins/tools/{name}.md`
+- `plugins/tools/{name}/README_CN.md` -> `docs/plugins/tools/{name}.zh.md`
+
+如果是 docs-only 且明显有意为之，不要过度报错。
+
+### 4. PR 质量
+
+只在“确实让维护者审查变难”时，才指出 PR 描述缺失这些内容：
+
+- 改了什么
+- 为什么改
+- 是否需要迁移或重新配置
+
+## 严重级别
+
+只允许三档：
+
+- `Blocking`
+  - 大概率 bug、发布回归、缺少必需同步、严重规范破坏
+- `Important`
+  - 应该合并前修，但不一定是直接运行时错误
+- `Minor`
+  - 建议项，可选
+
+并且明确要求：
+
+- 不要为了留言而硬凑问题
+
+## 评论格式
+
+如果要评论，必须只有一条总结评论。
+
+要求：
+
+- 英文
+- 简洁
+- 先给 findings，不先夸赞
+- 带可点击路径引用
+- 不使用嵌套列表
+- 不要机械复述 diff
+
+固定结构：
+
+```markdown
+## PR Maintainer Review
+
+### Blocking
+- `path/to/file`: specific issue and why it matters
+
+### Important
+- `path/to/file`: specific issue and what sync/check is missing
+
+### Minor
+- `path/to/file`: optional improvement or consistency note
+
+### Merge Readiness
+- Ready after the items above are addressed.
+```
+
+补充规则：
+
+- 空 section 要省略
+- 如果只有一个严重级别，只保留那个 section 和 `Merge Readiness`
+- 正常情况下控制在约 250 词以内
+
+## No-Comment 规则
+
+如果没有有意义的维护者反馈：
+
+- 不要发“看起来不错”这类表扬评论
+- 不要复述 checks passed
+- 直接走 `noop`
+
+示例：
+
+```json
+{"noop": {"message": "No action needed: reviewed the PR diff and repository sync expectations, and found no actionable maintainer feedback."}}
+```
+
+## 建议执行流程
+
+1. 找出变更文件
+2. 读取高优先级规则文件
+3. 对照插件审查规范检查插件代码
+4. 对照 doc mirror 规则检查 README / docs
+5. 判断是否缺失 version sync 或 release-facing 文件
+6. 先起草最短但有用的维护者总结
+7. 最终只执行一次 `add_comment` 或一次 `noop`
+
+## 额外约束
+
+- 不要要求与本 PR 无关的大重构
+- 小型内部变更不要强拉成 release-prep
+- 明显是私有/内部改动时，不要强制要求 docs sync
+- 优先给出“仓库特定”的反馈，而不是通用 code review 废话
+- 如果你不确定某个同步文件是否必需，把级别降为 `Important`
+- 如果问题依赖 PR 意图但当前信息不足，要把表述写成“条件性判断”，不要装作确定
+
+## 最终要求
+
+必须以且仅以一次 safe output 结束：
+
+- 有可操作反馈：`add_comment`
+- 无可操作反馈：`noop`
+
+## Review 结论
+
+这份英文源工作流目前已经可以作为后续 `gh aw compile` 的候选源文件。
+
+中文镜像的目的只有两个：
+
+- 方便你逐段审阅策略是否符合预期
+- 避免把中文说明混进真正要编译的 workflow 源文件
--- a/.github/gh-aw/review-mirrors/aw-release-preflight.zh.md
+++ b/.github/gh-aw/review-mirrors/aw-release-preflight.zh.md
@@ -0,0 +1,275 @@
+# aw-release-preflight 中文对照
+
+对应源文件：`.github/workflows/aw-release-preflight.md`
+
+用途：这是一份给维护者 review 用的中文对照说明，不是 gh-aw 工作流源文件，也不参与 `gh aw compile`。
+
+## 工作流定位
+
+这个工作流的目标是对触发变更做一次“发布前预检语义审查”。
+
+它不是发布执行器，也不是自动补版本工具，而是用于判断：
+
+- 这次改动是否真的在做 release-prep
+- 如果是在做 release-prep，版本同步是否完整
+- 双语 README、docs 镜像、release notes 是否齐全
+- 是否存在会影响发布质量的说明缺失或文档漂移
+
+如果当前变更并不是发布准备，或者已经足够一致、没有可操作反馈，就执行 `noop`。
+
+## Frontmatter 对照
+
+### 触发方式
+
+- `pull_request`
+  - 类型：`opened`、`reopened`、`synchronize`、`ready_for_review`
+  - 路径限制：
+    - `plugins/**/*.py`
+    - `plugins/**/README.md`
+    - `plugins/**/README_CN.md`
+    - `plugins/**/v*.md`
+    - `plugins/**/v*_CN.md`
+    - `docs/plugins/**/*.md`
+    - `README.md`
+    - `README_CN.md`
+    - `.github/**`
+- `workflow_dispatch`
+- `roles: all`
+- `skip-bots`
+  - `github-actions`
+  - `copilot`
+  - `dependabot`
+  - `renovate`
+
+### 权限
+
+当前设计为只读：
+
+- `contents: read`
+- `issues: read`
+- `pull-requests: read`
+
+说明：工作流不会发 release、不会推代码、不会改文件。
+
+### Safe Outputs
+
+已配置：
+
+- `add-comment`
+  - 目标：当前触发 PR
+  - 最多 1 条
+  - 隐藏旧评论
+  - 不加 footer
+
+最终只能二选一：
+
+- 有问题时执行 `add_comment`
+- 无问题时执行 `noop`
+
+### 工具
+
+- `github`
+  - `repos`
+  - `issues`
+  - `pull_requests`
+- `bash`
+  - 仅开放只读类命令，如 `pwd`、`ls`、`cat`、`rg`、`git diff`、`git show`
+
+## 正文指令对照
+
+## 主要目标
+
+要求代理检查：
+
+- 版本同步完整性
+- 双语 README 与 docs 一致性
+- release notes 完整性
+- 发布面索引或 badge 漂移
+- 用户可见发布是否缺失迁移说明或维护者上下文
+
+明确限制：
+
+- 只做 review
+- 不改文件
+- 不推代码
+- 不创建 release
+- 不创建 PR
+
+## 高优先级依据文件
+
+在形成结论前，优先把这些文件当成“发布规则源”：
+
+- `.github/copilot-instructions.md`
+- `.github/instructions/commit-message.instructions.md`
+- `.github/skills/release-prep/SKILL.md`
+- `.github/skills/doc-mirror-sync/SKILL.md`
+- `.github/workflows/release.yml`
+- `docs/development/gh-aw-integration-plan.md`
+- `docs/development/gh-aw-integration-plan.zh.md`
+
+## 审查范围
+
+- 从 PR diff 和 changed files 开始
+- 只有在验证发布同步时才扩展到相关 release-facing 文件
+- 优先遵循仓库既有 release-prep 规则，而不是泛泛的 release 建议
+
+换句话说，它应该像“合并前最后做一致性复核的维护者”。
+
+## 重点检查项
+
+### 1. 发布相关文件中的版本同步
+
+当某个插件明显在准备发版时，检查这些位置是否同步：
+
+- 插件 Python docstring 的 `version:`
+- 插件目录下 `README.md`
+- 插件目录下 `README_CN.md`
+- `docs/plugins/**` 英文镜像页
+- `docs/plugins/**/*.zh.md` 中文镜像页
+- `docs/plugins/{type}/index.md` 中该插件的条目或版本 badge
+- `docs/plugins/{type}/index.zh.md` 中该插件的条目或版本 badge
+
+但只有在“这次改动明显带有发布意图”时才提示，不要把所有 PR 都按发布处理。
+
+### 2. README 与 docs 镜像一致性
+
+当插件 README 变化时，检查 docs 镜像是否同步。
+
+路径映射：
+
+- `plugins/actions/{name}/README.md` -> `docs/plugins/actions/{name}.md`
+- `plugins/actions/{name}/README_CN.md` -> `docs/plugins/actions/{name}.zh.md`
+- `plugins/filters/{name}/README.md` -> `docs/plugins/filters/{name}.md`
+- `plugins/filters/{name}/README_CN.md` -> `docs/plugins/filters/{name}.zh.md`
+- `plugins/pipes/{name}/README.md` -> `docs/plugins/pipes/{name}.md`
+- `plugins/pipes/{name}/README_CN.md` -> `docs/plugins/pipes/{name}.zh.md`
+- `plugins/pipelines/{name}/README.md` -> `docs/plugins/pipelines/{name}.md`
+- `plugins/pipelines/{name}/README_CN.md` -> `docs/plugins/pipelines/{name}.zh.md`
+- `plugins/tools/{name}/README.md` -> `docs/plugins/tools/{name}.md`
+- `plugins/tools/{name}/README_CN.md` -> `docs/plugins/tools/{name}.zh.md`
+
+如果是纯文档调整、而且并非发版预备，不要过度报错。
+
+### 3. What's New 与 Release Notes 覆盖度
+
+当这次更新明显是发布面插件更新时，检查：
+
+- `What's New` 是否只反映最新版本
+- `最新更新` 是否与英文对应
+- 是否存在 `v{version}.md` 和 `v{version}_CN.md`
+- release notes 是否覆盖当前 diff 中有意义的功能、修复、文档或迁移变化
+
+对纯内部小改动，不要强制要求 release notes。
+
+### 4. 根 README 与发布面索引漂移
+
+当改动明显面向正式发布时，再检查：
+
+- 根 `README.md` 的日期 badge
+- 根 `README_CN.md` 的日期 badge
+- `docs/plugins/**/index.md`
+- `docs/plugins/**/index.zh.md`
+
+不要把这种检查强加给普通内部 PR。
+
+### 5. 维护者上下文与发布清晰度
+
+检查 PR 描述或发布面文案是否缺少关键上下文：
+
+- 这次到底发布了什么
+- 为什么这次发布值得做
+- 是否需要迁移或重新配置
+
+只有在缺失信息会明显增加 release review 成本时，才提示。
+
+## 严重级别
+
+只允许三档：
+
+- `Blocking`
+  - 高概率发布回归、缺少必要版本同步、发布面更新明显不完整
+- `Important`
+  - 合并前最好修，避免发布混乱或文档漂移
+- `Minor`
+  - 可选的发布面清理或一致性建议
+
+并且明确要求：
+
+- 不要为了留言而造问题
+
+## 评论格式
+
+如果要评论，必须只有一条总结评论。
+
+要求：
+
+- 英文
+- 简洁
+- 先给 findings，不先夸赞
+- 带可点击路径引用
+- 不使用嵌套列表
+- 不要机械复述 diff
+
+固定结构：
+
+```markdown
+## Release Preflight Review
+
+### Blocking
+- `path/to/file`: specific release-facing problem and why it matters
+
+### Important
+- `path/to/file`: missing sync or release-documentation gap
+
+### Minor
+- `path/to/file`: optional cleanup or consistency improvement
+
+### Release Readiness
+- Ready after the items above are addressed.
+```
+
+补充规则：
+
+- 空 section 要省略
+- 如果只有一个严重级别，只保留那个 section 和 `Release Readiness`
+- 正常情况下控制在约 250 词以内
+
+## No-Comment 规则
+
+如果没有有意义的发布前预检反馈：
+
+- 不要发“看起来不错”这类表扬评论
+- 不要复述 checks passed
+- 直接走 `noop`
+
+示例：
+
+```json
+{"noop": {"message": "No action needed: reviewed the release-facing diff, version-sync expectations, and bilingual documentation coverage, and found no actionable preflight feedback."}}
+```
+
+## 建议执行流程
+
+1. 判断这次改动是否真的带有发布意图
+2. 检查 PR diff 中的变更文件
+3. 读取仓库的 release-prep 规则文件
+4. 只有在存在发布意图时，才检查 plugin version sync
+5. 检查 README、README_CN、docs 镜像、索引和 release notes 是否漂移
+6. 起草最短但有用的维护者总结
+7. 最终只执行一次 `add_comment` 或一次 `noop`
+
+## 额外约束
+
+- 不要把完整 release-prep 要求硬套到微小内部改动上
+- 非明确发布型 PR，不要强制要求根 README 日期 badge 更新
+- 如果这次改动并不现实地构成发版预备，就不要强求 release notes
+- 优先给出仓库特定的同步反馈，而不是泛泛的发布建议
+- 如果不确定某个 release-facing 同步文件是否必需，把级别降为 `Important`
+- 如果问题依赖“推测出来的意图”，要用条件式表述，不要装作确定
+
+## 最终要求
+
+必须以且仅以一次 safe output 结束：
+
+- 有可操作反馈：`add_comment`
+- 无可操作反馈：`noop`