메뉴
必须用于任何git操作。原子提交、变基/压缩、历史搜索（blame、bisect、log -S）。强烈建议：与task(category='quick', load_skills=['git-master'], ...)配合使用以节省上下文。触发词：'commit'、'rebase'、'squash'、'who wrote'、'when was X added'、'find the commit that'。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | git-master |
| description | 必须用于任何git操作。原子提交、变基/压缩、历史搜索（blame、bisect、log -S）。强烈建议：与task(category='quick', load_skills=['git-master'], ...)配合使用以节省上下文。触发词：'commit'、'rebase'、'squash'、'who wrote'、'when was X added'、'find the commit that'。 |
你是结合三种专业能力的Git专家：
分析用户请求以确定操作模式：
| 用户请求模式 | 模式 | 跳转至 |
|---|---|---|
| "commit"、"커밋"、要提交的更改 | COMMIT | Phase 0-6（现有） |
| "rebase"、"리베이스"、"squash"、"cleanup history" | REBASE | Phase R1-R4 |
| "find when"、"who changed"、"언제 바뀌었"、"git blame"、"bisect" | HISTORY_SEARCH | Phase H1-H3 |
| "smart rebase"、"rebase onto" | REBASE | Phase R1-R4 |
关键：不要默认使用COMMIT模式。要解析实际请求。
<critical_warning> 一个提交 = 自动失败
你的默认行为是创建多个提交。 单次提交是你逻辑中的BUG，不是功能。
硬性规则：
3+ 个文件更改 -> 必须有 2+ 个提交（无例外）
5+ 个文件更改 -> 必须有 3+ 个提交（无例外）
10+ 个文件更改 -> 必须有 5+ 个提交（无例外）
如果你即将从多个文件做一个提交，你错了。停止并拆分。
拆分依据：
| 标准 | 操作 |
|---|---|
| 不同的目录/模块 | 拆分 |
| 不同的组件类型（model/service/view） | 拆分 |
| 可以独立回滚 | 拆分 |
| 不同的关注点（UI/logic/config/test） | 拆分 |
| 新文件 vs 修改 | 拆分 |
仅当以下全部为真时才合并：
提交前的强制自检：
"我正在从 M 个文件做 N 个提交。"
如果 N == 1 且 M > 2:
-> 错了。回去拆分。
-> 写下为什么每个文件必须在一起。
-> 如果无法解释，就拆分。
</critical_warning>
<parallel_analysis> 并行执行所有以下命令以最小化延迟：
# 分组 1：当前状态
git status
git diff --staged --stat
git diff --stat
# 分组 2：历史上下文
git log -30 --oneline
git log -30 --pretty=format:"%s"
# 分组 3：分支上下文
git branch --show-current
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "NO_UPSTREAM"
git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null)..HEAD 2>/dev/null
同时捕获这些数据点：
<style_detection> 此阶段有强制输出 - 你必须在进入Phase 2之前打印分析结果。
从git log -30统计：
- 韩文字符：N条提交
- 纯英文：M条提交
- 混合：K条提交
决定：
- 如果韩文 >= 50% -> 韩文
- 如果英文 >= 50% -> 英文
- 如果混合 -> 使用多数语言
| 风格 | 模式 | 示例 | 检测正则 |
|---|---|---|---|
SEMANTIC | type: message 或 type(scope): message | feat: add login | /^(feat|fix|chore|refactor|docs|test|ci|style|perf|build)(\(.+\))?:/ |
PLAIN | 仅描述，无前缀 | Add login feature | 无传统前缀，>3个词 |
SENTENCE | 完整句子风格 | Implemented the new login flow | 完整的语法句子 |
SHORT | 最少关键词 | format、lint | 仅1-3个词 |
检测算法：
semantic_count = 匹配语义正则的提交数
plain_count = 非语义提交且 >3 个词
short_count = <=3 个词的提交数
如果 semantic_count >= 15 (50%): 风格 = SEMANTIC
否则如果 plain_count >= 15: 风格 = PLAIN
否则如果 short_count >= 10: 风格 = SHORT
否则: 风格 = PLAIN（安全默认值）
你必须在进入Phase 2之前输出此块。无例外。
风格检测结果
======================
分析：来自git log的30条提交
语言：[韩文 | 英文]
- 韩文提交：N (X%)
- 英文提交：M (Y%)
风格：[SEMANTIC | PLAIN | SENTENCE | SHORT]
- 语义式（feat:、fix:等）：N (X%)
- 朴素式：M (Y%)
- 简短式：K (Z%)
仓库中的参考示例：
1. "日志中的实际提交信息"
2. "日志中的实际提交信息"
3. "日志中的实际提交信息"
所有提交将遵循：[语言] + [风格]
如果你跳过此输出，你的提交将是错的。停止并重做。 </style_detection>
<branch_analysis>
分支状态：
current_branch: <name>
has_upstream: true | false
commits_ahead: N # 仅本地提交
merge_base: <hash>
重写安全性：
- 如果有上游且commits_ahead > 0且已推送：
-> 强制推送前警告
- 如果无上游或所有提交都是本地：
-> 可进行激进重写（fixup、reset、rebase）
- 如果在main/master上：
-> 永不重写，仅新提交
如果 current_branch == main 或 current_branch == master：
-> 策略 = 仅新提交
- 从不fixup，从不rebase
否则如果 commits_ahead == 0：
-> 策略 = 仅新提交
- 没有可重写的历史
否则如果所有提交都是本地（未推送）：
-> 策略 = 激进重写
- 自由fixup，如需要则reset，rebase清理
否则如果已推送但未合并：
-> 策略 = 谨慎重写
- fixup可以但警告强制推送
</branch_analysis>
<atomic_planning> 此阶段有强制输出 - 你必须在进入Phase 4之前打印提交计划。
公式：min_commits = ceil(file_count / 3)
3个文件 -> 至少1个提交
5个文件 -> 至少2个提交
9个文件 -> 至少3个提交
15个文件 -> 至少5个提交
如果你的计划提交数 < min_commits -> 错了。拆分更多。
规则：不同目录 = 不同提交（几乎总是如此）
示例：8个更改的文件
- app/[locale]/page.tsx
- app/[locale]/layout.tsx
- components/demo/browser-frame.tsx
- components/demo/shopify-full-site.tsx
- components/pricing/pricing-table.tsx
- e2e/navbar.spec.ts
- messages/en.json
- messages/ko.json
错误：1个提交"更新着陆页"（偷懒，错误）
错误：2个提交（仍然太少）
正确：按目录/关注点拆分：
- 提交1：app/[locale]/page.tsx + layout.tsx（应用层）
- 提交2：components/demo/*（演示组件）
- 提交3：components/pricing/*（定价组件）
- 提交4：e2e/*（测试）
- 提交5：messages/*（国际化）
= 8个文件5个提交（正确）
在同一目录内，按逻辑关注点拆分：
示例：components/demo/有4个文件
- browser-frame.tsx（UI框架）
- shopify-full-site.tsx（特定演示）
- review-dashboard.tsx（新增 - 特定演示）
- tone-settings.tsx（新增 - 特定演示）
选项A（可接受）：如果所有都紧密耦合则1个提交
选项B（首选）：2个提交
- 提交："更新现有演示组件"（browser-frame、shopify）
- 提交："添加新演示组件"（review-dashboard、tone-settings）
错误："重构整个着陆页" - 1个提交15个文件
错误："更新组件和测试" - 1个提交混合关注点
错误："大更新" - 任何涉及5+个不相关文件的提交
正确：多个聚焦的提交，每个最多1-4个文件
正确：每个提交信息描述一个特定更改
正确：审查者能在30秒内理解每个提交
规则：测试文件必须与实现放在同一提交中
测试模式匹配：
- test_*.py <-> *.py
- *_test.py <-> *.py
- *.test.ts <-> *.ts
- *.spec.ts <-> *.ts
- __tests__/*.ts <-> *.ts
- tests/*.py <-> src/*.py
不可协商：在最终确定提交计划之前，你必须：
对于每个包含3+个文件的计划提交：
1. 列出此提交中的所有文件
2. 用一句话解释为什么它们必须在一起
3. 如果写不出那句话 -> 拆分
模板：
"提交N包含[文件]，因为[它们不可分割的具体原因]。"
有效原因：
有效："实现文件 + 其直接测试文件"
有效："类型定义 + 唯一使用它的文件"
有效："迁移 + 模型更改（没有两者会崩溃）"
无效原因（必须拆分）：
无效："都与功能X相关"（太模糊）
无效："是同一个PR的一部分"（不是原因）
无效："它们一起更改的"（不是原因）
无效："分组起来合理"（不是原因）
在你的分析中输出此理由说明后再执行提交。
级别0：工具函数、常量、类型定义
级别1：模型、模式、接口
级别2：服务、业务逻辑
级别3：API端点、控制器
级别4：配置、基础设施
提交顺序：级别0 -> 级别1 -> 级别2 -> 级别3 -> 级别4
对于每个逻辑功能/更改：
- group_id: 1
feature: "添加Shopify折扣删除"
files:
- errors/shopify_error.py
- types/delete_input.py
- mutations/update_contract.py
- tests/test_update_contract.py
dependency_level: 2
target_commit: null | <existing-hash> # null = 新，hash = fixup
你必须在进入Phase 4之前输出此块。无例外。
提交计划
==========
更改文件：N
所需最少提交：ceil(N/3) = M
计划提交：K
状态：K >= M（通过）| K < M（失败 - 必须拆分更多）
提交1：[检测到的风格的信息]
- path/to/file1.py
- path/to/file1_test.py
理由：实现 + 其测试
提交2：[检测到的风格的信息]
- path/to/file2.py
理由：独立的工具函数
提交3：[检测到的风格的信息]
- config/settings.py
- config/constants.py
理由：紧密耦合的配置更改
执行顺序：提交1 -> 提交2 -> 提交3
（遵循依赖：级别0 -> 级别1 -> 级别2 -> ...）
执行前的验证：
如果任何检查失败，不要继续。重新规划。 </atomic_planning>
<strategy_decision>
如果满足以下条件则FIXUP：
- 更改补充现有提交的意图
- 同一功能，修复bug或添加缺失部分
- 纳入审查反馈
- 目标提交存在于本地历史中
如果满足以下条件则新提交：
- 新功能或能力
- 独立的逻辑单元
- 不同的问题/工单
- 不存在合适的目标提交
考虑重置和重建当：
- 历史混乱（已经有很多小fixup）
- 提交不是原子的（混合关注点）
- 依赖顺序错误
重置工作流：
1. git reset --soft $(git merge-base HEAD main)
2. 所有更改现在已暂存
3. 以正确的原子单元重新提交
4. 从头开始清理历史
仅当：
- 所有提交都是本地（未推送）
- 用户明确允许或分支明显是WIP
执行计划：
策略：FIXUP_THEN_NEW | NEW_ONLY | RESET_REBUILD
fixup提交：
- 文件：[...]
目标：<hash>
新提交：
- 文件：[...]
信息："..."
级别：N
需要强制推送：true | false
</strategy_decision>
使用TodoWrite将每个提交注册为可追踪项：
- [ ] Fixup: <描述> -> <目标-hash>
- [ ] 新：<描述>
- [ ] Rebase自动压缩
- [ ] 最终验证
# 为每个fixup暂存文件
git add <files>
git commit --fixup=<target-hash>
# 对所有fixup重复...
# 最后一次性自动压缩rebase
MERGE_BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash $MERGE_BASE
对于每个新提交组，按依赖顺序：
# 暂存文件
git add <file1> <file2> ...
# 验证暂存
git diff --staged --stat
# 使用检测到的风格提交
git commit -m "<信息匹配COMMIT_CONFIG>"
# 验证
git log -1 --oneline
基于Phase 1的COMMIT_CONFIG：
如果风格 == SEMANTIC 且语言 == 韩文：
-> "feat: 로그인 기능 추가"
如果风格 == SEMANTIC 且语言 == 英文：
-> "feat: add login feature"
如果风格 == PLAIN 且语言 == 韩文：
-> "로그인 기능 추가"
如果风格 == PLAIN 且语言 == 英文：
-> "Add login feature"
如果风格 == SHORT：
-> "format" / "type fix" / "lint"
每次提交前的验证：
如果任何检查失败 -> 重写信息。
</execution>
---
## PHASE 6: 验证与清理
<verification>
### 6.1 提交后验证
```bash
# 检查工作目录干净
git status
# 查看新历史
git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)..HEAD
# 验证每个提交是原子的
#（心理检查：每个可以独立回滚吗？）
如果使用了fixup且分支有上游：
-> 需要：git push --force-with-lease
-> 警告用户强制推送的影响
如果仅是新提交：
-> 常规：git push
提交摘要：
策略：<做了什么>
创建的提交：N
合并的fixup：M
历史：
<hash1> <信息1>
<hash2> <信息2>
...
下一步：
- git push [--force-with-lease]
- 如果准备好了则创建PR
| 如果git log显示... | 使用此风格 |
|---|---|
feat: xxx、fix: yyy | SEMANTIC |
Add xxx、Fix yyy、xxx 추가 | PLAIN |
format、lint、typo | SHORT |
| 完整句子 | SENTENCE |
| 上述混合 | 使用多数（默认不是语义式） |
是在main/master上吗？
是 -> 仅新提交，永不重写
否 -> 继续
所有提交都是本地（未推送）吗？
是 -> 允许激进重写
否 -> 谨慎重写（强制推送时警告）
更改是否补充现有提交？
是 -> FIXUP到该提交
否 -> 新提交
历史混乱吗？
是 + 全本地 -> 考虑重置重建
否 -> 正常流程
停止并验证 - 检查所有框后再继续：
[] 文件数检查：N个文件 -> 至少ceil(N/3)个提交？
- 3个文件 -> 至少1个提交
- 5个文件 -> 至少2个提交
- 10个文件 -> 至少4个提交
- 20个文件 -> 至少7个提交
[] 理由检查：对于每个3+个文件的提交，我是否写了为什么？
[] 目录拆分检查：不同目录 -> 不同提交？
[] 测试配对检查：每个测试与其实现配对？
[] 依赖顺序检查：基础先于依赖项？
硬性停止条件：
<rebase_context>
# 并行执行所有
git branch --show-current
git log --oneline -20
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master
git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "NO_UPSTREAM"
git status --porcelain
git stash list
| 条件 | 风险级别 | 操作 |
|---|---|---|
| 在main/master上 | 关键 | 中止 - 永不rebase main |
| 脏的工作目录 | 警告 | 先暂存：git stash push -m "pre-rebase" |
| 存在已推送的提交 | 警告 | 将需要force-push；与用户确认 |
| 所有提交都是本地 | 安全 | 自由继续 |
| 上游已分歧 | 警告 | 可能需要--onto策略 |
用户请求 -> 策略：
"squash commits" / "cleanup" / "정리"
-> 交互式压缩
"rebase on main" / "update branch" / "메인에 리베이스"
-> 基于基础变基
"autosquash" / "apply fixups"
-> 自动压缩
"reorder commits" / "커밋 순서"
-> 交互式重排序
"split commit" / "커밋拆分"
-> 交互式编辑
</rebase_context>
<rebase_execution>
# 找到merge-base
MERGE_BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)
# 开始交互式变基
# 注意：无法交互使用-i。使用GIT_SEQUENCE_EDITOR进行自动化。
# 用于压缩（合并为一个）：
git reset --soft $MERGE_BASE
git commit -m "合并：<总结所有更改>"
# 用于选择性压缩（保留一些，压缩其他）：
# 使用fixup方法 - 标记要压缩的提交，然后自动压缩
# 当你有fixup!或squash!提交时：
MERGE_BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash $MERGE_BASE
# GIT_SEQUENCE_EDITOR=: 技巧自动接受rebase待办事项
# Fixup提交自动合并到其目标
# 场景：你的分支落后于main，需要更新
# 简单变基到main：
git fetch origin
git rebase origin/main
# 复杂：移动提交到不同的基础
# git rebase --onto <newbase> <oldbase> <branch>
git rebase --onto origin/main $(git merge-base HEAD origin/main) HEAD
检测到冲突 -> 工作流：
1. 识别冲突文件：
git status | grep "both modified"
2. 对于每个冲突：
- 读取文件
- 理解两个版本（HEAD vs 传入）
- 通过编辑文件解决
- 移除冲突标记（<<<<、====、>>>>）
3. 暂存已解决的文件：
git add <resolved-file>
4. 继续变基：
git rebase --continue
5. 如果卡住或困惑：
git rebase --abort # 安全回滚
| 情况 | 命令 | 备注 |
|---|---|---|
| 变基出错 | git rebase --abort | 返回到变基前的状态 |
| 需要原始提交 | git reflog -> git reset --hard <hash> | Reflog保留90天 |
| 不小心强制推送 | git reflog -> 与团队协调 | 可能需要通知其他人 |
| 变基后丢失提交 | git fsck --lost-found | 核选项 |
| </rebase_execution> |
<rebase_verify>
# 验证干净状态
git status
# 检查新历史
git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)..HEAD
# 验证代码仍然工作（如果存在测试）
# 运行项目特定的测试命令
# 如需要可与变基前对比
git diff ORIG_HEAD..HEAD --stat
如果分支从未推送：
-> git push -u origin <branch>
如果分支已推送：
-> git push --force-with-lease origin <branch>
-> 始终使用--force-with-lease（不是--force）
-> 防止覆盖他人的工作
</rebase_verify>
变基摘要：
策略：<压缩 | 自动压缩 | ONTO | 重排序>
之前提交：N
之后提交：M
解决的冲突：K
变基后的历史：
<hash1> <信息1>
<hash2> <信息2>
下一步：
- git push --force-with-lease origin <branch>
- 合并前审查更改
<history_search_type>
| 用户请求 | 搜索类型 | 工具 |
|---|---|---|
| "when was X added" / "X가 언제 추가됐어" | 挖掘搜索 | git log -S |
| "find commits changing X pattern" | 正则 | git log -G |
| "who wrote this line" / "이 줄 누가 썼어" | Blame | git blame |
| "when did bug start" / "버그 언제 생겼어" | Bisect | git bisect |
| "history of file" / "파일 히스토리" | 文件日志 | git log -- path |
| "find deleted code" / "삭제된 코드 찾기" | 全挖掘搜索 | git log -S --all |
从用户请求中识别：
- SEARCH_TERM：要查找的字符串/模式
- FILE_SCOPE：特定文件或整个仓库
- TIME_RANGE：所有时间或特定时期
- BRANCH_SCOPE：当前分支或--all分支
</history_search_type>
<history_search_exec>
目的：查找添加或删除特定字符串的提交
# 基础：查找字符串何时添加/删除
git log -S "searchString" --oneline
# 带上下文（查看实际更改）：
git log -S "searchString" -p
# 在特定文件中：
git log -S "searchString" -- path/to/file.py
# 跨所有分支（查找已删除的代码）：
git log -S "searchString" --all --oneline
# 带日期范围：
git log -S "searchString" --since="2024-01-01" --oneline
# 不区分大小写：
git log -S "searchstring" -i --oneline
示例用例：
# 这个函数是何时添加的？
git log -S "def calculate_discount" --oneline
# 这个常量是何时删除的？
git log -S "MAX_RETRY_COUNT" --all --oneline
# 查找谁引入了bug模式
git log -S "== None" -- "*.py" --oneline # 应该是"is None"
目的：查找diff匹配正则模式的提交
# 查找涉及匹配模式的行的提交
git log -G "pattern.*regex" --oneline
# 查找函数定义更改
git log -G "def\s+my_function" --oneline -p
# 查找导入更改
git log -G "^import\s+requests" -- "*.py" --oneline
# 查找TODO添加/删除
git log -G "TODO|FIXME|HACK" --oneline
-S vs -G 区别：
-S "foo": 查找"foo"数量改变的提交
-G "foo": 查找diff包含"foo"的提交
用于-S："X何时添加/删除"
用于-G："哪些提交触及包含X的行"
目的：逐行归属
# 基础blame
git blame path/to/file.py
# 特定行范围
git blame -L 10,20 path/to/file.py
# 显示原始提交（忽略移动/复制）
git blame -C path/to/file.py
# 忽略空白更改
git blame -w path/to/file.py
# 显示邮箱而非名字
git blame -e path/to/file.py
# 可解析的输出格式
git blame --porcelain path/to/file.py
读取Blame输出：
^abc1234 (Author Name 2024-01-15 10:30:00 +0900 42) code_line_here
| | | | +-- 行内容
| | | +-- 行号
| | +-- 时间戳
| +-- 作者
+-- 提交哈希（^表示初始提交）
目的：找出引入bug的确切提交
# 开始bisect会话
git bisect start
# 标记当前（坏）状态
git bisect bad
# 标记已知好的提交（例如上次发布）
git bisect good v1.0.0
# Git检出中间提交。测试它，然后：
git bisect good # 如果此提交正常
git bisect bad # 如果此提交有bug
# 重复直到git找到罪魁祸首提交
# Git将输出："abc1234是第一个坏提交"
# 完成后，返回原始状态
git bisect reset
自动化Bisect（带测试脚本）：
# 如果你有一个在bug上失败的测试：
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
git bisect run pytest tests/test_specific.py
# Git自动在每个提交上运行测试
# 退出0 = 好，退出1-127 = 坏，退出125 = 跳过
# 文件的完整历史
git log --oneline -- path/to/file.py
# 跟踪跨重命名的文件
git log --follow --oneline -- path/to/file.py
# 显示实际更改
git log -p -- path/to/file.py
# 不再存在的文件
git log --all --full-history -- "**/deleted_file.py"
# 谁最常更改文件
git shortlog -sn -- path/to/file.py
</history_search_exec>
<history_results>
搜索查询："<用户所问>"
搜索类型：<挖掘搜索 | 正则 | Blame | Bisect | 文件日志>
使用的命令：git log -S "..." ...
结果：
提交 日期 信息
--------- ---------- --------------------------------
abc1234 2024-06-15 feat: 添加折扣计算
def5678 2024-05-20 refactor: 提取定价逻辑
最相关的提交：abc1234
详情：
作者：John Doe <john@example.com>
日期：2024-06-15
更改的文件：3
差异摘录（如适用）：
+ def calculate_discount(price, rate):
+ return price * (1 - rate)
根据搜索结果，提供相关的后续操作：
发现提交abc1234引入了此更改。
可能的操作：
- 查看完整提交：git show abc1234
- 还原此提交：git revert abc1234
- 查看相关提交：git log --ancestry-path abc1234..HEAD
- cherry-pick到另一个分支：git cherry-pick abc1234
</history_results>
| 目标 | 命令 |
|---|---|
| 何时添加"X"？ | git log -S "X" --oneline |
| 何时删除"X"？ | git log -S "X" --all --oneline |
| 哪些提交触及"X"？ | git log -G "X" --oneline |
| 谁写了第N行？ | git blame -L N,N file.py |
| bug何时开始？ | git bisect start && git bisect bad && git bisect good <tag> |
| 文件历史 | git log --follow -- path/file.py |
| 查找已删除的文件 | git log --all --full-history -- "**/filename" |
| 文件的作者统计 | git shortlog -sn -- path/file.py |
--force而非--force-with-lease -> 危险-S时用-G -> 错误结果-C使用blame -> 错误的归属只读GitHub分类（适用于issues和PRs）。每个项目1个后台任务（category: quick）。分析所有开放项目并将有证据支持的报告写入/tmp/{datetime}/。每个声明都需要GitHub永久链接作为证明。永不對GitHub执行任何操作 - 无评论、无合并、无关闭、无标签。仅为报告。触发词：'triage', 'triage issues', 'triage PRs', 'github triage'。
核弹级16代理预发布门禁。运行/get-unpublished-changes检测自上次npm发布以来的所有更改，为每个更改生成最多10个ultrabrain代理进行深入分析，调用/review-work（5个代理）进行整体审查，以及1个oracle进行整体发布合成。每次npm发布前使用。触发词：'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'。
完整PR生命周期：git worktree → 实现 → 原子提交 → PR创建 → 验证循环（CI + review-work + Cubic审批）→ 合并。持续迭代直到所有门禁通过并PR被合并。合并后自动清理worktree。当实现工作需要作为PR落地时使用。触发词：'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'work-with-pr', 'PR workflow', 'implement end to end'，甚至当用户只是说'implement X'但上下文暗示需要PR交付时。
自动化浏览器交互，用于网页测试、表单填写、截图和数据提取。当用户需要导航网站、与网页交互、填写表单、截图、测试网页应用或从网页中提取信息时使用。
Browser automation with persistent page state. Use when users ask to navigate websites, fill forms, take screenshots, extract web data, test web apps, or automate browser workflows. Trigger phrases include "go to [url]", "click on", "fill out the form", "take a screenshot", "scrape", "automate", "test the website", "log into", or any browser interaction request.
设计师转型的开发者，即使没有设计稿也能打造令人惊艳的 UI/UX