agentleFS
renathoazrenathoaz/arsyn/skills/parallelizing/SKILL.md

parallelizing

Skill2 starsChanged 8 months agoMITView on GitHub

Run independent tasks concurrently via subagents.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before dispatching, answer three questions:

    line 12
  2. Distinctive:

    Are there 2+ distinct tasks?: If not, handle directly.

    line 14
  3. Distinctive:

    Are they independent?: If tasks share state, edit the same files, or depend on each other's output, run them sequentially.

    line 15
  4. Distinctive:

    Can each be scoped with full context?: If an agent would need your entire session history to operate, it is not a good candidate for …

    line 16
  5. Distinctive:

    All three must be yes. Otherwise, work sequentially.

    line 18
  6. Distinctive:

    If conflicts exist, resolve manually before running tests.

    line 49

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Parallelizing

Announce at start: "I'm applying the parallelizing skill to run these tasks concurrently."

Decision Gate

Before dispatching, answer three questions:

  1. Are there 2+ distinct tasks? If not, handle directly.
  2. Are they independent? If tasks share state, edit the same files, or depend on each other's output, run them sequentially.
  3. Can each be scoped with full context? If an agent would need your entire session history to operate, it is not a good candidate for dispatch.

All three must be yes. Otherwise, work sequentially.

Scoping Agent Tasks

Each agent operates in isolation with zero inherited context. Construct everything it needs:

  • Boundary — one file, one subsystem, one problem domain
  • Objective — concrete deliverable ("make these 3 tests pass," "add validation to endpoints X and Y")
  • Constraints — what NOT to touch ("do not modify production code," "only change files under src/auth/")
  • Deliverable format — what to return ("summary of root cause and changes made")

See references/agent-prompt-template.md for the standard prompt structure.

Dispatch

// All calls execute concurrently
Task("Fix agent-tool-abort.test.ts — 3 timing failures")
Task("Fix batch-completion.test.ts — event structure bug")
Task("Fix tool-approval-race.test.ts — missing async wait")

Integration After Return

When agents complete:

  1. Read each summary — understand what changed and why
  2. Check for conflicts — did any agents touch overlapping files?
  3. Run the full test suite — individual fixes can interact unexpectedly
  4. Spot-check agent work — agents can make systematic errors (e.g., all using the same wrong pattern)

If conflicts exist, resolve manually before running tests.

Prompt Anti-Patterns

ProblemBadBetter
Scope too wide"Fix all the tests""Fix the 3 failures in auth.test.ts"
Missing context"Fix the race condition"Paste error messages + test names
No guardrailsAgent refactors freely"Only modify files under src/auth/"
Vague deliverable"Fix it""Return: root cause, files changed, verification"

When NOT to Dispatch

  • Cascading failures — fixing one may resolve others. Investigate the root first.
  • Exploratory work — you do not yet know what is broken. Gather information before splitting.
  • Shared file edits — two agents editing the same file produces merge conflicts or silent overwrites.
  • Context-heavy tasks — if the agent needs to understand the full system architecture, sequential investigation is cheaper than reconstructing context.

Gotchas

  • Agents editing the same file — Even "independent" tasks can converge on a shared utility or config file. Audit file boundaries before dispatch.
  • Silent failures — An agent may report success while introducing a subtle regression. The full-suite run in integration is not optional.
  • Over-parallelizing — Dispatching 10 agents for 10 trivial tasks adds coordination overhead that exceeds the time saved. Reserve parallelization for tasks with real duration.
  • Stale context in prompts — Copying outdated error messages or file paths into agent prompts causes agents to chase ghosts. Verify context freshness before dispatch.

Integration

Called by:

  • orchestrating — dispatches agents for independent plan steps
  • debugging — parallel investigation of unrelated failures

Pairs with:

  • isolating — each agent may need its own worktree for file-level isolation

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.