parallel-task-design
Skill0 starsChanged 13 days agoMITView on GitHub
Break a multi-part engineering task into safely parallel work units with clear ownership and integration points. Use when several agents or contributors can work concurrently.
In this repository25 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agent-skill-auditSkill
- api-contract-checkSkill
- build-rescueSkill
- change-narrativeSkill
- context-handoffSkill
- data-quality-gateSkill
- dataset-workshopSkill
- dependency-careSkill
- docs-syncSkill
- experiment-ledgerSkill
- failure-forensicsSkill
- model-diff-reviewSkill
- model-eval-designSkill
- multi-agent-crosscheckSkill
- performance-proofSkill
- release-readinessSkill
- repo-scoutSkill
- research-evidence-mapSkill
- review-lensSkill
- safe-migrationSkill
- security-surfaceSkill
- spec-firstSkill
- sql-integrity-checkSkill
- test-driven-changeSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
Keep dependent tasks sequential.
- Distinctive: line 15
Ask each contributor to report touched files, decisions, commands/tests run, unresolved assumptions, and any edits made outside their scope.
- Distinctive: line 22
Do not have multiple agents edit the same file concurrently unless the environment explicitly supports conflict-free coordination.
- Distinctive: line 23
Do not assume a successful subtask means the integrated branch works.
≈ “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.
Files
Parallel Task Design
Procedure
- Map the requested outcome, shared files, dependencies, sequence constraints, and final integration tests.
- Split work by independent deliverable or subsystem rather than by arbitrary file count. Each task needs a clear owner, boundaries, input assumptions, and completion criteria.
- Identify conflicts: shared manifests, lockfiles, global types, generated code, schemas, snapshots, config, and common abstractions.
- Establish contracts before parallel implementation. Agree on names, interfaces, types, file ownership, and fixture formats early.
- Keep dependent tasks sequential. Parallelize independent research/tests/docs only when their results will not be invalidated by upstream decisions.
- Ask each contributor to report touched files, decisions, commands/tests run, unresolved assumptions, and any edits made outside their scope.
- Integrate one workstream at a time. Inspect the combined diff, reconcile contradictions, run cross-workstream tests, and remove duplicate or abandoned code.
Deliverable
Workstream table with owner, input, scope, files/contracts, acceptance criteria, dependencies, and integration test.
Boundaries
- Do not have multiple agents edit the same file concurrently unless the environment explicitly supports conflict-free coordination.
- Do not assume a successful subtask means the integrated branch works.
- Preserve all contributors' useful work; inspect repository state before reverting or overwriting.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.