gitlab-mr-issue

SKILL.md

创建 MR（非交互） 以下标题与描述规范为默认推荐格式；如与团队/仓库/平台等既有约束冲突，以既有约束为准。若有明确要求（如需中文），则优先遵循；未覆盖的部分再按本规范补齐。 1) 确保本地分支已推送且 git status 干净。 2) 标题风格：英文、遵循语义化提交规范（如 feat(scope): short summary），保持简洁且描述核心目的；即使标题要求中文，语义化前缀（如 feat、fix）仍需英文。

3) 描述风格：英文、短句和项目符号，优先让不看代码的读者也能理解动机与结果。重点是 what/why/impact 与必要约束，避免流水账与开发过程细节。若上下文不足以明确目标或约束，应主动向开发者确认后再撰写。涉及专有名词、函数名、方法名、类名、API 名称或配置键时，使用 inline code（反引号）包裹以提升可读性与准确性。 4) 期望正文格式（精简但信息完整，按需删减无关块）：

5) 特别强调：描述应聚焦 MR 合并前后系统的变化与影响，避免记录开发中的中间过程或修改步骤。 6) 用 heredoc 传多行描述，避免交互式编辑：

查看/更新 GitLab Issue、MR（含评论与 diff），并按团队规范非交互创建或修改 MR/Issue；涉及Problema de GitLab/MR 的操作时使用. Fuente: dcjanus/prompts.

Ver original