메뉴
Use after verification-before-completion passes and code review is clean, to close out the development branch
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when a feature, bugfix, or refactoring step is completed and needs review, or before merging to main, or when user says "review", "审查", "帮我看看代码"
Use when receiving an ambiguous feature request, when scope is unclear, or before writing any plan
Use when executing git commit, creating or naming branches, writing PR titles/descriptions, or asking about commit message format, branch naming, or version numbering in this project
Use when writing or reviewing .ets/.ts files in this project, or when seeing any, unknown, obj['key'] index access, destructuring assignment, var declarations,
Use when user asks to create a version release ticket, says "帮我建个发版任务", "建个 Jira", "创建发版单", or needs to track an SDK release in Jira
Use when user mentions "发布 SDK"、"ohpm 发布"、"打包发布"、"上传 har"、"publish"、"发版"、"release"、"发布" or "上传" in the context of this SDK
| name | finishing-a-development-branch |
| description | Use after verification-before-completion passes and code review is clean, to close out the development branch |
Type: Technique | Discipline: Rigid
功能做完、验证通过、审查通过后，进入"收尾阶段"。此 skill 防止两类遗漏：
核心原则： 验证通过 ≠ 任务结束。必须走完收尾五步，才算真正完成。
强制：
verification-before-completion skill 通过后sdk-code-review skill 通过后不触发：
git status
git log --oneline $(git merge-base HEAD master)..HEAD
git diff --stat master..HEAD
回答三个问题：
如果 git status 显示有未提交改动：
git-conventions skill 规范 commit禁止： 使用 git add -A 或 git add . 一把梭，可能把 .env / 本地配置 / 临时日志一起提交。按文件逐个 git add。
检查当前分支是否涉及版本号变更：
git diff master..HEAD -- GrowingAnalytics/oh-package.json5 GrowingToolsKit/oh-package.json5
如果 version 字段有变更： 这是发版分支，进入 Step 3a。
否则： 跳到 Step 4。
| 任务 | 如何执行 |
|---|---|
| 确认 CHANGELOG 已更新 | 检查 CHANGELOG.md / README_*.md 是否有本版本条目 |
| 确认 obfuscation-rules.txt 已同步 | 公开 API 变更是否已加入 keep 规则 |
| Jira 发版单 | 按 jira-ticket skill 创建发版任务（如尚未创建） |
| git tag | 合并到 master 之后再打，不在开发分支上打 |
| OHPM 发布 | 合并后按 ohpm-publish skill 执行 |
tag 命名规范（与 git-conventions 对齐）：
v<version>（如 v2.8.0）toolskit-v<version>（如 toolskit-v1.2.0）向用户呈现 4 个选项，不要擅自决定：
当前分支 <branch-name> 已准备好收尾，请选择：
A. 合并到 master（直接 merge，无 PR 审查）
B. 创建 PR（走 GitHub/GitLab 审查流程）
C. 暂时保留分支（继续迭代或等待依赖）
D. 废弃分支（改动不再需要）
选项 A（合并）： 仅当变更很小、已经过本地审查、无需团队 review 时使用。
选项 B（PR）： 默认推荐。触发 git-conventions skill 的 PR 标题/描述规范。
选项 C（保留）： 不做任何动作，但需要说明保留原因（记入 commit message 或本地备注）。
选项 D（废弃）： 确认后删除本地和远程分支。
路径 A（合并到 master）：
git checkout master
git pull
git merge --no-ff <branch-name>
git push
# 如果是发版分支，现在打 tag
git tag -a v<version> -m "Release v<version>"
git push --tags
# 清理分支
git branch -d <branch-name>
git push origin --delete <branch-name>
路径 B（创建 PR）：
git-conventions skill 写 PR title（类型 + scope + 简述）和 description（背景 / 变更 / 测试）gh pr create 或对应平台命令路径 C（保留）： git push -u origin <branch-name>（如尚未推送）
路径 D（废弃）：
# 本地
git checkout master
git branch -D <branch-name>
# 远程（如果已推送）
git push origin --delete <branch-name>
收尾完成后，向用户报告：
分支 <branch-name> 收尾完成：
- 提交：N 个 commit
- 路径：已合并到 master / PR #123 已创建 / 分支保留 / 分支已删除
- Tag：v2.8.0 已推送 / 无需打 tag
- 后续：需要在 Jira 更新发版单 / 执行 ohpm publish / 无
| 行为 | 为什么禁止 |
|---|---|
| 不问用户直接合并到 master | 合并是不可逆操作，必须用户确认 |
| 发版分支不打 tag 就合并 | 丢失版本追溯能力 |
git add -A 一把梭 | 容易提交敏感文件 |
| 合并后不清理分支 | 仓库分支列表污染 |
| 跳过 Step 1 直接进入合并 | 可能把未提交改动或 WIP commit 带入 master |
| Excuse | Reality |
|---|---|
| "验证通过就算完成了" | 没合并 / 没 PR / 没 tag = 交付还没落地 |
| "直接 push 到 master 快一点" | master 合并必须用户确认，不可自作主张 |
| "发版分支忘了打 tag 也没事" | 丢失版本追溯能力，补 tag 需要 cherry-pick 成本 |
"改动都 commit 了，用 git add -A 一把梭" | 容易把 .env / 密钥 / 构建产物带进去 |
| "合并完分支保留吧以后说不定还用" | 仓库分支列表会膨胀；真要用再 checkout commit |
| "没触发 Planning Gate 就不用走收尾" | 只要有 commit 产生就应该走本 skill，小改动可以跳过 PR 但不能跳过用户确认 |
git add . 快一点" → 下一秒就把 .env 推上去了verification-before-completion 通过且 sdk-code-review 通过jira-ticket（发版单） + ohpm-publish（OHPM 发布） + git-conventions（tag 命名）