my-omc-parallel-work

Files (1)

• SKILL.md

SKILL.md (first lines)

# Parallel Work Skill

Orchestrate parallel sub-agents for independent Beads tasks, each running
in its own isolated git worktree.

## When to invoke

- 2–3 independent actionable tasks identified by triage
- All selected tasks are autonomous (no user input required mid-execution)
- Tasks touch different files (no branch/file conflict risk)

If fewer than 2 tasks qualify → do NOT spawn parallel agents. Work directly
on the single task instead.

**Maximum 3 parallel agents.** If more than 3 tasks qualify, select the 3
highest-priority ones (P1 first, then by unblock chain length). Queue the
rest for the next session.

## Step 1 — Identify tasks

Use the actionable tasks already identified by `show-next-task` in this
session. Do NOT re-run `bv` — the triage context is in the conversation.

If invoked standalone without prior `show-next-task` triage, run first:

```bash
bv --robot-plan
```

From the task list, confirm each candidate is:

- **Actionable**: no open blockers
- **Autonomous**: no "awaiting user review" or "needs approval"
  (`bd show <id>` to verify)
- **Independent**: no dependency between selected tasks, different files

Exclude tasks needing user input — handle those interactively first.

### Pre-flight: check for uncommitted main-worktree changes

Before spawning any agents, run:

```bash
git status --porcelain
```

If output is non-empty, **stop immediately** and tell the user:

> Uncommitted changes detected in the main worktree. Parallel agents run
> in isolated worktrees and will not see these changes. Commit or stash
> before spawning agents:
>
> ```bash
> git add -p && git commit -m "wip: stash before parallel run"
> # or: git stash
> ```

Do NOT spawn agents until the working tree is clean.

## Step 2 — Select agent type per task

For each qualifying task, apply these rules (use `bd show <id>` if more
detail is needed):

| Signal from issue | Agent type |
| --- | --- |
| type: bug, or mentions test/molecule/CI failure | `ralph` |
| type: task/chore/feature with concrete spec | `executor` |
| root cause unknown, needs investigation | `debugger` |
| large epic needing decomposition into subtasks | `team N:executor` |

Default to `executor` when signal is ambiguous. Prefer `ralph` over
`executor` when a test suite must pass — the retry loop handles
test-fix-retry cycles without user intervention.

## Step 3 — Present execution plan

Before spawning, output the plan:

```text
Parallel execution plan (N agents, N worktrees):

  [id] <title>
       Agent: <type>  Reason: <one-line rationale>

  [id] <title>
       Agent: <type>  Reason: <one-line rationale>

Spawning now...
```

Do not wait for confirmation unless the user has explicitly requested it.

## Step 4 — Spawn agents simultaneously

Spawn all Agent calls in the same response (parallel execution).
Each agent uses `isolation: "worktree"`.

Each agent prompt must include:

1. **Claim instruction**: `bd update ansible-all-my-things-<id> --claim`
   before starting work
2. **Issue context**: title and description from `bd show`
3. **Task scope**: what files or systems to touch
4. **Verification**: what command confirms the work is correct
5. **PR instruction**: after pushing, open a PR targeting the default
   branch of `origin`. If the repo has an `upstream` remote, `origin` is
   a fork — target `origin` only, never `upstream`.
   Do NOT merge the PR — leave it open for user review.

**PR rules (encode in every agent prompt):**

- Determine target:
  `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`
- Target repo: `origin` (run `git remote get-url origin` to confirm)
- Never open PR against `upstream` remote
- No squash merges — regular merge commits only
- Do NOT merge the PR — the user merges explicitly

From wonderbird/ai-agent-workspace, GPL-3.0.

More from wonderbird/ai-agent-workspace