chore(skills): tighten issue and review creation checks

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

Author: DCjanus

skills/github-cli/SKILL.md

@@ -24,26 +24,37 @@ description: 使用 GitHub CLI 与 GitHub 资源交互；适用于 repo、issue
 - Release 列表：`gh release list`
 - Workflow 列表：`gh workflow list`
 
+## 创建前通用检查
+在创建 Issue 或 PR 前，先检查仓库规范、模板或表单；若仓库另有要求，以仓库要求为准。
+1. 优先查这些位置：`CONTRIBUTING.md`、`README.md` 中的贡献说明、`.github/ISSUE_TEMPLATE/`、`.github/ISSUE_TEMPLATE.md`、`.github/PULL_REQUEST_TEMPLATE.md`、`.github/pull_request_template.md`、`.github/PULL_REQUEST_TEMPLATE/`、`.github/config.yml`、issue / PR form 模板、`CODEOWNERS`，以及仓库里与提交规范或分支策略相关的说明。
+2. 若仓库要求特定标题格式、正文结构、关联 issue、检查项、标签、base 分支、签名提交、提交历史整理方式、测试/文档要求或其它必填字段，先按仓库要求准备，再补充本 skill 的默认格式。
+3. 在正式创建前检查本地状态是否匹配这些要求：相关代码、当前分支、提交标题/历史、测试、文档与变更说明是否一致且完整。
+
 ## 创建 Issue（非交互）
-1. 标题与描述风格同 PR，内容保持简洁清晰。
-2. 使用非交互方式创建，避免进入编辑器或依赖手工输入。
-3. 创建成功后，输出完整 Issue URL。
+以下规范建立在“创建前通用检查”已完成的前提上。
+1. 若仓库要求 issue 必须包含特定字段、标签、复现步骤、版本信息、最小示例或分类，先据此整理内容；不要跳过必填项。
+2. 若 issue 与当前本地改动或分支上下文有关，先检查相关代码、分支与提交信息，确认 issue 描述与现状一致，不要提交已经过时或与代码不符的内容。
+3. 标题与描述风格同 PR，内容保持简洁清晰。
+4. 使用非交互方式创建，避免进入编辑器或依赖手工输入。
+5. 创建成功后，输出完整 Issue URL。
 
 ## 创建 PR
 以下标题与描述规范为默认推荐格式；如与团队/仓库/平台等既有约束冲突，以既有约束为准。若有明确要求（如需中文），则优先遵循。
-1. 确认 `git status` 干净，`git push` 到远端。
-2. 标题风格：英文、遵循语义化提交规范（如 `feat(scope): short summary`），简洁且描述核心目的；即使标题要求中文，语义化前缀仍需英文。
-3. 描述风格：英文、短句和项目符号，优先让不看代码的读者快速理解动机、改动与验证方式。重点是 what/why/testing，避免流水账与过多实现细节。若上下文不足以明确目标或约束，应主动向开发者确认后再撰写。涉及专有名词、函数名、方法名、类名、API 名称或配置键时，使用 inline code（反引号）包裹以提升可读性与准确性。
-4. 默认正文格式：
+1. 先完成“创建前通用检查”。
+2. 只有在确认仓库要求与本地代码/提交状态都满足后，才创建 PR；若发现不满足，应先修正，再创建。
+3. `git status` 必须干净，且当前分支已推送到远端。
+4. 标题风格：英文、遵循语义化提交规范（如 `feat(scope): short summary`），简洁且描述核心目的；即使标题要求中文，语义化前缀仍需英文。
+5. 描述风格：英文、短句和项目符号，优先让不看代码的读者快速理解动机、改动与验证方式。重点是 what/why/testing，避免流水账与过多实现细节。若上下文不足以明确目标或约束，应主动向开发者确认后再撰写。涉及专有名词、函数名、方法名、类名、API 名称或配置键时，使用 inline code（反引号）包裹以提升可读性与准确性。
+6. 默认正文格式：
    - `## Why`：1-2 条短句说明为什么要做这次改动，聚焦问题背景或目标。
    - `## What`：1-3 条说明主要变更，聚焦功能或行为层面的变化，不罗列琐碎实现细节。
    - `## Testing`：说明验证方式、命令或场景；未测试需注明原因。
-5. 可选正文块：仅在确有必要时再添加。
+7. 可选正文块：仅在确有必要时再添加。
    - `## Risks`：兼容性影响、潜在风险、回滚注意事项。
    - `## Notes`：reviewers 需要特别关注的点，或后续计划。
-6. 使用非交互式命令创建 PR，避免进入交互式编辑流程；按需补充 base、draft 等参数。
-7. 修改 PR 时复用与创建时一致的非交互方式，避免手工编辑。
-8. 创建成功后，输出完整 PR URL。
+8. 使用非交互式命令创建 PR，避免进入交互式编辑流程；按需补充 base、draft 等参数。
+9. 修改 PR 时复用与创建时一致的非交互方式，避免手工编辑。
+10. 创建成功后，输出完整 PR URL。
 
 ## 更新 Issue/PR 标题或描述（前置要求）
 在更新 Issue 或 PR 的标题/描述之前，必须先读取当前标题/正文（即将被修改的内容），再进行修改。

skills/gitlab-cli/SKILL.md

@@ -41,20 +41,28 @@ description: 使用 GitLab CLI（glab）与 GitLab 资源交互；适用于 proj
 - 若当前版本没有直接的 `wiki` 子命令，改用 `glab api` 访问对应项目 wiki API。
 - 访问前先确认 project 路径或 `project_id`；自建实例场景优先显式设置 `GITLAB_HOST=<host>`。
 
+## 创建前通用检查
+在创建 Issue 或 MR 前，先检查仓库规范、模板或表单；若仓库另有要求，以仓库要求为准。
+1. 优先查这些位置：`CONTRIBUTING.md`、`README.md` 中的贡献说明、`.gitlab/merge_request_templates/`、`.gitlab/issue_templates/`、`CODEOWNERS`，以及仓库里与提交规范或分支策略相关的说明。若仓库明确混用 GitHub 模板或在其它文件中引用等价模板，再按实际情况补查。
+2. 若仓库要求特定标题格式、描述模板、关联 issue、检查项、标签、目标分支、签名提交、提交整理方式、测试/文档要求或其它必填字段，先按仓库要求准备，再补充本 skill 的默认格式。
+3. 在正式创建前检查本地状态是否匹配这些要求：相关代码、当前分支、提交标题/历史、测试、文档与变更说明是否一致且完整。
+
 ## 创建 MR（非交互）
 以下标题与描述规范为默认推荐格式；如与团队/仓库/平台等既有约束冲突，以既有约束为准。若有明确要求（如需中文），则优先遵循；未覆盖的部分再按本规范补齐。
-1) 确保本地分支已推送且 `git status` 干净。  
-2) 标题风格：英文、遵循语义化提交规范（如 `feat(scope): short summary`），保持简洁且描述核心目的；即使标题要求中文，语义化前缀（如 `feat`、`fix`）仍需英文。  
-3) 描述风格：英文、短句和项目符号，优先让不看代码的读者快速理解动机、改动与验证方式。重点是 what/why/testing，避免流水账与过多实现细节。若上下文不足以明确目标或约束，应主动向开发者确认后再撰写。涉及专有名词、函数名、方法名、类名、API 名称或配置键时，使用 inline code（反引号）包裹以提升可读性与准确性。  
-4) 默认正文格式：
+1) 先完成“创建前通用检查”。  
+2) 只有在确认仓库要求与本地代码/提交状态都满足后，才创建 MR；若发现不满足，应先修正，再创建。  
+3) 当前分支必须已推送，且 `git status` 干净。  
+4) 标题风格：英文、遵循语义化提交规范（如 `feat(scope): short summary`），保持简洁且描述核心目的；即使标题要求中文，语义化前缀（如 `feat`、`fix`）仍需英文。  
+5) 描述风格：英文、短句和项目符号，优先让不看代码的读者快速理解动机、改动与验证方式。重点是 what/why/testing，避免流水账与过多实现细节。若上下文不足以明确目标或约束，应主动向开发者确认后再撰写。涉及专有名词、函数名、方法名、类名、API 名称或配置键时，使用 inline code（反引号）包裹以提升可读性与准确性。  
+6) 默认正文格式：
 - `## Why`：1-2 条短句说明为什么要做这次改动，聚焦问题背景或目标。
 - `## What`：1-3 条说明主要变更，聚焦功能或行为层面的变化，不罗列琐碎实现细节。
 - `## Testing`：说明验证方式、命令或场景；未测试需注明原因。
-5) 可选正文块：仅在确有必要时再添加。
+7) 可选正文块：仅在确有必要时再添加。
 - `## Risks`：兼容性影响、潜在风险、回滚注意事项。
 - `## Notes`：reviewers 需要特别关注的点，或后续计划。
-6) 特别强调：描述应聚焦 MR 合并前后系统的变化与影响，避免记录开发中的中间过程或修改步骤。
-7) 用 heredoc 传多行描述，避免交互式编辑：
+8) 特别强调：描述应聚焦 MR 合并前后系统的变化与影响，避免记录开发中的中间过程或修改步骤。
+9) 用 heredoc 传多行描述，避免交互式编辑：
 ```
 glab mr create \
   --title "feat(scope): short summary" \
@@ -81,6 +89,9 @@ EOF
   --description "$(cat <<'EOF'\n...\nEOF\n)" --label ... --yes`。
 
 ## Issue 创建（非交互）
+以下规范建立在“创建前通用检查”已完成的前提上。
+- 若仓库要求 issue 必须包含特定字段、标签、复现步骤、版本信息、最小示例或分类，先据此整理内容；不要跳过必填项。
+- 若 issue 与当前本地改动或分支上下文有关，先检查相关代码、分支与提交信息，确认 issue 描述与现状一致，不要提交已经过时或与代码不符的内容。
 - 命令模式与 MR 类似，使用 `--title` 与 heredoc 描述：  
 ```
 glab issue create \