[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XC8DWHPJ6BFJS9K4HTW3SE":3,"skill-same:01M6XC8DWHPJ6BFJS9K4HTW3SE":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":33,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6XC8DWHPJ6BFJS9K4HTW3SE","merge-flow",null,"Merge a batch of approved workbuddy PRs into main: order them, resolve conflicts against design intent, validate post-merge health, and report. Use when the user asks to 'merge the batch', 'merge approved PRs', 'integrate finished issues', '批量合并', '处理冲突'; or when the merge-agent is invoked.","Lincyaw\u002Fworkbuddy","Lincyaw","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F53161583?v=4","01M6XC87YTNETZ3AARKMHXJYJR","Aoyang Fang","01M6XC882ZSY5XBX2W6S88AGNH",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002F.claude\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fmerge-flow\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"merge","merge flow","flow","resolve conflicts","design","when","prs","design intent","post","main","intent","conflicts","report","integrate","use","user","health","validate","batch","issues","2026-11-10 10:12:30",false,"---\nname: merge-flow\ndescription: \"Merge a batch of approved workbuddy PRs into main: order them, resolve conflicts against design intent, validate post-merge health, and report. Use when the user asks to 'merge the batch', 'merge approved PRs', 'integrate finished issues', '批量合并', '处理冲突'; or when the merge-agent is invoked.\"\n---\n\n# Batch Merge Flow\n\nThis skill codifies how to merge multiple approved workbuddy PRs into `main` safely, with design-intent judgment on conflicts.\n\n## When to use\n\n- A batch of workbuddy issues has completed: their PRs are approved by review-agent and CI is green\n- User asks to merge a list of PRs\n- **Typical invocation is manual** — a human decides a batch is ready and hands the PR list to the merge-agent. The operator may *detect* a batch-ready condition and surface it, but the decision to merge belongs to a human because this skill involves design-intent judgment that operator autonomy shouldn't override.\n\n## Input contract\n\nThe caller provides:\n\n```yaml\nprs: [#101, #102, #104]      # PR numbers to merge (in no particular order)\nrepo: Lincyaw\u002Fworkbuddy       # target repo\nbase: main                    # base branch (default: main)\nmode: auto | review-required  # auto = proceed on safe resolutions; review-required = escalate all conflicts\n```\n\n## Procedure\n\n### Phase 0 — Batch coherence analysis\n\n**Before touching any branch**, analyze the batch as a whole. This is where design-intent reasoning happens — do it once upfront, not hunk-by-hunk during rebase.\n\n#### 0.1 Issue-level duplicate detection\n\nFor each PR, fetch its linked issue:\n\n```bash\ngh pr view \u003Cn> --json body,closingIssuesReferences\ngh issue view \u003Cissue-num> --json title,body,labels\n```\n\nCompare issues pairwise. Duplicate signals:\n\n- **Title near-match**: same key terms, similar phrasing\n- **Symptom overlap**: both describe the same user-facing problem or error signature\n- **AC overlap**: acceptance criteria describe the same behavior\n- **File overlap**: both PRs modify the same files in the same region\n- **Root-cause overlap**: both diagnose the same underlying cause\n\nFor suspected duplicates, consult `decisions.md` and `project-index.yaml` to see if one is actually a re-filing of an older issue or a subset of a larger epic.\n\nOutput: a list of **duplicate groups**. Example:\n\n```\ngroup A: #87 (\"heartbeat lease bug\") + #88 (\"worker submit failure\")\n  — #88's root cause IS #87. Duplicates.\ngroup B: #91 (dynamic config reload) — standalone\n```\n\n#### 0.2 PR-level feature overlap detection\n\nFor each pair of PRs (within AND across duplicate groups), analyze diffs:\n\n```bash\ngh pr diff \u003Cn>\n```\n\nOverlap signals:\n\n- **Same files changed** with overlapping line ranges\n- **Same symbol modified** (function, type, const) — `git diff --name-only`, then grep for symbol names\n- **Same behavior implemented** (even if in different files) — e.g., both add a retry loop around the same API call\n- **Contradictory changes** — one PR adds X, another removes X\n\nClassify each overlap:\n\n| Class | Example | Default resolution |\n|-------|---------|-------------------|\n| **Identical intent, one better** | Both fix the same bug; PR A is 3 lines, PR B is 50 lines with refactor | **Adopt PR A entirely, close PR B** |\n| **Identical intent, equivalent quality** | Both fix same bug with equally clean code | **Adopt oldest-approved PR, close the other** |\n| **Complementary** | Both add distinct features to same file; changes don't semantically conflict | **Merge both in order** |\n| **Partially overlapping** | PR A adds features X+Y; PR B adds Y+Z; both need Y | **Cherry-pick** the non-overlapping parts into a merge order: take A's X, take one side's Y, take B's Z |\n| **Contradictory design** | PR A uses pattern P1; PR B uses pattern P2; incompatible architecturally | **Escalate** — human must pick the approach |\n\n#### 0.3 Decision authority\n\nFor each non-trivial overlap, the skill prescribes:\n\n- **\"Adopt one\" decisions** (classes 1, 2): the merge-agent decides based on: code quality heuristics (lines changed, test coverage delta, complexity) + design-intent anchors (CLAUDE.md conventions, north-star alignment). Record reasoning.\n- **\"Cherry-pick\" decisions** (class 4): the merge-agent proposes the split, but if the split requires non-trivial code rearrangement (not just a git cherry-pick -x of individual commits), **escalate to human** — don't rewrite authors' commits.\n- **Contradictory design** (class 5): always escalate.\n\nRecord all decisions in the report (Phase 6) with rationale. For \"close PR B\" decisions, post a comment on the closing PR explaining why, linking to the kept PR, and thanking the author.\n\n#### 0.4 Output of Phase 0\n\nA revised merge plan:\n\n```yaml\nplan:\n  merge:\n    - pr: 101       # after cherry-pick: take only files A.go, B.go\n      cherry_pick_from: [abc123, def456]\n      reason: \"partial overlap with #102; keeping non-overlapping commits\"\n    - pr: 102       # full merge\n      reason: \"standalone\"\n  close:\n    - pr: 105\n      reason: \"duplicate of #101 with inferior implementation; fewer tests, larger diff\"\n      comment_to_post: \"...\"\n  escalate:\n    - prs: [103, 104]\n      reason: \"contradictory design choices for internal\u002Fstore package layout\"\n      question_for_human: \"...\"\n```\n\nIf any item lands in `escalate:` with a **class 5 (contradictory design)**, **stop and surface the question to the invoker before touching any branch**. Resolving design-level conflicts is a human decision.\n\nIf only `merge:` and `close:` items remain, proceed to Phase 1 with the revised plan.\n\n### Phase 1 — Preconditions (per PR)\n\nFor each PR in `prs`, verify:\n\n1. **Approved**: `gh pr view \u003Cn> --json reviewDecision` returns `APPROVED`\n2. **CI green**: `gh pr checks \u003Cn>` shows all required checks passing\n3. **Base is current**: PR's base branch is `main` (no stale PRs targeting old branches)\n4. **No `status:blocked` label on linked issue**\n5. **Author branch exists** and is not force-pushed recently (check commit SHA hasn't changed since approval timestamp)\n\nSkip PRs that fail any precondition. Record reason in the report.\n\n### Phase 2 — Ordering\n\nDetermine merge order using a topological sort:\n\n1. **Explicit dependencies**: parse PR bodies and linked issue bodies for \"Blocked by #X\" \u002F \"Depends on #X\". PRs with unresolved deps go after their deps.\n2. **File-overlap heuristic**: PRs that touch the same files are ordered by `created_at` (oldest first) so the second PR rebases onto the first.\n3. **Disjoint PRs**: no specific order, merge in `created_at` order for reproducibility.\n\nOutput a linear order. Cycles (A blocks B and B blocks A) are an error → escalate.\n\n### Phase 3 — Serial merge\n\nFor each PR in order:\n\n```bash\n# 1. Fetch latest main\ngit fetch origin main\ngit checkout main\ngit pull --ff-only origin main\n\n# 2. Try to rebase PR branch onto main (without pushing)\ngit fetch origin pull\u002F\u003Cn>\u002Fhead:pr-\u003Cn>-rebase\ngit checkout pr-\u003Cn>-rebase\ngit rebase main\n```\n\n**If rebase succeeds cleanly** → proceed to Phase 4 validation, then `gh pr merge \u003Cn> --squash --rebase --delete-branch`.\n\n**If rebase has conflicts** → enter Phase 4 conflict resolution on the rebase, then:\n- If resolved automatically: push the rebased branch (`git push -f origin pr-\u003Cn>-rebase:\u003Coriginal-branch>`), wait for CI, then merge.\n- If escalated: abort rebase (`git rebase --abort`), comment on the PR with the conflict report, skip to next PR.\n\n### Phase 4 — Conflict resolution (when rebase conflicts)\n\nClassify each conflict hunk:\n\n| Class | Signature | Strategy |\n|-------|-----------|----------|\n| **Trivial** | Whitespace, import order, comment-only diffs | Prefer the PR's side; re-run `goimports` or equivalent formatter |\n| **Additive** | Both sides add distinct code to the same region (e.g., both add a new case to a switch) | Merge both additions, preserve order by PR created_at |\n| **Same-intent** | Both PRs do the same thing slightly differently (e.g., both fix the same bug) | Prefer the approach that aligns with `CLAUDE.md` conventions \u002F `decisions.md` entries. Flag if unclear. |\n| **Competing-intent** | PRs implement overlapping features with incompatible designs | **Escalate**. Do not silently pick one. |\n| **Structural** | Conflicts span multiple files and involve architectural choices (new package layout, interface changes) | **Escalate**. |\n\n#### Design-intent consultation\n\nBefore resolving `same-intent` or `competing-intent` hunks, consult in this order:\n\n1. **`CLAUDE.md`** — project conventions (e.g., \"squash + rebase only\", \"2-agent first principle\")\n2. **`decisions.md`** — recent architectural decisions with rationale\n3. **`project-index.yaml`** — requirement text for both PRs' linked issues; the resolution must satisfy both AC sets\n4. **North-star targets** in `CLAUDE.md` — if two resolutions are plausible, pick the one that advances primary targets (requirements coverage, test coverage, build health)\n\nRecord your reasoning inline in the resolution commit message:\n\n```\nresolve: PR #101 vs PR #102 conflict in cmd\u002Fcoordinator.go\n\nContext: both PRs modify handleTaskResult. #101 adds tokenized auth check,\n#102 adds metrics emission. Changes are orthogonal — merged both.\nDesign-intent basis: north-star reliability favors both; no competition.\n```\n\n### Phase 5 — Post-merge validation\n\nAfter each successful merge (before proceeding to next PR):\n\n```bash\ngit checkout main\ngit pull --ff-only origin main\ngo build .\u002F...\ngo vet .\u002F...\ngo test .\u002F... -count=1\n```\n\n**If validation fails**:\n- Immediate action: `git revert \u003Cmerge-sha>` and push, restoring main to green state\n- Comment on the just-merged PR explaining the revert with the failing output\n- Mark the PR's linked issue with `status:developing` to route back through dev-agent\n- Continue to next PR in batch (do not abort the entire batch)\n\n### Phase 6 — Report\n\nOutput a structured report:\n\n```markdown\n## Merge Batch Report — \u003Ctimestamp>\n\n### Merged (N)\n- #101 — clean rebase\n- #102 — additive conflict auto-resolved (switch case)\n- #104 — trivial conflict (imports)\n\n### Reverted (M)\n- #103 — merged then reverted: go test failed in internal\u002Fstore\n  (revert SHA: abc123; issue re-opened for developing)\n\n### Escalated \u002F Skipped (K)\n- #105 — competing-intent conflict with #101 in internal\u002Flauncher\u002Fpermissions.go:\n  #101 uses env-var token only; #105 adds keyring fallback.\n  Design intent unclear — human decision needed. PR left open.\n\n### Validation\n- Final main SHA: def456\n- go build: ok\n- go test: ok (42 packages, 0 failures)\n- go vet: ok\n```\n\n## Constraints\n\n- **Never force-push to main.** Always use `gh pr merge --squash --rebase`.\n- **Never skip Phase 5 validation.** Each merge is validated before the next begins.\n- **Never silently resolve competing-intent conflicts.** Escalate and leave the PR open.\n- **Never delete a PR's source branch** unless `--delete-branch` was specified by GitHub merge (which is fine).\n- **Never amend merged commits.** If something's wrong, revert + new PR.\n- **Never bypass review.** If a PR somehow lost its approval (e.g., new commits pushed), re-trigger review-agent instead of merging.\n\n## Edge cases\n\n### All PRs fail preconditions\nReport and exit. Do not attempt to salvage.\n\n### Main drifts during batch (new commit lands from outside)\nRe-rebase remaining PRs against new main. This is safe because `main` is always green (Phase 5 invariant).\n\n### Revert chain\nIf merging PR A causes failure, then reverting A also breaks (highly unusual):\n- Reset batch: do not continue\n- Alert: \"main is broken in a way the batch flow cannot recover from\" → escalate to human immediately\n\n### PR branch deleted mid-merge\nThe original author may have deleted their branch. Fetch via `refs\u002Fpull\u002F\u003Cn>\u002Fhead` (always available on GitHub).\n\n## Success criteria\n\nA batch merge succeeded if:\n- Every PR in `prs` is either: merged, reverted-and-re-queued, or escalated-with-report\n- `main` is in a green state (build + test + vet pass) at the end\n- The report accurately reflects all outcomes\n- No manual intervention was required for same-intent or trivial conflicts\n","# Batch Merge Flow\n\nThis skill codifies how to merge multiple approved workbuddy PRs into `main` safely, with design-intent judgment on conflicts.\n\n## When to use\n\n- A batch of workbuddy issues has completed: their PRs are approved by review-agent and CI is green\n- User asks to merge a list of PRs\n- **Typical invocation is manual** — a human decides a batch is ready and hands the PR list to the merge-agent. The operator may *detect* a batch-ready condition and surface it, but the decision to merge belongs to a human because this skill involves design-intent judgment that operator autonomy shouldn't override.\n\n## Input contract\n\nThe caller provides:\n\n```yaml\nprs: [#101, #102, #104]      # PR numbers to merge (in no particular order)\nrepo: Lincyaw\u002Fworkbuddy       # target repo\nbase: main                    # base branch (default: main)\nmode: auto | review-required  # auto = proceed on safe resolutions; review-required = escalate all conflicts\n```\n\n## Procedure\n\n### Phase 0 — Batch coherence analysis\n\n**Before touching any branch**, analyze the batch as a whole. This is where design-intent reasoning happens — do it once upfront, not hunk-by-hunk during rebase.\n\n#### 0.1 Issue-level duplicate detection\n\nFor each PR, fetch its linked issue:\n\n```bash\ngh pr view \u003Cn> --json body,closingIssuesReferences\ngh issue view \u003Cissue-num> --json title,body,labels\n```\n\nCompare issues pairwise. Duplicate signals:\n\n- **Title near-match**: same key terms, similar phrasing\n- **Symptom overlap**: both describe the same user-facing problem or error signature\n- **AC overlap**: acceptance criteria describe the same behavior\n- **File overlap**: both PRs modify the same files in the same region\n- **Root-cause overlap**: both diagnose the same underlying cause\n\nFor suspected duplicates, consult `decisions.md` and `project-index.yaml` to see if one is actually a re-filing of an older issue or a subset of a larger epic.\n\nOutput: a list of **duplicate groups**. Example:\n\n```\ngroup A: #87 (\"heartbeat lease bug\") + #88 (\"worker submit failure\")\n  — #88's root cause IS #87. Duplicates.\ngroup B: #91 (dynamic config reload) — standalone\n```\n\n#### 0.2 PR-level feature overlap detection\n\nFor each pair of PRs (within AND across duplicate groups), analyze diffs:\n\n```bash\ngh pr diff \u003Cn>\n```\n\nOverlap signals:\n\n- **Same files changed** with overlapping line ranges\n- **Same symbol modified** (function, type, const) — `git diff --name-only`, then grep for symbol names\n- **Same behavior implemented** (even if in different files) — e.g., both add a retry loop around the same API call\n- **Contradictory changes** — one PR adds X, another removes X\n\nClassify each overlap:\n\n| Class | Example | Default resolution |\n|-------|---------|-------------------|\n| **Identical intent, one better** | Both fix the same bug; PR A is 3 lines, PR B is 50 lines with refactor | **Adopt PR A entirely, close PR B** |\n| **Identical intent, equivalent quality** | Both fix same bug with equally clean code | **Adopt oldest-approved PR, close the other** |\n| **Complementary** | Both add distinct features to same file; changes don't semantically conflict | **Merge both in order** |\n| **Partially overlapping** | PR A adds features X+Y; PR B adds Y+Z; both need Y | **Cherry-pick** the non-overlapping parts into a merge order: take A's X, take one side's Y, take B's Z |\n| **Contradictory design** | PR A uses pattern P1; PR B uses pattern P2; incompatible architecturally | **Escalate** — human must pick the approach |\n\n#### 0.3 Decision authority\n\nFor each non-trivial overlap, the skill prescribes:\n\n- **\"Adopt one\" decisions** (classes 1, 2): the merge-agent decides based on: code quality heuristics (lines changed, test coverage delta, complexity) + design-intent anchors (CLAUDE.md conventions, north-star alignment). Record reasoning.\n- **\"Cherry-pick\" decisions** (class 4): the merge-agent proposes the split, but if the split requires non-trivial code rearrangement (not just a git cherry-pick -x of individual commits), **escalate to human** — don't rewrite authors' commits.\n- **Contradictory design** (class 5): always escalate.\n\nRecord all decisions in the report (Phase 6) with rationale. For \"close PR B\" decisions, post a comment on the closing PR explaining why, linking to the kept PR, and thanking the author.\n\n#### 0.4 Output of Phase 0\n\nA revised merge plan:\n\n```yaml\nplan:\n  merge:\n    - pr: 101       # after cherry-pick: take only files A.go, B.go\n      cherry_pick_from: [abc123, def456]\n      reason: \"partial overlap with #102; keeping non-overlapping commits\"\n    - pr: 102       # full merge\n      reason: \"standalone\"\n  close:\n    - pr: 105\n      reason: \"duplicate of #101 with inferior implementation; fewer tests, larger diff\"\n      comment_to_post: \"...\"\n  escalate:\n    - prs: [103, 104]\n      reason: \"contradictory design choices for internal\u002Fstore package layout\"\n      question_for_human: \"...\"\n```\n\nIf any item lands in `escalate:` with a **class 5 (contradictory design)**, **stop and surface the question to the invoker before touching any branch**. Resolving design-level conflicts is a human decision.\n\nIf only `merge:` and `close:` items remain, proceed to Phase 1 with the revised plan.\n\n### Phase 1 — Preconditions (per PR)\n\nFor each PR in `prs`, verify:\n\n1. **Approved**: `gh pr view \u003Cn> --json reviewDecision` returns `APPROVED`\n2. **CI green**: `gh pr checks \u003Cn>` shows all required checks passing\n3. **Base is current**: PR's base branch is `main` (no stale PRs targeting old branches)\n4. **No `status:blocked` label on linked issue**\n5. **Author branch exists** and is not force-pushed recently (check commit SHA hasn't changed since approval timestamp)\n\nSkip PRs that fail any precondition. Record reason in the report.\n\n### Phase 2 — Ordering\n\nDetermine merge order using a topological sort:\n\n1. **Explicit dependencies**: parse PR bodies and linked issue bodies for \"Blocked by #X\" \u002F \"Depends on #X\". PRs with unresolved deps go after their deps.\n2. **File-overlap heuristic**: PRs that touch the same files are ordered by `created_at` (oldest first) so the second PR rebases onto the first.\n3. **Disjoint PRs**: no specific order, merge in `created_at` order for reproducibility.\n\nOutput a linear order. Cycles (A blocks B and B blocks A) are an error → escalate.\n\n### Phase 3 — Serial merge\n\nFor each PR in order:\n\n```bash\n# 1. Fetch latest main\ngit fetch origin main\ngit checkout main\ngit pull --ff-only origin main\n\n# 2. Try to rebase PR branch onto main (without pushing)\ngit fetch origin pull\u002F\u003Cn>\u002Fhead:pr-\u003Cn>-rebase\ngit checkout pr-\u003Cn>-rebase\ngit rebase main\n```\n\n**If rebase succeeds cleanly** → proceed to Phase 4 validation, then `gh pr merge \u003Cn> --squash --rebase --delete-branch`.\n\n**If rebase has conflicts** → enter Phase 4 conflict resolution on the rebase, then:\n- If resolved automatically: push the rebased branch (`git push -f origin pr-\u003Cn>-rebase:\u003Coriginal-branch>`), wait for CI, then merge.\n- If escalated: abort rebase (`git rebase --abort`), comment on the PR with the conflict report, skip to next PR.\n\n### Phase 4 — Conflict resolution (when rebase conflicts)\n\nClassify each conflict hunk:\n\n| Class | Signature | Strategy |\n|-------|-----------|----------|\n| **Trivial** | Whitespace, import order, comment-only diffs | Prefer the PR's side; re-run `goimports` or equivalent formatter |\n| **Additive** | Both sides add distinct code to the same region (e.g., both add a new case to a switch) | Merge both additions, preserve order by PR created_at |\n| **Same-intent** | Both PRs do the same thing slightly differently (e.g., both fix the same bug) | Prefer the approach that aligns with `CLAUDE.md` conventions \u002F `decisions.md` entries. Flag if unclear. |\n| **Competing-intent** | PRs implement overlapping features with incompatible designs | **Escalate**. Do not silently pick one. |\n| **Structural** | Conflicts span multiple files and involve architectural choices (new package layout, interface changes) | **Escalate**. |\n\n#### Design-intent consultation\n\nBefore resolving `same-intent` or `competing-intent` hunks, consult in this order:\n\n1. **`CLAUDE.md`** — project conventions (e.g., \"squash + rebase only\", \"2-agent first principle\")\n2. **`decisions.md`** — recent architectural decisions with rationale\n3. **`project-index.yaml`** — requirement text for both PRs' linked issues; the resolution must satisfy both AC sets\n4. **North-star targets** in `CLAUDE.md` — if two resolutions are plausible, pick the one that advances primary targets (requirements coverage, test coverage, build health)\n\nRecord your reasoning inline in the resolution commit message:\n\n```\nresolve: PR #101 vs PR #102 conflict in cmd\u002Fcoordinator.go\n\nContext: both PRs modify handleTaskResult. #101 adds tokenized auth check,\n#102 adds metrics emission. Changes are orthogonal — merged both.\nDesign-intent basis: north-star reliability favors both; no competition.\n```\n\n### Phase 5 — Post-merge validation\n\nAfter each successful merge (before proceeding to next PR):\n\n```bash\ngit checkout main\ngit pull --ff-only origin main\ngo build .\u002F...\ngo vet .\u002F...\ngo test .\u002F... -count=1\n```\n\n**If validation fails**:\n- Immediate action: `git revert \u003Cmerge-sha>` and push, restoring main to green state\n- Comment on the just-merged PR explaining the revert with the failing output\n- Mark the PR's linked issue with `status:developing` to route back through dev-agent\n- Continue to next PR in batch (do not abort the entire batch)\n\n### Phase 6 — Report\n\nOutput a structured report:\n\n```markdown\n## Merge Batch Report — \u003Ctimestamp>\n\n### Merged (N)\n- #101 — clean rebase\n- #102 — additive conflict auto-resolved (switch case)\n- #104 — trivial conflict (imports)\n\n### Reverted (M)\n- #103 — merged then reverted: go test failed in internal\u002Fstore\n  (revert SHA: abc123; issue re-opened for developing)\n\n### Escalated \u002F Skipped (K)\n- #105 — competing-intent conflict with #101 in internal\u002Flauncher\u002Fpermissions.go:\n  #101 uses env-var token only; #105 adds keyring fallback.\n  Design intent unclear — human decision needed. PR left open.\n\n### Validation\n- Final main SHA: def456\n- go build: ok\n- go test: ok (42 packages, 0 failures)\n- go vet: ok\n```\n\n## Constraints\n\n- **Never force-push to main.** Always use `gh pr merge --squash --rebase`.\n- **Never skip Phase 5 validation.** Each merge is validated before the next begins.\n- **Never silently resolve competing-intent conflicts.** Escalate and leave the PR open.\n- **Never delete a PR's source branch** unless `--delete-branch` was specified by GitHub merge (which is fine).\n- **Never amend merged commits.** If something's wrong, revert + new PR.\n- **Never bypass review.** If a PR somehow lost its approval (e.g., new commits pushed), re-trigger review-agent instead of merging.\n\n## Edge cases\n\n### All PRs fail preconditions\nReport and exit. Do not attempt to salvage.\n\n### Main drifts during batch (new commit lands from outside)\nRe-rebase remaining PRs against new main. This is safe because `main` is always green (Phase 5 invariant).\n\n### Revert chain\nIf merging PR A causes failure, then reverting A also breaks (highly unusual):\n- Reset batch: do not continue\n- Alert: \"main is broken in a way the batch flow cannot recover from\" → escalate to human immediately\n\n### PR branch deleted mid-merge\nThe original author may have deleted their branch. Fetch via `refs\u002Fpull\u002F\u003Cn>\u002Fhead` (always available on GitHub).\n\n## Success criteria\n\nA batch merge succeeded if:\n- Every PR in `prs` is either: merged, reverted-and-re-queued, or escalated-with-report\n- `main` is in a green state (build + test + vet pass) at the end\n- The report accurately reflects all outcomes\n- No manual intervention was required for same-intent or trivial conflicts\n",{"name":5,"description":7},"b9778c800f442939b879c9a556dfb8d6f4a40971",".claude\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fmerge-flow",1,"https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy","https:\u002F\u002Fgithub.com\u002FLincyaw","http:\u002F\u002Fprofile.aoyangfang.top\u002F","Student in The Chinese University of Hong Kong, Shenzhen","2026-06-08 13:33:51",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add Lincyaw\u002Fworkbuddy --skill merge-flow",{"tool":63,"command":64},"bunx","bunx skills add Lincyaw\u002Fworkbuddy --skill merge-flow",{"tool":66,"command":67},"pnpm","pnpm dlx skills add Lincyaw\u002Fworkbuddy --skill merge-flow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002F.claude\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fmerge-flow\u002FSKILL.md",true,[],[72,98,134,161,180,186],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":44},"01M6XCBSW1MMEAWEF38VX9NH3E","workbuddy-guide","Explain and operate workbuddy: what it is, which command to reach for, and where to find deeper references. **Trigger whenever the user mentions 'workbuddy' in any context** — including operational requests (register\u002Fonboard a repo, add\u002Fbind a worker, 注册仓库, 加仓库, 接入新仓库, onboard repo, set up worker), explanatory questions (how to use workbuddy, workbuddy guide, teach me workbuddy, 怎么用workbuddy, 使用指南), deployment\u002Frunning\u002Foperating\u002Fdebugging workbuddy, and questions about how issues\u002Ftasks are scheduled or how dependencies between issues work (depends_on, blocked, dependency gate, 依赖, 调度, 排队, '为什么没派发'), and questions about parallel-development workflows (rollouts:N fan-out, synthesize\u002Fsynthesis reduce step, cherry-pick, '并行开发', '多个方案', 'rollout'). Invoke this skill before running workbuddy CLI commands so the documented onboarding flow (coordinator register + worker repos add) and the dependency\u002Fscheduling model aren't re-derived from scratch.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fworkbuddy-guide\u002FSKILL.md",[],[79,80,81,43,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97],"guide","workbuddy guide","debugging","SET","model","pick","up","rollouts","deeper","worker","bind","how to","operating","coordinator","re","operate","which","scheduled","invoke",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":115,"publishedAt":44},"01M6XCBM7B95PB3Q6PHZ3TCM7F","web-debug","Validate the workbuddy webui (SPA + auth + JSON API) end-to-end on the same machine workbuddy runs on, using browser-use's headless harness. Use when the user says 'verify the frontend', 'test the SPA', 'check dashboard loads', '前端验证', '验下 webui', or after merging changes that touch internal\u002Fwebui, web\u002F, or the auth\u002Fcookie path.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fweb-debug\u002FSKILL.md",[104,107,110],{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[116,117,118,119,120,121,122,123,124,38,125,126,127,128,129,130,131,132,133,29],"web","debug","web debug","frontend","auth","browser","harness","api","check","webui","spa","end","machine","touch","loads","headless","browser-use","using browser",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":143,"publishedAt":44},"01M6XCBFR925WJSWEYVHGSTT56","setup-repo","Configure a GitHub repository for workbuddy orchestration — creates labels, the two canonical agent configs (dev + review), workflow definitions, issue templates, and config.yaml. Use when the user says 'set up repo', 'configure repo for workbuddy', 'initialize workbuddy', '配置仓库', '初始化workbuddy', or wants to onboard a new repo.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fsetup-repo\u002FSKILL.md",[140],{"categoryNo":141,"categoryName":142,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[144,145,146,147,148,149,150,151,152,82,153,154,85,155,156,157,158,159,160,29],"setup","setup repo","repo","review","orchestration","workflow","config","dev","repository","configure","initialize","issue","new repo","初始化","canonical","for","labels",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":44},"01M6XCBAEPZQTAS5FZYCPDEGAG","pipeline-monitor","Monitor the workbuddy agent pipeline, detect stuck issues, zombie processes, and missed redispatches. Works for both the 3-unit bundle (supervisor + coordinator + worker) and single-process `serve`. Use when the user says 'monitor the pipeline', 'check workbuddy status', '监工', '看看跑完了没', or asks to watch issue progress.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fpipeline-monitor\u002FSKILL.md",[],[168,169,170,171,43,172,124,38,155,173,88,174,175,176,177,92,178,159,179,29],"monitor","pipeline","pipeline monitor","status","supervisor","missed","watch","progress","detect","unit","agent pipeline","single",{"skillNo":181,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":185,"publishedAt":44},"01M6XCB5RTYNH7QK9RQ5Z4B6NK","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fmerge-flow\u002FSKILL.md",[184],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[24,26,25,28,41,36,43,42,40,39,38,37,27,35,34,33,32,31,30,29],{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":195,"publishedAt":44},"01M6XCB29F96RJ02Z3BXTAVYSB","deploy","Workbuddy deployment topology guide — explains the 3-unit bundle (supervisor + coordinator + worker), the rolling-restart property, and the cutover from the legacy single-process `serve` install. Use when the user says 'how should I deploy workbuddy', 'install workbuddy as a service', 'switch to bundle', 'rolling restart', '部署 workbuddy', '升级到 bundle'.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fdeploy\u002FSKILL.md",[192],{"categoryNo":193,"categoryName":194,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[188,196,197,198,172,199,200,79,38,201,202,88,203,204,205,206,177,92,179,29],"deployment","topology","how","process","install","Legacy","switch","service","as","bundle","serve"]