parallel-brief

Featured

Write a subagent brief that isolates ports, files, worktrees, scratch output, baselines, and primary evidence before parallel work begins.

AI & Automation 139 stars 21 forks Updated today MIT

Install

View on GitHub

Quality Score: 87/100

Stars 20%
71
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Parallel brief Concurrency is not the risk; uncoordinated shared state is. Every rule here came from a real failure on 2026-08-03 or 2026-08-04. ## 1. Give every browser run its own server `playwright.config.ts` may reuse an existing local server. Two agents can therefore measure different code while both report success. - Assign a unique port and explicit `PLAYWRIGHT_BASE_URL`. - Use `PLAYWRIGHT_STATIC=1` when proof must cover the exported build. - Run one spec at a time so server failure is distinguishable from product failure. ## 2. One person owns each ratchet baseline Two branches lowering the same literal from one stale starting value cannot be combined arithmetically. The merging owner recounts after integration, lowers the number once, and proves one step lower turns red. Only one agent edits a ratchet file. Others may report measurements, never commit competing baselines. ## 3. Worktrees and stash - Never run `git add -A`; a worktree directory can be staged as an empty gitlink. - Subagents do not remove worktrees. The coordinating owner may remove a task-created worktree only after confirming ownership, preserved changes, and no active users. Otherwise report its path for later cleanup. - Never use `git stash`; stash is repository-wide and has erased another agent's work in this project. ## 4. Keep measurement scratch outside the repository Git may ignore a path that ESLint still scans. Probe files under `output/` or `.tmp/` have inflated warning c...

Details

Author
wlsdks
Repository
wlsdks/ontology-atlas
Created
5 months ago
Last Updated
today
Language
TypeScript
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

parallel-pr-fanout

Use when a batch of 3+ independent changes should land as SEPARATE pull requests built by parallel agents — "address all of these", "fix everything on the list", "make as much parallel work as possible", a review or audit producing many unrelated fixes. Goal — reviewable, file-disjoint PRs that merge in any order. NOT for coupled changes (one PR), sequential work (a stack), or generic non-PR parallelism (that is plain agent dispatch).

1 Updated today
damson
AI & Automation Listed

parallel-agents

Fan independent work out to multiple subagents that run concurrently, each with a focused scope and self-contained instructions, then review and integrate their results. Use when you face two or more genuinely independent tasks (separate failing test files, unrelated bugs, distinct subsystems) that share no state and don't depend on each other's order.

5 Updated 3 days ago
KhaledSaeed18
AI & Automation Listed

sdlc-parallel-work

Run several streams of work at once using isolated worktrees, and factor recurring jobs into subagents with their own context and tool limits. Use when there is more work in flight than one session can hold, when asked to parallelize or run tasks concurrently, when the same job recurs across tasks (verifying the app runs, simplifying after implementation, exploring a codebase without flooding context), when writing subagent definitions, or when deciding how many sessions one person can genuinely supervise. Covers splitting work so sessions do not collide, what makes a good subagent, and the real ceiling.

0 Updated 6 days ago
asaf-shitrit