work-with-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Work With PR — Full PR Lifecycle

Work With PR — 完整PR生命周期

You are executing a complete PR lifecycle: from isolated worktree setup through implementation, PR creation, and an unbounded verification loop until the PR is merged. The loop has three gates — CI, review-work, and Cubic — and you keep fixing and pushing until all three pass simultaneously.

Phase 0: Setup         → Branch + worktree in sibling directory
Phase 1: Implement     → Do the work, atomic commits
Phase 2: PR Creation   → Push, create PR targeting dev
Phase 3: Verify Loop   → Unbounded iteration until ALL gates pass:
  ├─ Gate A: CI         → gh pr checks (bun test, typecheck, build)
  ├─ Gate B: review-work → 5-agent parallel review
  └─ Gate C: Cubic      → cubic-dev-ai[bot] "No issues found"
Phase 4: Merge         → Squash merge, worktree cleanup

</architecture>

你将执行完整的PR生命周期：从搭建独立worktree开始，到功能实现、创建PR，再到无限制的验证循环，直至PR合并完成。该循环包含三个检查环节——CI、review-work和Cubic，你需要不断修复并推送代码，直至三个环节同时通过。

Phase 0: Setup         → Branch + worktree in sibling directory
Phase 1: Implement     → Do the work, atomic commits
Phase 2: PR Creation   → Push, create PR targeting dev
Phase 3: Verify Loop   → Unbounded iteration until ALL gates pass:
  ├─ Gate A: CI         → gh pr checks (bun test, typecheck, build)
  ├─ Gate B: review-work → 5-agent parallel review
  └─ Gate C: Cubic      → cubic-dev-ai[bot] "No issues found"
Phase 4: Merge         → Squash merge, worktree cleanup

</architecture>

Phase 0: Setup

阶段0：环境搭建

Create an isolated worktree so the user's main working directory stays clean. This matters because the user may have uncommitted work, and checking out a branch would destroy it.

<setup>

创建独立的worktree，确保用户的主工作目录保持整洁。这一点很重要，因为用户可能存在未提交的工作，切换分支会导致这些工作丢失。

<setup>

1. Resolve repository context

1. 解析仓库上下文

bash

REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
REPO_NAME=$(basename "$PWD")
BASE_BRANCH="dev"  # CI blocks PRs to master

bash

REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
REPO_NAME=$(basename "$PWD")
BASE_BRANCH="dev"  # CI blocks PRs to master

2. Create branch

2. 创建分支

If user provides a branch name, use it. Otherwise, derive from the task:

bash

undefined

如果用户提供了分支名称，则使用该名称；否则，根据任务自动生成：

bash

undefined

Auto-generate: feature/short-description or 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"

undefined

BRANCH_NAME="feature/$(echo "$TASK_SUMMARY" | tr '[:upper:] ' '[:lower:]-' | head -c 50)" git fetch origin "$BASE_BRANCH" git branch "$BRANCH_NAME" "origin/$BASE_BRANCH"

undefined

3. Create worktree

3. 创建worktree

Place worktrees as siblings to the repo — not inside it. This avoids git nested repo issues and keeps the working tree clean.

bash

WORKTREE_PATH="../${REPO_NAME}-wt/${BRANCH_NAME}"
mkdir -p "$(dirname "$WORKTREE_PATH")"
git worktree add "$WORKTREE_PATH" "$BRANCH_NAME"

将worktree放置在仓库的同级目录下——而非仓库内部。这样可以避免Git嵌套仓库问题，同时保持工作树整洁。

bash

WORKTREE_PATH="../${REPO_NAME}-wt/${BRANCH_NAME}"
mkdir -p "$(dirname "$WORKTREE_PATH")"
git worktree add "$WORKTREE_PATH" "$BRANCH_NAME"

4. Set working context

4. 设置工作上下文

All subsequent work happens inside the worktree. Install dependencies if needed:

bash

cd "$WORKTREE_PATH"

后续所有操作均在该worktree内进行。如有需要，安装依赖：

bash

cd "$WORKTREE_PATH"

If bun project:

[ -f "bun.lock" ] && bun install


</setup>

---

[ -f "bun.lock" ] && bun install


</setup>

---

Phase 1: Implement

阶段1：功能实现

Do the actual implementation work inside the worktree. The agent using this skill does the work directly — no subagent delegation for the implementation itself.

Scope discipline: For bug fixes, stay minimal. Fix the bug, add a test for it, done. Do not refactor surrounding code, add config options, or "improve" things that aren't broken. The verification loop will catch regressions — trust the process.

在worktree内完成实际的功能开发工作。使用本技能的Agent将直接执行开发任务——不会将实现工作委托给子Agent。

范围规范：对于Bug修复，保持最小改动。修复Bug，添加对应的测试即可。不要重构周边代码、添加配置项或“优化”原本正常的功能。验证循环会捕获回归问题——请信任该流程。

Commit strategy

提交策略

Use the git-master skill's atomic commit principles. The reason for atomic commits: if CI fails on one change, you can isolate and fix it without unwinding everything.

3+ files changed  → 2+ commits minimum
5+ files changed  → 3+ commits minimum
10+ files changed → 5+ commits minimum

Each commit should pair implementation with its tests. Load

git-master

skill when committing:

task(category="quick", load_skills=["git-master"], prompt="Commit the changes atomically following git-master conventions. Repository is at {WORKTREE_PATH}.")

遵循git-master技能的原子提交原则。采用原子提交的原因：如果CI在某一项更改上失败，你可以单独定位并修复问题，无需回滚所有改动。

3+ files changed  → 2+ commits minimum
5+ files changed  → 3+ commits minimum
10+ files changed → 5+ commits minimum

每个提交应将实现代码与对应的测试配对。提交时加载

git-master

技能：

task(category="quick", load_skills=["git-master"], prompt="Commit the changes atomically following git-master conventions. Repository is at {WORKTREE_PATH}.")

Pre-push local validation

推送前本地验证

Before pushing, run the same checks CI will run. Catching failures locally saves a full CI round-trip (~3-5 min):

bash

bun run typecheck
bun test
bun run build

Fix any failures before pushing. Each fix-commit cycle should be atomic.

</implementation>

推送代码前，运行CI将执行的相同检查。在本地提前发现问题可以节省完整CI循环的时间（约3-5分钟）：

bash

bun run typecheck
bun test
bun run build

推送前修复所有问题。每次修复-提交循环都应保持原子性。

</implementation>

Phase 2: PR Creation

阶段2：创建PR

<pr_creation>

Push and create PR

推送代码并创建PR

bash

git push -u origin "$BRANCH_NAME"

Create the PR using the project's template structure:

bash

gh pr create \
  --base "$BASE_BRANCH" \
  --head "$BRANCH_NAME" \
  --title "$PR_TITLE" \
  --body "$(cat <<'EOF'

bash

git push -u origin "$BRANCH_NAME"

使用项目的模板结构创建PR：

bash

gh pr create \
  --base "$BASE_BRANCH" \
  --head "$BRANCH_NAME" \
  --title "$PR_TITLE" \
  --body "$(cat <<'EOF'

Summary

[1-3 sentences describing what this PR does and why]

Changes

[Bullet list of key changes]

Testing

```
bun run typecheck
```
✅
```
bun test
```
✅
```
bun run build
```
✅

```
bun run typecheck
```
✅
```
bun test
```
✅
```
bun run build
```
✅

Related Issues

[Link to issue if applicable] EOF )"


Capture the PR number:

```bash
PR_NUMBER=$(gh pr view --json number -q .number)

</pr_creation>

[Link to issue if applicable] EOF )"


捕获PR编号：

```bash
PR_NUMBER=$(gh pr view --json number -q .number)

</pr_creation>

Phase 3: Verification Loop

阶段3：验证循环

This is the core of the skill. Three gates must ALL pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest, review-work is most thorough, Cubic is external and asynchronous.

<verify_loop>

while true:
  1. Wait for CI          → Gate A
  2. If CI fails          → read logs, fix, commit, push, continue
  3. Run review-work      → Gate B
  4. If review fails      → fix blocking issues, commit, push, continue
  5. Check Cubic          → Gate C
  6. If Cubic has issues   → fix issues, commit, push, continue
  7. All three pass       → break

这是本技能的核心部分。PR准备就绪前必须通过三个检查环节。该循环无迭代次数限制——直至所有环节通过为止。环节顺序经过精心设计：CI成本最低、速度最快，review-work最全面，Cubic是外部异步检查。

<verify_loop>

while true:
  1. Wait for CI          → Gate A
  2. If CI fails          → read logs, fix, commit, push, continue
  3. Run review-work      → Gate B
  4. If review fails      → fix blocking issues, commit, push, continue
  5. Check Cubic          → Gate C
  6. If Cubic has issues   → fix issues, commit, push, continue
  7. All three pass       → break

Gate A: CI Checks

环节A：CI检查

CI is the fastest feedback loop. Wait for it to complete, then parse results.

bash

undefined

CI是最快的反馈循环。等待CI完成后解析结果。

bash

undefined

Wait for checks to start (GitHub needs a moment after push)

Then watch for completion

gh pr checks "$PR_NUMBER" --watch --fail-fast


**On failure**: Get the failed run logs to understand what broke:

```bash

gh pr checks "$PR_NUMBER" --watch --fail-fast


**失败处理**：获取失败运行的日志以定位问题：

```bash

Find the failed run

RUN_ID=$(gh run list --branch "$BRANCH_NAME" --status failure --json databaseId --jq '.[0].databaseId')

Get failed job logs

gh run view "$RUN_ID" --log-failed


Read the logs, fix the issue, commit atomically, push, and re-enter the loop.

gh run view "$RUN_ID" --log-failed


阅读日志、修复问题、原子提交、推送代码，然后重新进入循环。

Gate B: review-work

环节B：review-work评审

The review-work skill launches 5 parallel sub-agents (goal verification, QA, code quality, security, context mining). All 5 must pass.

Invoke review-work after CI passes — there's no point reviewing code that doesn't build:

task(
  category="unspecified-high",
  load_skills=["review-work"],
  run_in_background=false,
  description="Post-implementation review of PR changes",
  prompt="Review the implementation work on branch {BRANCH_NAME}. The worktree is at {WORKTREE_PATH}. Goal: {ORIGINAL_GOAL}. Constraints: {CONSTRAINTS}. Run command: bun run dev (or as appropriate)."
)

On failure: review-work reports blocking issues with specific files and line numbers. Fix each blocking issue, commit, push, and re-enter the loop from Gate A (since code changed, CI must re-run).

review-work技能会启动5个并行子Agent（目标验证、QA、代码质量、安全、上下文挖掘）。所有5个Agent必须通过评审。

在CI通过后再调用review-work——评审无法构建的代码毫无意义：

task(
  category="unspecified-high",
  load_skills=["review-work"],
  run_in_background=false,
  description="Post-implementation review of PR changes",
  prompt="Review the implementation work on branch {BRANCH_NAME}. The worktree is at {WORKTREE_PATH}. Goal: {ORIGINAL_GOAL}. Constraints: {CONSTRAINTS}. Run command: bun run dev (or as appropriate)."
)

失败处理：review-work会报告带有具体文件和行号的阻塞问题。修复每个阻塞问题、提交、推送代码，然后从环节A重新进入循环（由于代码变更，必须重新运行CI）。

Gate C: Cubic Approval

环节C：Cubic审核

Cubic (

cubic-dev-ai[bot]

) is an automated review bot that comments on PRs. It does NOT use GitHub's APPROVED review state — instead it posts comments with issue counts and confidence scores.

Approval signal: The latest Cubic comment contains

**No issues found**

and confidence

**5/5**

Issue signal: The comment lists issues with file-level detail.

bash

undefined

Cubic（

cubic-dev-ai[bot]

）是一款自动评审机器人，会在PR下发表评论。它不使用GitHub的“已批准”评审状态——而是发布包含问题数量和置信度得分的评论。

审核通过信号：最新的Cubic评论包含

**No issues found**

且置信度为

**5/5**

。

问题信号：评论中会列出带有文件级细节的问题。

bash

undefined

Get the latest Cubic review

CUBIC_REVIEW=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews"
--jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .body')

Check if approved

if echo "$CUBIC_REVIEW" | grep -q "No issues found"; then echo "Cubic: APPROVED" else echo "Cubic: ISSUES FOUND" echo "$CUBIC_REVIEW" fi


**On issues**: Cubic's review body contains structured issue descriptions. Parse them, determine which are valid (some may be false positives), fix the valid ones, commit, push, re-enter from Gate A.

Cubic reviews are triggered automatically on PR updates. After pushing a fix, wait for the new review to appear before checking again. Use `gh api` polling with a conditional loop:

```bash

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`轮询和条件循环：

```bash

Wait for new Cubic review after push

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

Use gh api call itself as the delay mechanism — each call takes ~1-2s

For longer waits, use: timeout 30 gh pr checks "$PR_NUMBER" --watch 2>/dev/null || true

done

undefined

Use gh api call itself as the delay mechanism — each call takes ~1-2s

For longer waits, use: timeout 30 gh pr checks "$PR_NUMBER" --watch 2>/dev/null || true

done

undefined

Iteration discipline

迭代规范

Each iteration through the loop:

Fix ONLY the issues identified by the failing gate
Commit atomically (one logical fix per commit)
Push
Re-enter from Gate A (code changed → full re-verification)

Avoid the temptation to "improve" unrelated code during fix iterations. Scope creep in the fix loop makes debugging harder and can introduce new failures.

</verify_loop>

每次循环迭代：

仅修复当前失败环节指出的问题
原子提交（每个提交对应一个逻辑修复）
推送代码
从环节A重新进入循环（代码变更后必须重新验证CI）

避免在修复迭代中“优化”无关代码。修复循环中的范围蔓延会增加调试难度，并可能引入新的故障。

</verify_loop>

Phase 4: Merge & Cleanup

阶段4：合并与清理

Once all three gates pass:

<merge_cleanup>

当三个环节全部通过后：

<merge_cleanup>

Merge the PR

合并PR

bash

undefined

bash

undefined

Squash merge to keep history clean

gh pr merge "$PR_NUMBER" --squash --delete-branch

undefined

gh pr merge "$PR_NUMBER" --squash --delete-branch

undefined

Sync .sisyphus state back to main repo

将.sisyphus状态同步回主仓库

Before removing the worktree, copy

.sisyphus/

state back. When

.sisyphus/

is gitignored, files written there during worktree execution are not committed or merged — they would be lost on worktree removal.

bash

undefined

删除worktree前，将

.sisyphus/

状态复制回主仓库。当

.sisyphus/

被Git忽略时，在worktree执行期间写入的文件不会被提交或合并——删除worktree后这些文件会丢失。

bash

undefined

Sync .sisyphus state from worktree to main repo (preserves task state, plans, notepads)

if [ -d "$WORKTREE_PATH/.sisyphus" ]; then mkdir -p "$ORIGINAL_DIR/.sisyphus" cp -r "$WORKTREE_PATH/.sisyphus/"* "$ORIGINAL_DIR/.sisyphus/" 2>/dev/null || true fi

undefined

if [ -d "$WORKTREE_PATH/.sisyphus" ]; then mkdir -p "$ORIGINAL_DIR/.sisyphus" cp -r "$WORKTREE_PATH/.sisyphus/"* "$ORIGINAL_DIR/.sisyphus/" 2>/dev/null || true fi

undefined

Clean up the worktree

清理worktree

The worktree served its purpose — remove it to avoid disk bloat:

bash

cd "$ORIGINAL_DIR"  # Return to original working directory
git worktree remove "$WORKTREE_PATH"

worktree已完成使命——删除它以避免磁盘占用过高：

bash

cd "$ORIGINAL_DIR"  # Return to original working directory
git worktree remove "$WORKTREE_PATH"

Prune any stale worktree references

git worktree prune

undefined

git worktree prune

undefined

Report completion

报告完成状态

Summarize what happened:

undefined

总结执行情况：

undefined

PR Merged ✅

PR: #{PR_NUMBER} — {PR_TITLE}
Branch: {BRANCH_NAME} → {BASE_BRANCH}
Iterations: {N} verification loops
Gates passed: CI ✅ | review-work ✅ | Cubic ✅
Worktree: cleaned up


</merge_cleanup>

---

PR: #{PR_NUMBER} — {PR_TITLE}
Branch: {BRANCH_NAME} → {BASE_BRANCH}
Iterations: {N} verification loops
Gates passed: CI ✅ | review-work ✅ | Cubic ✅
Worktree: cleaned up


</merge_cleanup>

---

Failure Recovery

故障恢复

<failure_recovery>

If you hit an unrecoverable error (e.g., merge conflict with base branch, infrastructure failure):

Do NOT delete the worktree — the user may want to inspect or continue manually
Report what happened, what was attempted, and where things stand
Include the worktree path so the user can resume

For merge conflicts:

bash

cd "$WORKTREE_PATH"
git fetch origin "$BASE_BRANCH"
git rebase "origin/$BASE_BRANCH"

<failure_recovery>

如果遇到无法恢复的错误（如与基准分支的合并冲突、基础设施故障）：

不要删除worktree——用户可能需要检查或手动继续
报告故障情况、已尝试的操作和当前状态
提供worktree路径以便用户恢复工作

对于合并冲突：

bash

cd "$WORKTREE_PATH"
git fetch origin "$BASE_BRANCH"
git rebase "origin/$BASE_BRANCH"

Resolve conflicts, then continue the loop


</failure_recovery>

---


</failure_recovery>

---

Anti-Patterns

反模式

Violation	Why it fails	Severity
Working in main worktree instead of isolated worktree	Pollutes user's working directory, may destroy uncommitted work	CRITICAL
Pushing directly to dev/master	Bypasses review entirely	CRITICAL
Skipping CI gate after code changes	review-work and Cubic may pass on stale code	CRITICAL
Fixing unrelated code during verification loop	Scope creep causes new failures	HIGH
Deleting worktree on failure	User loses ability to inspect/resume	HIGH
Ignoring Cubic false positives without justification	Cubic issues should be evaluated, not blindly dismissed	MEDIUM
Giant single commits	Harder to isolate failures, violates git-master principles	MEDIUM
Not running local checks before push	Wastes CI time on obvious failures	MEDIUM

违规行为	失败原因	严重程度
在主工作树而非独立worktree中操作	污染用户的主工作目录，可能导致未提交工作丢失	严重
直接推送到dev/master分支	完全绕过评审流程	严重
代码变更后跳过CI环节	review-work和Cubic可能基于过时代码通过评审	严重
在验证循环中修复无关代码	范围蔓延会引入新故障	高
故障时删除worktree	用户失去检查/恢复工作的能力	高
无正当理由忽略Cubic误报	应评估Cubic指出的问题，而非盲目忽略	中
单个巨型提交	难以隔离故障，违反git-master原则	中
推送前不运行本地检查	将CI时间浪费在明显的故障上	中