work-with-pr

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"  # CI阻止到master的PR

2. 创建分支

如果用户提供了分支名称，使用它。否则，从任务派生：

# 自动生成: feature/short-description 或 fix/short-description
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"
# 如果是bun项目:
[ -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是最快的反馈循环。等待它完成，然后解析结果。

# 等待检查开始（GitHub在推送后需要一点时间）
# 然后监视完成
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审查
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轮询：

# 推送后等待新的Cubic审查
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
  # 使用gh api调用本身作为延迟机制 — 每次调用需要约1-2秒
  # 对于更长的等待，使用: timeout 30 gh pr checks "$PR_NUMBER" --watch 2>/dev/null || true
done

迭代纪律

每次通过循环：

1. 只修复失败门禁识别的问题
2. 原子提交（每个逻辑修复一个提交）
3. 推送
4. 从门禁A重新进入（代码更改 → 完整重新验证）

避免在修复迭代中"改进"无关代码的诱惑。修复循环中的范围蔓延会使调试更难，并可能导致新的失败。

</verify_loop>

---

阶段 4: 合并和清理

一旦三个门禁全部通过：

<merge_cleanup>

合并PR

# 压缩合并以保持历史干净
gh pr merge "$PR_NUMBER" --squash --delete-branch

同步.sisyphus状态回主仓库

在移除worktree之前，将.sisyphus/状态复制回来。当.sisyphus/被gitignored时，在worktree执行期间写入的文件不会被提交或合并 — 它们会在worktree移除时丢失。

# 将.sisyphus状态从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"
# 修剪任何过时的worktree引用
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>

如果您遇到不可恢复的错误（例如，与基础分支的合并冲突、基础设施故障）：

1. 不要删除worktree — 用户可能想要检查或手动继续
2. 报告发生了什么，尝试了什么，以及当前状态
3. 包含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