docs(gitlab-mr-issue): simplify MR template

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

Author: DCjanus

skills/gitlab-mr-issue/SKILL.md

@@ -28,20 +28,28 @@ description: 查看/更新 GitLab Issue、MR（含评论与 diff），并按团
 以下标题与描述规范为默认推荐格式；如与团队/仓库/平台等既有约束冲突，以既有约束为准。若有明确要求（如需中文），则优先遵循；未覆盖的部分再按本规范补齐。
 1) 确保本地分支已推送且 `git status` 干净。  
 2) 标题风格：英文、遵循语义化提交规范（如 `feat(scope): short summary`），保持简洁且描述核心目的；即使标题要求中文，语义化前缀（如 `feat`、`fix`）仍需英文。  
-3) 描述风格：英文、短句和项目符号，优先让不看代码的读者也能理解动机与结果。重点是 what/why/impact 与必要约束，避免流水账与开发过程细节。若上下文不足以明确目标或约束，应主动向开发者确认后再撰写。涉及专有名词、函数名、方法名、类名、API 名称或配置键时，使用 inline code（反引号）包裹以提升可读性与准确性。  
-4) 期望正文格式（精简但信息完整，按需删减无关块）：
-- `## Summary`：用 1-2 条短句从功能层面概述目的与影响，强调功能变更而非逐条代码变更；跨层（如 Service/DAO）且语义一致的改动应合并为一次功能描述。
-- `## Key changes`：3-5 条要点列出主要变更。
-- `## Constraints / tradeoffs`：若存在约束、限制或非理想选择，简要说明。
-- `## Testing`：验证方式、命令或场景；未测试需注明原因。
-- `## Notes`（可选）：review 关注点、发布注意事项或后续计划。
-5) 特别强调：描述应聚焦 MR 合并前后系统的变化与影响，避免记录开发中的中间过程或修改步骤。
-6) 用 heredoc 传多行描述，避免交互式编辑：
+3) 描述风格：英文、短句和项目符号，优先让不看代码的读者快速理解动机、改动与验证方式。重点是 what/why/testing，避免流水账与过多实现细节。若上下文不足以明确目标或约束，应主动向开发者确认后再撰写。涉及专有名词、函数名、方法名、类名、API 名称或配置键时，使用 inline code（反引号）包裹以提升可读性与准确性。  
+4) 默认正文格式：
+- `## Why`：1-2 条短句说明为什么要做这次改动，聚焦问题背景或目标。
+- `## What`：1-3 条说明主要变更，聚焦功能或行为层面的变化，不罗列琐碎实现细节。
+- `## Testing`：说明验证方式、命令或场景；未测试需注明原因。
+5) 可选正文块：仅在确有必要时再添加。
+- `## Risks`：兼容性影响、潜在风险、回滚注意事项。
+- `## Notes`：reviewers 需要特别关注的点，或后续计划。
+6) 特别强调：描述应聚焦 MR 合并前后系统的变化与影响，避免记录开发中的中间过程或修改步骤。
+7) 用 heredoc 传多行描述，避免交互式编辑：
 ```
 glab mr create \
   --title "feat(scope): short summary" \
   --description "$(cat <<'EOF'
-# 按上面的格式填充正文
+## Why
+- explain why
+
+## What
+- summarize key changes
+
+## Testing
+- list validation steps
 EOF
 )" \
   --target-branch main \