用途：该技能只负责 main → builds/dev/<app> 的单向同步。当需要为某个 app 部署 QA、而 main 到 builds/dev/<app> 无法 fast-forward 时使用；冲突在临时的 sync/main-to-dev-<app> 分支上解决，再反向合并回对应的 builds/dev/<app>。release 到 prod、cut release、cherry-pick hotfix 等流程不在范围内，资料称这些场景几乎不冲突、频率低，由 Maintainer 手动处理。
主要能力：列出仓库中的 builds/dev/* 分支供选择；验证目标 app 是否存在；判断是否真的需要同步；创建 sync 分支并合并目标以暴露冲突；按规则解决冲突（逻辑代码保留 main，QA 专属配置如 API 地址、debug flag 保留 builds/dev 一侧）；提交并推送后创建 MR；支持一次同步多个 app；还可审计 builds/dev/* 是否存在直接提交等违反单向规则的行为，并列出违规 commit 给出清理建议。
使用方式：主要触发语包括“sync main to dev-<app>”“sync main 到 builds/dev/...”“resolve conflict builds/dev/...”等。会用到 git 与 glab（GitLab CLI，安装参考 https://gitlab.com/gitlab-org/cli）。流程上先 git fetch --all --prune 并用 git ls-remote 确认分支存在，然后 git checkout main、git pull origin main、git checkout -b sync/main-to-dev-<app>、git merge origin/builds/dev/<app>，解决后以 chore(sync) 格式提交；推送前必须经用户确认，再执行 git push -u origin sync/main-to-dev-<app>，最后用 glab mr create 以 --target-branch builds/dev/<app> 创建 MR，并带 --remove-source-branch。多 app 场景按 app 逐个串行处理，不共用同一个 sync 分支。
限制与安全规则：禁止直接提交到 builds/dev/，禁止任何形式的 builds/dev/ → main 合并，禁止直接把 feature 合并到 builds/dev/；禁止对 main 或 builds/dev/ 强制推送，禁止用 --strategy=ours 伪装解决冲突；不确定该保留哪一侧时必须先询问用户，尤其涉及配置、.env、路由定义文件。冲突提交信息不使用 feat/fix 类型，也不添加 Co-Authored-By 行。审计发现违规 commit 时仅提出 cherry-pick 或 reset 建议，不自动执行 force-push。命令与安装方式保持原样，具体触发词与命令示例以资料为准。