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
This commit is contained in:
fujie
5
.github/agents/plugin-implementer.agent.md
vendored
5
.github/agents/plugin-implementer.agent.md
vendored
@@ -56,6 +56,11 @@ When bumping, update ALL 7+ files (code docstring + 2× README + 2× doc detail
|
||||
- Never run `git commit`, `git push`, or create PRs automatically.
|
||||
- After all edits, list what changed and why, then stop.
|
||||
|
||||
## Knowledge Capture (Mandatory)
|
||||
Before ending the session, if you discovered any non-obvious internal API behaviour,
|
||||
parameter injection quirk, or workaround, save it to `.agent/learnings/{topic}.md`.
|
||||
Also browse `.agent/learnings/` at the start to reuse existing knowledge.
|
||||
|
||||
## Completion Output
|
||||
- Modified files (full relative paths, one-line descriptions)
|
||||
- Remaining manual checks
|
||||
|
||||
1
.github/agents/plugin-planner.agent.md
vendored
1
.github/agents/plugin-planner.agent.md
vendored
@@ -22,6 +22,7 @@ You are the **planning specialist** for the `openwebui-extensions` repository.
|
||||
- Never propose `git commit`, `git push`, or PR creation.
|
||||
- Every plan must end with an acceptance checklist for the user to approve before handing off.
|
||||
- Reference `.github/copilot-instructions.md` as the authoritative spec.
|
||||
- Browse `.agent/learnings/` **first** to reuse existing knowledge before researching anything.
|
||||
|
||||
## Repository Plugin Inventory
|
||||
|
||||
|
||||
4
.github/agents/plugin-reviewer.agent.md
vendored
4
.github/agents/plugin-reviewer.agent.md
vendored
@@ -54,6 +54,9 @@ Full review rules are in .github/instructions/code-review.instructions.md.
|
||||
- [ ] `docs/plugins/{type}/index.md` and `.zh.md` version badges updated.
|
||||
- [ ] Root `README.md` / `README_CN.md` date badge updated.
|
||||
|
||||
**8. Knowledge Capture**
|
||||
- [ ] Any non-obvious findings (API contracts, injection quirks, gotchas) documented in `.agent/learnings/{topic}.md`.
|
||||
|
||||
### 🟡 Non-blocking (suggestions)
|
||||
- Copilot SDK tools: `params_type=MyParams` in `define_tool()`.
|
||||
- Long tasks (>3s): periodic `_emit_notification("info")` every 5s.
|
||||
@@ -68,4 +71,5 @@ Full review rules are in .github/instructions/code-review.instructions.md.
|
||||
- **Blocking issues** (file:line references)
|
||||
- **Non-blocking suggestions**
|
||||
- **Pass / Fail verdict**
|
||||
- **Knowledge captured?** (`.agent/learnings/` updated if any discoveries were made)
|
||||
- **Next step**: Pass → handoff to Release Prep; Fail → return to Implementer with fix list
|
||||
|
||||
25
.github/copilot-instructions.md
vendored
25
.github/copilot-instructions.md
vendored
@@ -32,6 +32,15 @@ plugins/actions/export_to_docx/
|
||||
- `README.md` - English documentation
|
||||
- `README_CN.md` - 中文文档
|
||||
|
||||
#### 文档交付与审阅 (Documentation Delivery for Review)
|
||||
|
||||
当任务涉及文档类内容时，例如 README、Guide、Post、Release Notes、Announcement、Development Docs：
|
||||
|
||||
- **必须**同时提供英文版与中文版，方便审阅与校对。
|
||||
- 若仓库最终只提交英文文件，也**必须**在对话中额外提供中文版草稿给维护者 review。
|
||||
- 若用户未明确指定只保留单语文件，默认按双语交付处理。
|
||||
- 中文版的目标是**便于审阅**，应忠实对应英文原意，可在表达上自然调整，但不得遗漏风险、限制、步骤或结论。
|
||||
|
||||
#### README 结构规范 (README Structure Standard)
|
||||
|
||||
所有插件 README 必须遵循以下统一结构顺序：
|
||||
@@ -1151,6 +1160,7 @@ Filter 实例是**单例 (Singleton)**。
|
||||
- [ ] **README 结构**:
|
||||
- **Key Capabilities** (英文) / **核心功能** (中文): 必须包含所有核心功能
|
||||
- **What's New** (英文) / **最新更新** (中文): 仅包含最新版本的变更信息
|
||||
- [ ] **知识沉淀**: 开发过程中发现的非显而易见的规律、踩坑或内部 API 合约，必须记录到 `.agent/learnings/{topic}.md`
|
||||
|
||||
### 2. 🔄 一致性维护 (Consistency Maintenance)
|
||||
|
||||
@@ -1208,6 +1218,21 @@ Filter 实例是**单例 (Singleton)**。
|
||||
|
||||
使用 `@all-contributors please add @username for <type>` 指令。
|
||||
|
||||
### 6. 📖 知识沉淀 Knowledge Capture (Mandatory)
|
||||
|
||||
任何开发会话中发现的**非显而易见**的内部 API 行为、参数注入机制、Mock 对象要求或其他踩坑经验，
|
||||
**必须**在会话结束前记录到 `.agent/learnings/{topic}.md`。
|
||||
|
||||
- **开始前**: 先浏览 `.agent/learnings/` 确认是否存在相关先验知识，避免重复调研。
|
||||
- **格式规范**: 参见 `.agent/learnings/README.md`。
|
||||
- **现有条目**: 见 `.agent/learnings/` 目录。
|
||||
|
||||
典型需要记录的内容：
|
||||
- OpenWebUI 内部函数的参数注入机制
|
||||
- Pipe 调用 Tool 时必须提供的上下文字段
|
||||
- Mock Request 对象所需满足的接口契约
|
||||
- 模型 ID 在不同上下文中的解析规则
|
||||
|
||||
---
|
||||
|
||||
## 📚 参考资源 (Reference Resources)
|
||||
|
||||
21
.github/gh-aw/README.md
vendored
Normal file
21
.github/gh-aw/README.md
vendored
Normal file
@@ -0,0 +1,21 @@
|
||||
# gh-aw Support Files
|
||||
|
||||
This directory stores repository-local support files for GitHub Agentic Workflows.
|
||||
|
||||
## Purpose
|
||||
|
||||
Keep review aids, policy notes, and human-facing mirrors out of `.github/workflows/` so only real gh-aw source workflows live there.
|
||||
|
||||
## Structure
|
||||
|
||||
- `review-mirrors/`: Chinese review mirrors and maintainer-facing explanations for workflow source files.
|
||||
|
||||
## Current Files
|
||||
|
||||
- `review-mirrors/aw-pr-maintainer-review.zh.md`: Chinese review mirror for `.github/workflows/aw-pr-maintainer-review.md`.
|
||||
- `review-mirrors/aw-release-preflight.zh.md`: Chinese review mirror for `.github/workflows/aw-release-preflight.md`.
|
||||
- `review-mirrors/aw-ci-audit.zh.md`: Chinese review mirror for `.github/workflows/aw-ci-audit.md`.
|
||||
|
||||
## Rule
|
||||
|
||||
Files in this directory are for maintainer review and documentation only. They are not gh-aw workflow source files and should not be compiled.
|
||||
249
.github/gh-aw/review-mirrors/aw-ci-audit.zh.md
vendored
Normal file
249
.github/gh-aw/review-mirrors/aw-ci-audit.zh.md
vendored
Normal file
@@ -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`
|
||||
268
.github/gh-aw/review-mirrors/aw-pr-maintainer-review.zh.md
vendored
Normal file
268
.github/gh-aw/review-mirrors/aw-pr-maintainer-review.zh.md
vendored
Normal file
@@ -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 源文件
|
||||
275
.github/gh-aw/review-mirrors/aw-release-preflight.zh.md
vendored
Normal file
275
.github/gh-aw/review-mirrors/aw-release-preflight.zh.md
vendored
Normal file
@@ -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`
|
||||
222
.github/workflows/aw-ci-audit.md
vendored
Normal file
222
.github/workflows/aw-ci-audit.md
vendored
Normal file
@@ -0,0 +1,222 @@
|
||||
---
|
||||
description: "CI audit workflow for failed releases, publish jobs, stats updates, and other important repository automation"
|
||||
private: true
|
||||
labels: [automation, diagnostics, ci, gh-aw]
|
||||
metadata:
|
||||
author: Fu-Jie
|
||||
category: maintenance
|
||||
maturity: draft
|
||||
on:
|
||||
schedule: daily
|
||||
workflow_dispatch:
|
||||
roles: all
|
||||
skip-bots: [github-actions, copilot, dependabot, renovate]
|
||||
permissions:
|
||||
contents: read
|
||||
issues: read
|
||||
pull-requests: read
|
||||
actions: read
|
||||
engine: copilot
|
||||
network:
|
||||
allowed:
|
||||
- defaults
|
||||
safe-outputs:
|
||||
create-issue:
|
||||
title-prefix: "[ci-audit] "
|
||||
labels: [ci-audit, maintenance]
|
||||
close-older-issues: false
|
||||
allowed-github-references: [repo]
|
||||
timeout-minutes: 15
|
||||
tools:
|
||||
github:
|
||||
toolsets: [repos, issues, pull_requests]
|
||||
bash:
|
||||
- pwd
|
||||
- ls
|
||||
- cat
|
||||
- head
|
||||
- tail
|
||||
- grep
|
||||
- wc
|
||||
- rg
|
||||
- git status
|
||||
- git diff
|
||||
- git show
|
||||
- git ls-files
|
||||
---
|
||||
|
||||
# CI Audit
|
||||
|
||||
You are the repository maintainer assistant for `Fu-Jie/openwebui-extensions`.
|
||||
|
||||
Your job is to inspect recent repository automation health and create **one concise maintenance issue only when there is actionable CI or automation feedback**.
|
||||
|
||||
If there is no meaningful failure pattern, no new actionable diagnosis, or no useful maintainer issue to open, you **must call `noop`** with a short explanation.
|
||||
|
||||
## Primary Goal
|
||||
|
||||
Audit recent automation health for:
|
||||
|
||||
- failed or flaky release-related workflows
|
||||
- plugin publishing failures
|
||||
- community stats update regressions
|
||||
- repeated workflow drift or fragile maintenance steps
|
||||
- repository-specific next steps maintainers can actually act on
|
||||
|
||||
This workflow is **diagnostic-only**. Do not modify files, push code, open pull requests, or create releases.
|
||||
|
||||
## High-Priority Source Files
|
||||
|
||||
Use these files as the authoritative context before forming conclusions:
|
||||
|
||||
- `.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`
|
||||
|
||||
## Target Workflows
|
||||
|
||||
Prioritize these workflows first:
|
||||
|
||||
- `release.yml`
|
||||
- `publish_plugin.yml`
|
||||
- `publish_new_plugin.yml`
|
||||
- `plugin-version-check.yml`
|
||||
- `community-stats.yml`
|
||||
- `deploy.yml`
|
||||
|
||||
If there are no meaningful issues there, do not widen scope unnecessarily.
|
||||
|
||||
## Review Scope
|
||||
|
||||
Focus on recent failed or suspicious automation runs and repository-facing symptoms. Prefer diagnosis that is grounded in repository context, not generic CI advice.
|
||||
|
||||
This workflow should behave like a maintainer who is reviewing workflow health trends, not like a generic log summarizer.
|
||||
|
||||
Focus especially on these areas:
|
||||
|
||||
### 1. Release and Publish Failures
|
||||
|
||||
Inspect whether recent failures suggest actionable problems such as:
|
||||
|
||||
- version extraction or comparison drift
|
||||
- release-note packaging gaps
|
||||
- publish-script authentication or environment issues
|
||||
- assumptions in release jobs that no longer match repository structure
|
||||
- failures that are likely to recur until repository logic changes
|
||||
|
||||
### 2. Stats and Scheduled Workflow Reliability
|
||||
|
||||
Inspect whether scheduled maintenance jobs show drift or fragility such as:
|
||||
|
||||
- community stats commits no longer happening when expected
|
||||
- badge or docs generation assumptions becoming stale
|
||||
- external API dependent jobs failing in repeatable ways
|
||||
- schedule-driven jobs causing noisy or low-value churn
|
||||
|
||||
### 3. Signal Quality for Maintainers
|
||||
|
||||
Only create an issue if there is a useful diagnosis with at least one concrete next step.
|
||||
|
||||
Good issue-worthy findings include:
|
||||
|
||||
- a repeated failure signature across runs
|
||||
- a repository mismatch between workflow logic and current file layout
|
||||
- a likely missing secret, missing permission, or stale path assumption
|
||||
- repeated low-signal failures that should be filtered or hardened
|
||||
|
||||
Do not open issues for one-off noise unless the failure pattern is likely to recur.
|
||||
|
||||
### 4. Existing Issue Awareness
|
||||
|
||||
Before creating a new issue, check whether a recent open issue already appears to cover the same CI failure pattern.
|
||||
|
||||
If an existing issue already covers the problem well enough, prefer `noop` and mention that the diagnosis is already tracked.
|
||||
|
||||
## Severity Model
|
||||
|
||||
Use three levels only:
|
||||
|
||||
- `High`: likely recurring CI or automation failure with repository impact
|
||||
- `Medium`: useful to fix soon to reduce maintenance burden or workflow drift
|
||||
- `Low`: optional hardening or cleanup suggestion
|
||||
|
||||
Do not invent issues just to create a report.
|
||||
|
||||
## Issue Creation Rules
|
||||
|
||||
Create **one maintenance issue** only if there is actionable new diagnosis.
|
||||
|
||||
The issue must:
|
||||
|
||||
- be in English
|
||||
- be concise and maintainer-like
|
||||
- lead with findings, not generic praise
|
||||
- include clickable file references like ``.github/workflows/release.yml`` or ``scripts/publish_plugin.py``
|
||||
- avoid nested bullets
|
||||
- avoid pasting raw logs unless a short excerpt is critical
|
||||
|
||||
Use this exact structure when creating the issue:
|
||||
|
||||
```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.
|
||||
```
|
||||
|
||||
Rules:
|
||||
|
||||
- Keep the issue under about 300 words unless multiple workflows are affected.
|
||||
- If there are multiple related findings, group them into one issue rather than opening separate issues.
|
||||
- Prefer a single, actionable diagnosis over a broad laundry list.
|
||||
|
||||
## No-Issue Rule
|
||||
|
||||
If there is no meaningful new diagnosis to report:
|
||||
|
||||
- do not create a status-only issue
|
||||
- do not restate that workflows look healthy
|
||||
- call `noop` with a short explanation like:
|
||||
|
||||
```json
|
||||
{"noop": {"message": "No action needed: reviewed recent repository automation signals and found no new actionable CI diagnosis worth opening as a maintenance issue."}}
|
||||
```
|
||||
|
||||
## Suggested Audit Process
|
||||
|
||||
1. Inspect recent repository automation context.
|
||||
2. Prioritize the target workflows listed above.
|
||||
3. Identify recurring or repository-specific failure patterns.
|
||||
4. Check whether the problem is already tracked in an open issue.
|
||||
5. Draft the shortest useful maintenance issue only if the diagnosis is actionable and new.
|
||||
6. Finish with exactly one `create_issue` or one `noop`.
|
||||
|
||||
## Important Constraints
|
||||
|
||||
- Do not create an issue for a single low-signal transient failure.
|
||||
- Do not propose large refactors unless the failure pattern clearly justifies them.
|
||||
- Prefer repository-specific causes over generic "retry later" style advice.
|
||||
- If the likely root cause is uncertain, state the uncertainty explicitly.
|
||||
- If the pattern appears already tracked, prefer `noop` over duplicate issue creation.
|
||||
|
||||
## Final Requirement
|
||||
|
||||
You **must** finish with exactly one safe output action:
|
||||
|
||||
- `create_issue` if there is actionable new diagnosis
|
||||
- `noop` if there is not
|
||||
236
.github/workflows/aw-pr-maintainer-review.md
vendored
Normal file
236
.github/workflows/aw-pr-maintainer-review.md
vendored
Normal file
@@ -0,0 +1,236 @@
|
||||
---
|
||||
description: "Semantic PR maintainer review for plugin standards, bilingual docs sync, and release readiness gaps"
|
||||
private: true
|
||||
labels: [automation, review, pull-request, gh-aw]
|
||||
metadata:
|
||||
author: Fu-Jie
|
||||
category: maintenance
|
||||
maturity: draft
|
||||
on:
|
||||
pull_request:
|
||||
types: [opened, reopened, synchronize, ready_for_review]
|
||||
paths:
|
||||
- 'plugins/**'
|
||||
- 'docs/**'
|
||||
- '.github/**'
|
||||
- 'README.md'
|
||||
- 'README_CN.md'
|
||||
forks: ["*"]
|
||||
workflow_dispatch:
|
||||
roles: all
|
||||
skip-bots: [github-actions, copilot, dependabot, renovate]
|
||||
permissions:
|
||||
contents: read
|
||||
issues: read
|
||||
pull-requests: read
|
||||
engine: copilot
|
||||
network:
|
||||
allowed:
|
||||
- defaults
|
||||
safe-outputs:
|
||||
add-comment:
|
||||
target: triggering
|
||||
max: 1
|
||||
hide-older-comments: true
|
||||
footer: false
|
||||
allowed-github-references: [repo]
|
||||
timeout-minutes: 12
|
||||
tools:
|
||||
github:
|
||||
toolsets: [repos, issues, pull_requests]
|
||||
bash:
|
||||
- pwd
|
||||
- ls
|
||||
- cat
|
||||
- head
|
||||
- tail
|
||||
- grep
|
||||
- wc
|
||||
- rg
|
||||
- git status
|
||||
- git diff
|
||||
- git show
|
||||
- git ls-files
|
||||
---
|
||||
|
||||
# PR Maintainer Review
|
||||
|
||||
You are the repository maintainer assistant for `Fu-Jie/openwebui-extensions`.
|
||||
|
||||
Your job is to review the triggering pull request against this repository's standards and leave **one concise summary comment only when there is actionable feedback**.
|
||||
|
||||
If the PR already looks compliant enough and there is no useful maintainer feedback to add, you **must call `noop`** with a short explanation.
|
||||
|
||||
## Primary Goal
|
||||
|
||||
Review the PR for:
|
||||
|
||||
- repository-standard compliance
|
||||
- missing synchronized file updates
|
||||
- release-readiness gaps
|
||||
- documentation drift introduced by the change
|
||||
- risky behavior regressions in plugin code
|
||||
|
||||
This workflow is **review-only**. Do not attempt to modify files, push code, or open pull requests.
|
||||
|
||||
## High-Priority Source Files
|
||||
|
||||
Use these files as the authoritative rule set before forming conclusions:
|
||||
|
||||
- `.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`
|
||||
|
||||
## Review Scope
|
||||
|
||||
Start from the PR diff and changed files only. Expand into related files only when necessary to verify consistency.
|
||||
|
||||
Prioritize repository policy over generic best practices. This workflow should behave like a maintainer who knows this repository well, not like a broad lint bot.
|
||||
|
||||
Focus especially on these areas:
|
||||
|
||||
### 1. Plugin Code Standards
|
||||
|
||||
When a plugin Python file changes, check for repository-specific correctness:
|
||||
|
||||
- single-file i18n pattern is preserved
|
||||
- user-visible text is routed through translations where appropriate
|
||||
- `_get_user_context` and `_get_chat_context` are used instead of fragile direct access
|
||||
- `__event_call__` JavaScript execution has timeout guards and JS-side fallback handling
|
||||
- `print()` is not introduced in production plugin code
|
||||
- emitter usage is guarded safely
|
||||
- filter plugins do not store request-scoped mutable state on `self`
|
||||
- OpenWebUI/Copilot SDK tool definitions remain consistent with repository conventions
|
||||
|
||||
### 2. Versioning and Release Hygiene
|
||||
|
||||
When `plugins/**/*.py` changes, verify whether the PR also updates what should normally move with it:
|
||||
|
||||
- plugin docstring `version:` changed when behavior changed
|
||||
- local `README.md` and `README_CN.md` changed where user-visible behavior changed
|
||||
- mirrored docs under `docs/plugins/**` changed where required
|
||||
- docs plugin indexes changed if a published version badge or listing text should change
|
||||
- root `README.md` and `README_CN.md` updated date badge if this PR is clearly release-prep oriented
|
||||
|
||||
Do not require every PR to be full release prep. Only flag missing sync files when the PR clearly changes published behavior, plugin metadata, versioned documentation, or release-facing content.
|
||||
|
||||
### 3. Documentation Sync
|
||||
|
||||
When plugin READMEs change, check whether matching docs mirrors should also change:
|
||||
|
||||
- `plugins/{type}/{name}/README.md` -> `docs/plugins/{type}/{name}.md`
|
||||
- `plugins/{type}/{name}/README_CN.md` -> `docs/plugins/{type}/{name}.zh.md`
|
||||
|
||||
When docs-only changes are intentional, avoid over-reporting.
|
||||
|
||||
Useful path mappings:
|
||||
|
||||
- `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`
|
||||
|
||||
### 4. PR Quality and Maintainer Signal
|
||||
|
||||
Check whether the PR description is missing key maintainer context:
|
||||
|
||||
- what changed
|
||||
- why it changed
|
||||
- whether users need migration or reconfiguration
|
||||
|
||||
Only mention this if the omission makes review materially harder.
|
||||
|
||||
## Severity Model
|
||||
|
||||
Use three levels only:
|
||||
|
||||
- `Blocking`: likely bug, release regression, missing required sync, or standards breakage
|
||||
- `Important`: should be fixed before merge, but not an obvious runtime break
|
||||
- `Minor`: worthwhile suggestion, but optional
|
||||
|
||||
Do not invent issues just to leave a comment.
|
||||
|
||||
## Commenting Rules
|
||||
|
||||
Leave **one summary comment** only if there is actionable feedback.
|
||||
|
||||
The comment must:
|
||||
|
||||
- be in English
|
||||
- be concise and maintainer-like
|
||||
- lead with findings, not compliments
|
||||
- include clickable file references like ``plugins/pipes/foo/foo.py`` or ``docs/plugins/pipes/index.md``
|
||||
- avoid nested bullets
|
||||
- avoid repeating obvious diff content
|
||||
|
||||
Use this exact structure when commenting:
|
||||
|
||||
```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.
|
||||
```
|
||||
|
||||
Rules:
|
||||
|
||||
- Omit empty sections.
|
||||
- If there is only one severity category, include only that category plus `Merge Readiness`.
|
||||
- Keep the full comment under about 250 words unless multiple files are involved.
|
||||
|
||||
## No-Comment Rule
|
||||
|
||||
If the PR has no meaningful maintainer findings:
|
||||
|
||||
- do not leave a praise-only comment
|
||||
- do not restate that checks passed
|
||||
- call `noop` with a short explanation like:
|
||||
|
||||
```json
|
||||
{"noop": {"message": "No action needed: reviewed the PR diff and repository sync expectations, and found no actionable maintainer feedback."}}
|
||||
```
|
||||
|
||||
## Suggested Review Process
|
||||
|
||||
1. Identify the changed files in the PR.
|
||||
2. Read the high-priority repository rule files.
|
||||
3. Compare changed plugin code against plugin review instructions.
|
||||
4. Compare changed README or docs files against doc-mirror expectations.
|
||||
5. Determine whether version-sync or release-facing files are missing.
|
||||
6. Draft the shortest useful maintainer summary.
|
||||
7. Leave exactly one `add_comment` or one `noop`.
|
||||
|
||||
## Important Constraints
|
||||
|
||||
- Do not request broad refactors unless the PR already touches that area.
|
||||
- Do not require release-prep steps for tiny internal-only edits.
|
||||
- Do not insist on docs sync when the change is clearly private/internal and not user-facing.
|
||||
- Prefer precise, repository-specific feedback over generic code review advice.
|
||||
- If you are unsure whether a sync file is required, downgrade to `Important` rather than `Blocking`.
|
||||
- If a finding depends on intent that is not visible in the PR, explicitly say it is conditional instead of presenting it as certain.
|
||||
|
||||
## Final Requirement
|
||||
|
||||
You **must** finish with exactly one safe output action:
|
||||
|
||||
- `add_comment` if there is actionable feedback
|
||||
- `noop` if there is not
|
||||
248
.github/workflows/aw-release-preflight.md
vendored
Normal file
248
.github/workflows/aw-release-preflight.md
vendored
Normal file
@@ -0,0 +1,248 @@
|
||||
---
|
||||
description: "Release preflight review for version sync, bilingual docs, release notes, and release-facing consistency"
|
||||
private: true
|
||||
labels: [automation, review, release, gh-aw]
|
||||
metadata:
|
||||
author: Fu-Jie
|
||||
category: maintenance
|
||||
maturity: draft
|
||||
on:
|
||||
pull_request:
|
||||
types: [opened, reopened, synchronize, ready_for_review]
|
||||
paths:
|
||||
- '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/**'
|
||||
forks: ["*"]
|
||||
workflow_dispatch:
|
||||
roles: all
|
||||
skip-bots: [github-actions, copilot, dependabot, renovate]
|
||||
permissions:
|
||||
contents: read
|
||||
issues: read
|
||||
pull-requests: read
|
||||
engine: copilot
|
||||
network:
|
||||
allowed:
|
||||
- defaults
|
||||
safe-outputs:
|
||||
add-comment:
|
||||
target: triggering
|
||||
max: 1
|
||||
hide-older-comments: true
|
||||
footer: false
|
||||
allowed-github-references: [repo]
|
||||
timeout-minutes: 12
|
||||
tools:
|
||||
github:
|
||||
toolsets: [repos, issues, pull_requests]
|
||||
bash:
|
||||
- pwd
|
||||
- ls
|
||||
- cat
|
||||
- head
|
||||
- tail
|
||||
- grep
|
||||
- wc
|
||||
- rg
|
||||
- git status
|
||||
- git diff
|
||||
- git show
|
||||
- git ls-files
|
||||
---
|
||||
|
||||
# Release Preflight Review
|
||||
|
||||
You are the repository maintainer assistant for `Fu-Jie/openwebui-extensions`.
|
||||
|
||||
Your job is to perform a **release-preflight review** for the triggering change and leave **one concise summary comment only when there is actionable release-facing feedback**.
|
||||
|
||||
If the change is not actually release-prep, or it already looks consistent enough that there is no useful maintainer feedback to add, you **must call `noop`** with a short explanation.
|
||||
|
||||
## Primary Goal
|
||||
|
||||
Review the change for:
|
||||
|
||||
- version-sync completeness
|
||||
- bilingual README and docs consistency
|
||||
- release-notes completeness
|
||||
- release-facing index or badge drift
|
||||
- missing migration or maintainer context for a user-visible release
|
||||
|
||||
This workflow is **review-only**. Do not modify files, push code, create releases, or open pull requests.
|
||||
|
||||
## High-Priority Source Files
|
||||
|
||||
Use these files as the authoritative rule set before forming conclusions:
|
||||
|
||||
- `.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`
|
||||
|
||||
## Review Scope
|
||||
|
||||
Start from the PR diff and changed files only. Expand into related release-facing files only when needed to verify sync.
|
||||
|
||||
Prioritize repository release policy over generic release advice. This workflow should act like a maintainer performing a final consistency pass before a release-oriented merge.
|
||||
|
||||
Focus especially on these areas:
|
||||
|
||||
### 1. Version Sync Across Release Files
|
||||
|
||||
When a plugin release is being prepared, check whether the expected version bump is consistently reflected across the release-facing file set:
|
||||
|
||||
- plugin Python docstring `version:`
|
||||
- plugin-local `README.md`
|
||||
- plugin-local `README_CN.md`
|
||||
- docs mirror page in `docs/plugins/**`
|
||||
- Chinese docs mirror page in `docs/plugins/**/*.zh.md`
|
||||
- plugin list entries or badges in `docs/plugins/{type}/index.md`
|
||||
- plugin list entries or badges in `docs/plugins/{type}/index.zh.md`
|
||||
|
||||
Only flag this when the change is clearly release-oriented, version-oriented, or user-visible enough that a synchronized release update is expected.
|
||||
|
||||
### 2. README and Docs Mirror Consistency
|
||||
|
||||
When plugin README files change, check whether the mirrored docs pages were updated consistently.
|
||||
|
||||
Useful path mappings:
|
||||
|
||||
- `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`
|
||||
|
||||
Do not over-report if the change is intentionally docs-only and not a release-prep change.
|
||||
|
||||
### 3. What's New and Release Notes Coverage
|
||||
|
||||
When a release-facing plugin update is present, check whether the release documentation covers the current scope clearly enough:
|
||||
|
||||
- the current `What's New` section reflects the latest release only
|
||||
- the Chinese `最新更新` section is aligned with the English version
|
||||
- `v{version}.md` and `v{version}_CN.md` exist when release notes are expected
|
||||
- release notes cover meaningful feature, fix, docs, or migration changes in the current diff
|
||||
|
||||
Do not require release notes for tiny internal-only edits. Do flag missing release notes if the PR is obviously preparing a published plugin release.
|
||||
|
||||
### 4. Root Readme and Release-Facing Index Drift
|
||||
|
||||
For clearly release-oriented changes, check whether repository-level release-facing surfaces also need updates:
|
||||
|
||||
- root `README.md` updated date badge
|
||||
- root `README_CN.md` updated date badge
|
||||
- plugin index entries under `docs/plugins/**/index.md`
|
||||
- plugin index entries under `docs/plugins/**/index.zh.md`
|
||||
|
||||
Only mention missing root-level updates when the PR is truly release-prep oriented, not for routine internal edits.
|
||||
|
||||
### 5. Maintainer Context and Release Clarity
|
||||
|
||||
Check whether the PR description or visible release-facing text is missing essential context:
|
||||
|
||||
- what is being released
|
||||
- why the release matters
|
||||
- whether migration or reconfiguration is needed
|
||||
|
||||
Only mention this if the omission makes release review materially harder.
|
||||
|
||||
## Severity Model
|
||||
|
||||
Use three levels only:
|
||||
|
||||
- `Blocking`: likely release regression, missing required version sync, or clearly incomplete release-facing update
|
||||
- `Important`: should be fixed before merge to avoid release confusion or drift
|
||||
- `Minor`: worthwhile release-facing cleanup or consistency suggestion
|
||||
|
||||
Do not invent issues just to leave a comment.
|
||||
|
||||
## Commenting Rules
|
||||
|
||||
Leave **one summary comment** only if there is actionable release-preflight feedback.
|
||||
|
||||
The comment must:
|
||||
|
||||
- be in English
|
||||
- be concise and maintainer-like
|
||||
- lead with findings, not compliments
|
||||
- include clickable file references like ``plugins/pipes/foo/README.md`` or ``docs/plugins/pipes/index.md``
|
||||
- avoid nested bullets
|
||||
- avoid restating obvious diff content
|
||||
|
||||
Use this exact structure when commenting:
|
||||
|
||||
```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.
|
||||
```
|
||||
|
||||
Rules:
|
||||
|
||||
- Omit empty sections.
|
||||
- If there is only one severity category, include only that category plus `Release Readiness`.
|
||||
- Keep the full comment under about 250 words unless multiple files are involved.
|
||||
|
||||
## No-Comment Rule
|
||||
|
||||
If the change has no meaningful release-preflight findings:
|
||||
|
||||
- do not leave a praise-only comment
|
||||
- do not restate that checks passed
|
||||
- call `noop` with a short explanation like:
|
||||
|
||||
```json
|
||||
{"noop": {"message": "No action needed: reviewed the release-facing diff, version-sync expectations, and bilingual documentation coverage, and found no actionable preflight feedback."}}
|
||||
```
|
||||
|
||||
## Suggested Review Process
|
||||
|
||||
1. Identify whether the change is actually release-oriented.
|
||||
2. Inspect the changed files in the PR diff.
|
||||
3. Read the repository release-prep rule files.
|
||||
4. Check plugin version-sync expectations only where release intent is visible.
|
||||
5. Check README, README_CN, docs mirrors, indexes, and release notes for drift.
|
||||
6. Draft the shortest useful maintainer summary.
|
||||
7. Leave exactly one `add_comment` or one `noop`.
|
||||
|
||||
## Important Constraints
|
||||
|
||||
- Do not force full release-prep expectations onto tiny internal edits.
|
||||
- Do not require root README badge updates unless the PR is clearly release-facing.
|
||||
- Do not ask for release notes if the change is not realistically a release-prep PR.
|
||||
- Prefer repository-specific sync feedback over generic release advice.
|
||||
- If you are unsure whether a release-facing sync file is required, downgrade to `Important` rather than `Blocking`.
|
||||
- If a finding depends on inferred intent, state it conditionally instead of presenting it as certain.
|
||||
|
||||
## Final Requirement
|
||||
|
||||
You **must** finish with exactly one safe output action:
|
||||
|
||||
- `add_comment` if there is actionable feedback
|
||||
- `noop` if there is not
|
||||
Reference in New Issue
Block a user