| 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
- Determine the current branch name.
- 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:
- Check the commit authors. If commits are from a different swarm/agent
(different author name/email pattern), treat this as parallel swarm work.
- 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
- 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>
