| name | work-with-pr |
| description | 完整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交付时。 |
Work With PR — 完整PR生命周期
您正在执行一个完整的PR生命周期：从隔离的worktree设置，到实现、PR创建，再到无限制的验证循环，直到PR被合并。循环有三个门禁 — CI、review-work和Cubic — 您不断修复和推送直到三个同时通过。
阶段 0: 设置 → 分支 + 同级目录中的worktree
阶段 1: 实现 → 做工作，原子提交
阶段 2: PR创建 → 推送，创建PR目标为dev
阶段 3: 验证循环 → 无限制迭代直到所有门禁通过：
├─ 门禁 A: CI → gh pr checks（bun test, typecheck, build）
├─ 门禁 B: review-work → 5个代理并行审查
└─ 门禁 C: Cubic → cubic-dev-ai[bot] "No issues found"
阶段 4: 合并 → 压缩合并，worktree清理
阶段 0: 设置
创建一个隔离的worktree以保持用户的主工作目录干净。这很重要，因为用户可能有未提交的工作，而检出分支会破坏它。
1. 解析仓库上下文
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
REPO_NAME=$(basename "$PWD")
BASE_BRANCH="dev"
2. 创建分支
如果用户提供了分支名称，使用它。否则，从任务派生：
BRANCH_NAME="feature/$(echo "$TASK_SUMMARY" | tr '[:upper:] ' '[:lower:]-' | head -c 50)"
git fetch origin "$BASE_BRANCH"
git branch "$BRANCH_NAME" "origin/$BASE_BRANCH"
3. 创建worktree
将worktree放置为仓库的同级目录 — 不要放在内部。这可以避免git嵌套仓库问题并保持工作树干净。
WORKTREE_PATH="../${REPO_NAME}-wt/${BRANCH_NAME}"
mkdir -p "$(dirname "$WORKTREE_PATH")"
git worktree add "$WORKTREE_PATH" "$BRANCH_NAME"
4. 设置工作上下文
所有后续工作在worktree内进行。如需要安装依赖：
cd "$WORKTREE_PATH"
[ -f "bun.lock" ] && bun install
阶段 1: 实现
在worktree内完成实际的实现工作。使用此技能的代理直接完成工作 — 不使用子代理进行实现本身。
范围纪律：对于bug修复，保持最小化。修复bug，添加测试，完成。不要重构周围代码，添加配置选项，或"改进"没有坏掉的东西。验证循环会捕获回归 — 信任流程。
提交策略
使用git-master技能的原子提交原则。原子提交的原因：如果一个更改导致CI失败，您可以隔离并修复它而不需要撤销一切。
3+ 文件更改 → 至少2个提交
5+ 文件更改 → 至少3个提交
10+ 文件更改 → 至少5个提交
每个提交应该将实现与其测试配对。提交时加载git-master技能：
task(category="quick", load_skills=["git-master"], prompt="遵循git-master约定原子提交更改。仓库位置为{WORKTREE_PATH}。")
推送前的本地验证
在推送之前，运行CI将运行的相同检查。在本地捕获失败可节省完整的CI往返（约3-5分钟）：
bun run typecheck
bun test
bun run build
在推送前修复任何失败。每次修复-提交循环应该是原子的。
阶段 2: PR创建
<pr_creation>
推送并创建PR
git push -u origin "$BRANCH_NAME"
使用项目的模板结构创建PR：
gh pr create \
--base "$BASE_BRANCH" \
--head "$BRANCH_NAME" \
--title "$PR_TITLE" \
--body "$(cat <<'EOF'
## Summary
[1-3句话描述此PR做了什么以及为什么]
## Changes
[关键更改的列表]
## Testing
- `bun run typecheck` ✅
- `bun test` ✅
- `bun run build` ✅
## Related Issues
[如果适用，链接到issue]
EOF
)"
捕获PR编号：
PR_NUMBER=$(gh pr view --json number -q .number)
</pr_creation>
阶段 3: 验证循环
这是技能的核心。三个门禁必须全部通过PR才能准备就绪。循环没有迭代上限 — 持续直到完成。门禁顺序是故意的：CI最便宜/最快，review-work最彻底，Cubic是外部的且异步的。
<verify_loop>
while true:
1. 等待CI → 门禁 A
2. 如果CI失败 → 读取日志，修复，提交，推送，继续
3. 运行review-work → 门禁 B
4. 如果review失败 → 修复阻塞问题，提交，推送，继续
5. 检查Cubic → 门禁 C
6. 如果Cubic有问题 → 修复问题，提交，推送，继续
7. 三个全部通过 → 退出
门禁 A: CI检查
CI是最快的反馈循环。等待它完成，然后解析结果。
gh pr checks "$PR_NUMBER" --watch --fail-fast
失败时：获取失败的运行日志以了解什么出了问题：
RUN_ID=$(gh run list --branch "$BRANCH_NAME" --status failure --json databaseId --jq '.[0].databaseId')
gh run view "$RUN_ID" --log-failed
阅读日志，原子地修复问题，推送，然后重新进入循环。
门禁 B: review-work
review-work技能启动5个并行子代理（目标验证、QA、代码质量、安全、上下文挖掘）。所有5个必须通过。
在CI通过后调用review-work — 在无法构建的代码上审查没有意义：
task(
category="unspecified-high",
load_skills=["review-work"],
run_in_background=false,
description="Post-implementation review of PR changes",
prompt="审查{BRANCH_NAME}分支上的实现工作。worktree在{WORKTREE_PATH}。目标：{ORIGINAL_GOAL}。约束：{CONSTRAINTS}。运行命令：bun run dev（或适当的话）。"
)
失败时：review-work报告具有特定文件和行号的阻塞问题。修复每个阻塞问题，提交，推送，然后从门禁A重新进入循环（因为代码更改了，CI必须重新运行）。
门禁 C: Cubic审批
Cubic（cubic-dev-ai[bot]）是一个自动化审查机器人，会在PR上发表评论。它不使用GitHub的APPROVED审查状态 — 而是发布包含问题数量和置信度评分的评论。
审批信号：最新的Cubic评论包含**No issues found**和置信度**5/5**。
问题信号：评论列出具有文件级详情的问题。
CUBIC_REVIEW=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
--jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .body')
if echo "$CUBIC_REVIEW" | grep -q "No issues found"; then
echo "Cubic: APPROVED"
else
echo "Cubic: ISSUES FOUND"
echo "$CUBIC_REVIEW"
fi
有问题时：Cubic的审查主体包含结构化的问题描述。解析它们，确定哪些是有效的（可能是误报），修复有效的，从门禁A重新进入。
Cubic审查会在PR更新时自动触发。推送修复后，在再次检查之前等待新审查出现。使用带条件循环的gh api轮询：
PUSH_TIME=$(date -u +%Y-%m-%dT%H:%M:%SZ)
while true; do
LATEST_REVIEW_TIME=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
--jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .submitted_at')
if [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]]; then
break
fi
done
迭代纪律
每次通过循环：
- 只修复失败门禁识别的问题
- 原子提交（每个逻辑修复一个提交）
- 推送
- 从门禁A重新进入（代码更改 → 完整重新验证）
避免在修复迭代中"改进"无关代码的诱惑。修复循环中的范围蔓延会使调试更难，并可能导致新的失败。
</verify_loop>
阶段 4: 合并和清理
一旦三个门禁全部通过：
<merge_cleanup>
合并PR
gh pr merge "$PR_NUMBER" --squash --delete-branch
同步.sisyphus状态回主仓库
在移除worktree之前，将.sisyphus/状态复制回来。当.sisyphus/被gitignored时，在worktree执行期间写入的文件不会被提交或合并 — 它们会在worktree移除时丢失。
if [ -d "$WORKTREE_PATH/.sisyphus" ]; then
mkdir -p "$ORIGINAL_DIR/.sisyphus"
cp -r "$WORKTREE_PATH/.sisyphus/"* "$ORIGINAL_DIR/.sisyphus/" 2>/dev/null || true
fi
清理worktree
worktree已经完成了它的用途 — 移除它以避免磁盘膨胀：
cd "$ORIGINAL_DIR"
git worktree remove "$WORKTREE_PATH"
git worktree prune
报告完成
总结发生的事情：
## PR Merged ✅
- **PR**: #{PR_NUMBER} — {PR_TITLE}
- **Branch**: {BRANCH_NAME} → {BASE_BRANCH}
- **Iterations**: {N} 验证循环
- **Gates passed**: CI ✅ | review-work ✅ | Cubic ✅
- **Worktree**: 已清理
</merge_cleanup>
失败恢复
<failure_recovery>
如果您遇到不可恢复的错误（例如，与基础分支的合并冲突、基础设施故障）：
- 不要删除worktree — 用户可能想要检查或手动继续
- 报告发生了什么，尝试了什么，以及当前状态
- 包含worktree路径以便用户可以恢复
对于合并冲突：
cd "$WORKTREE_PATH"
git fetch origin "$BASE_BRANCH"
git rebase "origin/$BASE_BRANCH"
</failure_recovery>
反模式
| 违反 | 为什么失败 | 严重性 |
|---|
| 在主worktree而不是隔离的worktree中工作 | 污染用户的工作目录，可能破坏未提交的工作 | CRITICAL |
| 直接推送到dev/master | 完全绕过审查 | CRITICAL |
| 代码更改后跳过CI门禁 | review-work和Cubic可能在陈旧代码上通过 | CRITICAL |
| 在验证循环期间修复无关代码 | 范围蔓延导致新的失败 | HIGH |
| 失败时删除worktree | 用户失去检查/恢复的能力 | HIGH |
| 不评估Cubic误报就忽略 | Cubic问题应该被评估，而不是盲目忽略 | MEDIUM |
| 巨大的单一提交 | 更难隔离失败，违反git-master原则 | MEDIUM |
| 推送前不运行本地检查 | 在明显失败上浪费CI时间 | MEDIUM |
