用途：为 GitHub Issue/PR、GitLab Issue/MR 编写或更新标题与正文，只负责文案内容，平台命令交给 SKILL.md。
创建前检查：先检查平台模板、表单、必填字段、标签、base/target 分支、squash 策略等仓库约束；若仓库有特定标题格式或正文结构，先按仓库要求准备，再补充默认格式；创建前确认当前代码、分支与提交状态与将要提交的内容一致。
标题与正文原则：只描述提交给 reviewer/maintainer 的最终信息。PR/MR 只描述目标分支当前状态到当前分支最终状态的净变化。先确认 base/head 或 target/source，再用 final net diff 作为依据：git fetch 后查看 git diff --stat <base-or-target>...HEAD 与 git diff --name-status <base-or-target>...HEAD。正文不写中间提交顺序、调试过程、失败尝试、merge/rebase/冲突解决过程，也不写本机绝对路径、home 目录、agent 工作区路径。
默认不写 Validation：CI、pipeline、格式化、lint、类型检查、构建、普通单元测试或“测试通过”不写入正文。仅在验证内容提供 reviewer 在 diff 或 CI 状态里看不到的高信噪比证据时，才添加 ## Validation，例如真实环境验证、手工 UI/API/CLI 确认、外部服务集成、迁移 dry-run、性能或兼容性数据、bug 修复中稳定复现从失败到通过。
更新已有正文：先回读当前正文，再基于 final net diff 重写完整正文并替换过时内容，避免局部补丁和 rerun、previously 等过程措辞。
标题风格：英文、语义化提交规范（如 feat(scope): short summary）；有 breaking change 时用 type(scope)!: short summary，并在正文加 BREAKING CHANGE: 说明影响和迁移方式。
默认正文格式：## Why 用 1-2 条短句说明动机；## What 用 1-3 条说明主要变更；仅在必要时添加 ## Validation、BREAKING CHANGE:、## Risks 或 ## Notes。
Issue：按仓库要求补齐字段、标签、复现步骤、版本信息、最小示例；标题与描述保持简洁，不写草稿路径或本机路径。
限制：资料未提供具体平台命令步骤与安装方式；是否收费、支持平台范围、效果数据暂未提供。