parallel-work-check

name	parallel-work-check
audience	swarm-plugin
description	Apply before starting work on an existing branch. Checks for parallel work by other agents or developers that may supersede or conflict with your planned changes. Prevents wasted effort on stale branches.
effort	small
generated_from_knowledge	[]
source_knowledge_ids	["f07c1f4d-9bb0-4219-9804-26aa8efe8146"]
generated_at	2026-06-14T16:50:00.000Z
confidence	0.8
status	active
version	4
skill_origin	generated
provenance_note	Re-linked to current knowledge entries (version 4). The original source ID b8fee776... is no longer present in the active knowledge store. The skill body and behavior are unchanged; only source_knowledge_ids metadata was updated to point to the current lesson about verifying pre-existing state on parent commit, which is directly relevant to the parallel-work-check protocol.

Parallel Work Check Protocol

Run this check before starting ANY work on an existing branch (not a fresh branch you just created). This applies to PR branches, feature branches, and any branch that may have concurrent contributors.

Step 1 — Check current branch state

1. Determine the current branch name.
2. Determine the remote tracking branch (usually origin/<branch-name>).

Step 2 — Fetch remote state

Fetch the latest state from the remote for the current branch. Do NOT skip this step because "the branch looks recent" or "I just checked."

Step 3 — Compare local vs remote

Compare the local HEAD commit hash with the remote HEAD commit hash:

• Identical: Remote has not diverged. Proceed with your work.
• Remote ahead: The remote branch has commits you don't have locally.
  • Read the new commit messages with git log local..remote.
  • Check if any of those commits touch files you plan to modify.
  • If yes: evaluate whether the parallel work supersedes your planned changes.
  • If the parallel work is superior: reset your local branch to match remote and abandon your planned approach. Document the decision.
  • If the parallel work is complementary: integrate it first, then proceed.
• Local ahead: You have local commits not on remote. This is normal if you already started work. Proceed, but be aware that pushing may conflict with subsequent remote changes.
• Diverged: Both local and remote have unique commits. This requires integration. Merge or rebase as appropriate for the team's workflow.

Step 4 — Check for parallel swarm/agent work

If the remote has new commits:

1. Check the commit authors. If commits are from a different swarm/agent (different author name/email pattern), treat this as parallel swarm work.
2. Parallel swarm work is often superior because:
   • It may have access to different context or tools
   • It may have started earlier or had more iterations
   • It may have taken a fundamentally better approach
3. Default stance: prefer the parallel swarm's work unless you can clearly articulate why your approach is better.

Step 5 — Decision and documentation

Before proceeding, document your decision:

PARALLEL WORK CHECK:
- Branch: <name>
- Local HEAD: <hash> <message>
- Remote HEAD: <hash> <message>
- Diverged: yes/no
- New commits on remote: <count>
- Parallel swarm work detected: yes/no
- Decision: [proceed / integrate-then-proceed / abandon-use-remote / needs-review]
- Rationale: <one sentence>