gitops-admin/agent-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: scope onboarding skill to app release flow

Browse Source
This commit is contained in:
xiaobing.wang 2026-03-31 14:22:33 +08:00
parent 0567364af5
commit dd77f8da1f
2 changed files with 23 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
README.md
View File

@ -16,14 +16,15 @@
- 给当前平台接入新项目 - 给当前平台接入新项目
- 恢复 `.gitlab-ci.yml`、`deploy/`、Helm Chart、release bundle - 恢复 `.gitlab-ci.yml`、`deploy/`、Helm Chart、release bundle
- 修当前 GitOps 仓库中的 `Application`、`AppProject`、release 引用 - 修当前平台的发版链路
- 补齐当前平台的 GitOps 交付链路 - 让应用仓库在发版时推送自己的 release 结果
不适合处理： 不适合处理：
- 通用 GitLab CI 改造 - 通用 GitLab CI 改造
- 通用 Helm Chart 编写 - 通用 Helm Chart 编写
- 未指向当前平台常量的通用 GitOps / Argo CD 任务 - 未指向当前平台常量的通用 GitOps / Argo CD 任务
- 修改 GitOps 仓库中的 `Application`、`AppProject` 或其他发布侧清单
## 安装 ## 安装

54
gitops-app-onboarding/SKILL.md
View File

@ -1,6 +1,6 @@
--- ---
name: gitops-app-onboarding name: gitops-app-onboarding
description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适用于 `deploy.baizhi.cloud`、`registry.baizhi.cloud`、GitLab + Argo CD 这套固定交付模型。只要用户提到“给当前平台接入新项目”“恢复 .gitlab-ci.yml / deploy 目录”“修当前 GitOps 仓库里的 Application / AppProject / release 引用”“补齐当前平台的 Helm chart / release bundle / GitOps 交付链路”，就应优先使用这个 skill；如果只是通用 CI、通用 Helm 或通用 GitOps 任务而未指向当前平台，不应触发。 description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适用于 `deploy.baizhi.cloud`、`registry.baizhi.cloud`、GitLab + Argo CD 这套固定交付模型。只要用户提到“给当前平台接入新项目”“恢复 .gitlab-ci.yml / deploy 目录”“补齐当前平台的 Helm chart / release bundle”“修当前平台的发版链路”“让应用仓库在发版时推送自己的 release 结果”，就应优先使用这个 skill；如果只是通用 CI、通用 Helm 或通用 GitOps 任务而未指向当前平台，不应触发。
--- ---
# GitOps 项目接入 Skill # GitOps 项目接入 Skill
@ -14,7 +14,7 @@ description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适
- 为应用仓库补齐或恢复 `.gitlab-ci.yml` - 为应用仓库补齐或恢复 `.gitlab-ci.yml`
- 生成或修复 `deploy/helm/<app>/` Chart - 生成或修复 `deploy/helm/<app>/` Chart
- 生成或修复 `deploy/release/` release bundle - 生成或修复 `deploy/release/` release bundle
- 在需要时补当前 GitOps 仓库中的 `Application`、`AppProject` 与发布结果 - 在发版链路中将当前应用自己的 release 结果推送到固定 GitOps 仓库
## 平台固定常量 ## 平台固定常量
@ -42,15 +42,13 @@ description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适
开始改代码前，按下面顺序建立上下文： 开始改代码前，按下面顺序建立上下文：
1. 先读当前 GitOps 仓库 `README.md` 1. 先读目标应用仓库 `README.md`
2. 再读目标应用仓库 `README.md` 2. 再读 Dockerfile、包管理文件、构建脚本、现有 deploy 文件
3. 再读 Dockerfile、包管理文件、构建脚本、现有 deploy 文件 3. 如果用户给了额外设计文档，一并读取
4. 如果用户给了额外设计文档，一并读取
判断规则： 判断规则：
- 目标应用仓库自己的 `README.md` 是应用运行架构的真相来源 - 目标应用仓库自己的 `README.md` 是应用运行架构的真相来源
- 当前 GitOps 仓库 `README.md` 说明平台目录职责和安装入口
- 本 skill 定义平台接入流程、约束和执行重点 - 本 skill 定义平台接入流程、约束和执行重点
- 如果应用 README 与平台约定冲突，优先识别是“应用设计差异”还是“平台硬约束” - 如果应用 README 与平台约定冲突，优先识别是“应用设计差异”还是“平台硬约束”
- 如果冲突会直接改变最终实现且无法安全推断，再问用户；否则优先按已有代码和文档做最小偏差实现 - 如果冲突会直接改变最终实现且无法安全推断，再问用户；否则优先按已有代码和文档做最小偏差实现
@ -70,11 +68,14 @@ description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适
先区分任务属于哪一种： 先区分任务属于哪一种：
1. 只修应用仓库：仅修改应用仓库中的 CI、Chart、release 模板 1. 补齐或修复应用仓库中的 CI、Chart、release 模板
2. 首次接入当前 GitOps 仓库：除应用仓库外，还要补当前 GitOps 仓库中的发布文件 2. 修复应用仓库中的发版链路，使其在发版时推送当前应用自己的 release 结果
3. 只修当前 GitOps 仓库：仅改 GitOps 侧引用与发布结果
如果用户只要求修应用仓库，不要擅自修改当前 GitOps 仓库。 边界约束：
- 本 skill 只处理应用仓库侧接入
- 不读取、不判断、不修改 GitOps 仓库中的 `Application`、`AppProject` 或其他发布侧清单
- 对 GitOps 的唯一动作，是在应用仓库 CI 中推送当前应用自己的 release 结果或版本引用
## 交付模型 ## 交付模型
@ -115,22 +116,6 @@ description: 面向当前 Baizhi GitOps 平台的项目接入工作流，只适
如果应用还有不适合放进 Chart 的静态清单，可以在后续发布结果中导出到当前 GitOps 仓库的 `releases/<app>/manifests/`。 如果应用还有不适合放进 Chart 的静态清单，可以在后续发布结果中导出到当前 GitOps 仓库的 `releases/<app>/manifests/`。
## 当前 GitOps 仓库通常需要生成什么
只有在“首次接入当前 GitOps 仓库”或用户明确要求时，才生成或修复：
- `apps/<app-name>/application.yaml`
- `bootstrap/projects/<app-name>-project.yaml`
- `releases/<app-name>/metadata.yaml`
- `releases/<app-name>/values.yaml`
- `releases/<app-name>/manifests/secret.yaml`
- `releases/<app-name>/manifests/kustomization.yaml`
- 其他确有必要的静态发布清单
如需建新应用骨架，优先执行或仿照 `scripts/new-app.sh`，不要脱离现有目录结构重新发明。
当前 GitOps 仓库保存的是 Argo 可消费的发布结果，不保存应用 Chart 模板源码。
## GitLab CI 规则 ## GitLab CI 规则
### stages ### stages
@ -197,14 +182,14 @@ test job 应运行在分支和 MR 上，并执行目标项目自己的标准测
这个 job 必须： 这个 job 必须：
- 克隆 `https://${GITEA_USER}:${GITEA_TOKEN}@deploy.baizhi.cloud/gitops-admin/argodeploy.git` - 克隆 `https://${GITEA_USER}:${GITEA_TOKEN}@deploy.baizhi.cloud/gitops-admin/argodeploy.git`
- 只更新目标应用在当前 GitOps 仓库中的版本引用 - 只同步当前应用自己的 release 结果或版本引用
- 提交并推送到 `main` - 提交并推送到 `main`
通常需要更新： 通常需要更新：
- `apps/<app-name>/application.yaml`
- `releases/<app-name>/values.yaml` - `releases/<app-name>/values.yaml`
- `releases/<app-name>/metadata.yaml` - `releases/<app-name>/metadata.yaml`
- `releases/<app-name>/manifests/` 下由当前应用导出的发布结果
不要在这个 job 中加入集群部署逻辑。 不要在这个 job 中加入集群部署逻辑。
@ -297,6 +282,8 @@ deploy/helm/<app-name>/
- 如果用户暂时没有提供，不要造占位内容冒充可部署配置 - 如果用户暂时没有提供，不要造占位内容冒充可部署配置
- 可以只保留结构，或暂不生成具体 secret 内容，但必须在最终输出中明确警告缺失项与影响 - 可以只保留结构，或暂不生成具体 secret 内容，但必须在最终输出中明确警告缺失项与影响
release bundle 只负责导出当前应用自己的发布结果，不负责维护 GitOps 仓库中的其他对象。
## 平台共享配置契约 ## 平台共享配置契约
`shared/` 目录只放平台级共享配置。 `shared/` 目录只放平台级共享配置。
@ -354,13 +341,12 @@ shared 边界：
建议按下面顺序推进： 建议按下面顺序推进：
1. 读取应用 README 与构建文件，梳理组件和暴露模型 1. 读取应用 README 与构建文件，梳理组件和暴露模型
2. 判断任务范围是应用仓库、当前 GitOps 仓库，还是两者都要改 2. 判断任务是补齐应用仓库接入，还是修复发版链路
3. 生成或修复 `.gitlab-ci.yml` 3. 生成或修复 `.gitlab-ci.yml`
4. 生成或修复 Chart 与 values 4. 生成或修复 Chart 与 values
5. 生成或修复 release bundle 5. 生成或修复 release bundle
6. 如任务需要，再补当前 GitOps 仓库中的 `Application` 与发布结果 6. 完成非阻塞工作后，再处理可选私有接入提问
7. 完成非阻塞工作后，再处理可选私有接入提问 7. 自检并在最终输出中说明风险点
8. 自检并在最终输出中说明风险点
## 自检要求 ## 自检要求
@ -373,7 +359,7 @@ shared 边界：
至少确认： 至少确认：
- 应用仓库不再缺少接入文件 - 应用仓库不再缺少接入文件
- `.gitlab-ci.yml` 包含 test、镜像构建、chart 发布、GitOps 仓库更新逻辑 - `.gitlab-ci.yml` 包含 test、镜像构建、chart 发布、release 结果同步逻辑
- release values 指向 `registry.baizhi.cloud` - release values 指向 `registry.baizhi.cloud`
- GitOps 仓库更新 job 指向 `https://deploy.baizhi.cloud/gitops-admin/argodeploy.git` - GitOps 仓库更新 job 指向 `https://deploy.baizhi.cloud/gitops-admin/argodeploy.git`
- CI 中没有直接调用 Argo - CI 中没有直接调用 Argo