扩展 GitHub 与 GitLab skill 为平台级 CLI 交互 (#34)

## 背景
- 现有 GitHub / GitLab skill 的名称和描述过于聚焦 issue、PR、MR，容易把触发范围限制死。
- 实际使用中还会涉及更广泛的平台交互场景，例如 GitLab wiki。
- 同时不希望在 AGENTS.md 中直接耦合具体 skill 名称，应更多依赖 skill 自身的 name 和 description
做判断。
- 另外，当前模型在执行 `git add`、`git commit`、`git push` 时容易倾向并行调用，实际会因为
`.git/index.lock` 导致部分 Git 命令失败，需要在 `git-commit` skill 中补充明确约束。

## 变更
- 将 `github-pr-issue` 重命名为 `github-cli`，将 `gitlab-mr-issue` 重命名为
`gitlab-cli`。
- 调整两个 skill 的 description 和正文说明，从 issue / PR / MR 场景扩展到平台级 CLI 交互场景。
- 在 `gitlab-cli` 中补充 wiki 场景，明确优先检查 `glab` 子命令，不足时使用 `glab api`。
- 清理 `AGENTS.md` 中对具体 skill 的直接引用，仅保留平台交互应优先使用官方 CLI 或 API、且尽量非交互的原则。
- 更新 README 中的 skill 列表说明，和新的 skill 名称与定位保持一致。
- 在 `git-commit` 中新增 Git 写操作默认串行执行的约束，明确避免并行触发多个 `git add`、`git
commit`、`git push`，并补充 `index.lock` 相关处理说明与顺序执行示例。

## 验证
- 未运行自动化测试；本次仅涉及文档与 skill 定义调整。

---------

Co-authored-by: OpenAI Codex <codex@openai.com>

Author: DCjanus

AGENTS.md

@@ -65,10 +65,11 @@
 ## 4. 操作流程
 
 ### 4.1 Git 提交相关操作
-- 涉及 `git commit`、`git push`、分支命名、提交信息或提交前整理时，优先使用 [git-commit](skills/git-commit/)。
+- 涉及 `git commit`、`git push`、分支命名、提交信息或提交前整理时，优先使用非交互命令，并遵循仓库内对应约定。
 
-### 4.2 查看 GitHub issue / PR
-- 涉及 GitHub issue/PR 的查看、更新或创建：优先使用 [github-pr-issue](skills/github-pr-issue/)。
+### 4.2 GitHub / GitLab 交互
+- 涉及 GitHub 资源或交互（如 repo、issue、PR、comment、release、workflow 等）的查看、更新或创建时，优先使用对应平台的官方 CLI 或 API，并尽量保持非交互。
+- 涉及 GitLab 资源或交互（如 project、issue、MR、comment、wiki 等）的查看、更新或创建时，优先使用对应平台的官方 CLI 或 API，并尽量保持非交互。
 
 ### 4.3 添加/更新依赖
 - 使用对应生态官方命令：

README.md

@@ -56,8 +56,8 @@ notification_method = "bel"
 | [`dcjanus-preferences`](skills/dcjanus-preferences/SKILL.md) | 记录 DCjanus 在不同语言中偏好的第三方库与使用场景，供 AI 在选型、引入依赖或替换库时优先参考。适用于 Python/Rust/Go 的库选择、技术方案对比、或需要遵循 DCjanus 个人偏好进行开发的场景。 |
 | [`fetch-url`](skills/fetch-url/SKILL.md) | 获取并提取链接正文（默认 Markdown）；内置 X/Twitter URL 处理，提升受限页面的抓取成功率。 |
 | [`git-commit`](skills/git-commit/SKILL.md) | 处理 git 提交/推送/分支命名与提交信息规范；当用户要求 commit、push、起分支或整理 commit message 时使用。 |
-| [`github-pr-issue`](skills/github-pr-issue/SKILL.md) | GitHub CLI 使用指引（issue/PR 查看、编辑与创建，含团队 PR 规范） |
-| [`gitlab-mr-issue`](skills/gitlab-mr-issue/SKILL.md) | GitLab CLI（glab）使用指引（issue/MR 查看、编辑与创建，含团队 MR/issue 规范） |
+| [`github-cli`](skills/github-cli/SKILL.md) | GitHub CLI 使用指引，面向 GitHub 资源交互（如 repo、issue、PR、comment、release、workflow） |
+| [`gitlab-cli`](skills/gitlab-cli/SKILL.md) | GitLab CLI（glab）使用指引，面向 GitLab 资源交互（如 project、issue、MR、comment、wiki） |
 | [`golang-lo`](skills/golang-lo/SKILL.md) | Go >= 1.18 项目中希望用 samber/lo（Lodash 风格泛型库）简化集合/映射/字符串、错误处理、重试/节流/防抖、通道并发或指针空值场景时使用。 |
 | [`pwdebug`](skills/pwdebug/SKILL.md) | 用于需要通过命令行操作真实浏览器实例进行前端调试（如导航、执行 JS、截图、元素拾取、控制台日志）且希望跨多次命令复用同一浏览器会话的场景。 |
 | [`ticktick-cli`](skills/ticktick-cli/SKILL.md) | 使用 Python CLI 与 Dida365 Open API 交互以管理滴答清单任务/项目，适用于需要通过脚本或命令行调用滴答清单接口的场景（如项目/任务的查询、创建、更新、完成、删除）。 |

skills/git-commit/SKILL.md

@@ -14,6 +14,8 @@ git add <paths>
 git commit -m "feat(scope): short summary"
 ```
 
+涉及 Git 写操作时，默认按串行顺序执行单条命令，避免并行触发多个 `git add`、`git commit`、`git push`，以免因为 `.git/index.lock` 导致部分命令失败。
+
 ## 使用约定
 
 - 未收到用户当次明确 `commit` 指令时，不执行 `git commit`。
@@ -25,6 +27,9 @@ git commit -m "feat(scope): short summary"
 - 提交时追加 `Co-authored-by: OpenAI Codex <codex@openai.com>` trailer。
 - 日常切换/恢复操作优先使用 `git switch` 与 `git restore`，尽量避免 `git checkout`。
 - 进行提交前，先确认工作区中哪些改动属于当前任务，避免把无关改动混入同一个提交。
+- 涉及 Git 写操作时，默认串行执行，不并行调用多个 Git 命令；尤其不要并行触发多个会写入 index 或引用的命令。
+- 如需连续执行 `git add`、`git commit`、`git push`，优先单次按顺序执行，前一步成功后再执行下一步；只有明确确认不存在锁竞争风险时才可例外。
+- 如果遇到 `.git/index.lock`，先判断是否有其他活跃 Git 进程；不要把并行执行当成默认方案。
 
 ## 常用场景
 
@@ -72,6 +77,14 @@ git restore <path>
 git restore --staged <path>
 ```
 
+- 顺序执行 add / commit / push：
+
+```bash
+git add <paths>
+git commit -m "feat(scope): concise summary" -m "Co-authored-by: OpenAI Codex <codex@openai.com>"
+git push origin HEAD
+```
+
 ## 提交信息约定
 
 - 推荐格式：`type(scope): short summary`

skills/github-pr-issue/SKILL.md skills/github-cli/SKILL.mdskills/github-pr-issue/SKILL.md renamed to skills/github-cli/SKILL.md

@@ -1,16 +1,29 @@
 ---
-name: github-pr-issue
-description: 查看/更新 GitHub Issue、PR（含评论与 diff），并按团队规范非交互创建或修改 PR；涉及 GitHub Issue/PR 的操作时使用。
+name: github-cli
+description: 使用 GitHub CLI 与 GitHub 资源交互；适用于 repo、issue、PR、comment、release、workflow 等查看、更新或创建场景。
 ---
 
-# GitHub CLI Skill（Issue/PR）
+# GitHub CLI Skill
+
+一句话说明：当任务核心是“和 GitHub 打交道”时，优先使用 `gh`，而不是把范围局限在 Issue/PR。
+
+## 常用场景
+- 仓库、Issue、PR、评论、release、workflow 等资源，优先先用 `gh <group> --help` 确认是否有现成子命令，再执行。
+- 需要机器可读输出时，优先使用 `--json`，必要时再配合 `jq` 整理字段。
 
 ## PR Review
 - 先看 PR 概览，再拉取 review / comment / thread 明细，确保不是只看单一来源。
 - 必要时可以查看本地对应分支的代码；查看前先 `git fetch`，确保分支是最新远端状态。
 - 当用户要求整理 PR 审查意见时，按严重程度从高到低排列，数字编号，方便用户回复。
 - 每次最多展示 10 条；若还有更多，在末尾提示“还剩 N 条未展示”。
 
+## 快速查看
+- 仓库概览：`gh repo view [owner/repo]`
+- Issue 概览：`gh issue view <id|url>`
+- PR 概览：`gh pr view <id|url>`
+- Release 列表：`gh release list`
+- Workflow 列表：`gh workflow list`
+
 ## 创建 Issue（非交互）
 1. 标题与描述风格同 PR，内容保持简洁清晰。
 2. 使用非交互方式创建，避免进入编辑器或依赖手工输入。
@@ -34,3 +47,8 @@ description: 查看/更新 GitHub Issue、PR（含评论与 diff），并按团
 
 ## 更新 Issue/PR 标题或描述（前置要求）
 在更新 Issue 或 PR 的标题/描述之前，必须先读取当前标题/正文（即将被修改的内容），再进行修改。
+
+## 冷门参数怎么查
+- `gh --help`
+- `gh <group> --help`
+- `gh <group> <subcommand> --help`

skills/gitlab-mr-issue/SKILL.md skills/gitlab-cli/SKILL.mdskills/gitlab-mr-issue/SKILL.md renamed to skills/gitlab-cli/SKILL.md

@@ -1,9 +1,11 @@
 ---
-name: gitlab-mr-issue
-description: 查看/更新 GitLab Issue、MR（含评论与 diff），并按团队规范非交互创建或修改 MR/Issue；涉及 GitLab（含自建实例）Issue/MR 的操作时使用。
+name: gitlab-cli
+description: 使用 GitLab CLI（glab）与 GitLab 资源交互；适用于 project、issue、MR、comment、wiki 等查看、更新或创建场景，含自建实例。
 ---
 
-# GitLab CLI Skill（MR/Issue）
+# GitLab CLI Skill
+
+一句话说明：当任务核心是“和 GitLab 打交道”时，优先使用 `glab`，而不是把范围局限在 MR/Issue。
 
 ## MR Review
 - 优先读取 MR discussions / notes / diff comments，再做统一整理。
@@ -19,6 +21,10 @@ description: 查看/更新 GitLab Issue、MR（含评论与 diff），并按团
 - 输出格式默认够用，若需机器可读用 `--output json`。
 - 创建 MR 或 Issue 成功后，在终端**单独一行**输出 CLI 返回的完整 URL。
 
+## 常用场景
+- project、issue、MR、comment、wiki 等资源，优先先用 `glab <group> --help` 确认是否有现成子命令，再执行。
+- 若 `glab` 没有直接子命令，但 GitLab API 支持该资源，优先改用 `glab api ...`。
+
 ## Issue 快速查看
 - 只看正文：`glab issue view <id|url>`.
 - 带讨论：`glab issue view <id|url> --comments`（必要时加 `--system-logs`）。
@@ -30,6 +36,11 @@ description: 查看/更新 GitLab Issue、MR（含评论与 diff），并按团
 - 查看 diff：`glab mr diff <id|branch> --color=never`；需要原始 patch 用 `--raw`。
 - 相关 issue：`glab mr issues <id>`。
 
+## Wiki
+- 先检查命令：`glab wiki --help`
+- 若当前版本没有直接的 `wiki` 子命令，改用 `glab api` 访问对应项目 wiki API。
+- 访问前先确认 project 路径或 `project_id`；自建实例场景优先显式设置 `GITLAB_HOST=<host>`。
+
 ## 创建 MR（非交互）
 以下标题与描述规范为默认推荐格式；如与团队/仓库/平台等既有约束冲突，以既有约束为准。若有明确要求（如需中文），则优先遵循；未覆盖的部分再按本规范补齐。
 1) 确保本地分支已推送且 `git status` 干净。  
@@ -87,3 +98,9 @@ glab issue create \
 
 ## 更新 Issue/MR 标题或描述（前置要求）
 在更新 Issue 或 MR 的标题/描述之前，必须先读取当前标题/正文（即将被修改的内容），再进行修改。
+
+## 冷门参数怎么查
+- `glab --help`
+- `glab <group> --help`
+- `glab <group> <subcommand> --help`
+- API 字段不明确时：`glab api --help`