# Parallel Build

> Split a hackathon build into independent agent or teammate tasks with explicit interfaces, file ownership, integration order, and bounded verification.

- Skill: `shreyp087/parallel-build` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add shreyp087/parallel-build`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shreyp087/parallel-build/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Shreyp087 (https://skillmd.com/u/shreyp087)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shreyp087/parallel-build

---


# Parallel build

Use parallel work when independent progress exceeds the cost of coordination. Keep tightly coupled changes local. Work with the available concurrency instead of spawning duplicate generalists.

Before delegation, define the shared contract: data shape, API surface, state transitions, representative fixtures, and errors. Assign each worker one deliverable, files they may change, dependencies, a done condition, and a time budget. Choose one integration owner. Separate read-only research/review from code ownership.

Useful concurrent tasks include a dependency feasibility spike, a UI against an agreed fixture, isolated evaluation cases, and a demo script derived from already implemented behavior. The critical backend and its interface redesign are usually one owner's task.

For independent code changes in the same repository, prefer a separate git worktree and branch per worker when the repository supports them. Keep a shared interface contract and one integration owner; worktrees do not integrate themselves. If a shared checkout is necessary, workers need disjoint file ownership. Read-only research does not need another worktree. Record contract changes and notify affected workers before further dependent work. Never discard someone else's uncommitted changes.

Integrate as soon as a small slice works. Verify the joined behavior rather than accepting separate claims of completion. Ask each worker for changed paths, checks run, observed result, and unresolved assumptions. A reviewer should inspect actual artifacts; multiple agreeing agents are not independent empirical evidence.

Stop or redirect redundant work when the bottleneck changes. Deliver the integration status and next critical-path action. Do not create separate user-owned Codex tasks unless the user asks for those tasks.