parallel-plan

Parallel Plan

Overview

Use this skill as a lightweight implementation profile of blueprint-plan-drafter for current in-flight work. Its purpose is simple: do not try to do complex tasks alone; split into independent workstreams and use help. Keep the same core terminology (milestone/workstream/work package/patch), but reduce process weight so teams can start quickly. The ultimate goal is to reduce implementation wall time, not to maximize process, parallelism theater, or document volume.

Terminology Contract

• Milestone: short planning window for the current task.
• Workstream: parallel lane with one clear owner.
• Work package: assignment-sized chunk a single coder can finish.
• Patch: reviewable change set used for progress reporting.

Core Nudge

• If a task has 2 or more separable tracks, split it.
• If one person is becoming the bottleneck, split it.
• If independence is unclear, do prerequisite work first, then split the rest.
• Prefer asking for help early rather than debugging integration late.
• Judge every split by one question: will this reduce elapsed time to a correct implementation?

Relationship to Manager Planning

• blueprint-plan-drafter is the full manager-grade planning workflow.
• parallel-plan is the lightweight operational version for active execution.
• Use the same language and dependency discipline, but with less document overhead and faster dispatch.

Choose Execution Mode

• Decide between orchestration-only and real parallel execution.
• Choose the mode that minimizes elapsed time to a validated result.
• Use orchestration-only when environment limits prevent true concurrency. Still split into independent streams and write complete stream briefs.
• Use real parallel execution when streams can run at the same time in isolated sessions/worktrees or a single batched multi-task dispatch.
• If briefing, coordination, and merge overhead exceed likely time savings, do not parallelize.

Tooling and State

• Keep execution tooling non-prescriptive.
• Treat tmux as an optional helper, not a requirement.
• Accept any equivalent mechanism that provides true concurrent execution and isolation.
• Default to lightweight text artifacts for task state (stream briefs, stream reports, unified plan).
• Make the orchestrator choose report paths per run; do not hardcode a global fixed path.
• Use collision-safe naming for report paths (for example: run id + stream id + timestamp/random suffix).
• Prefer repo-local temp directories or other orchestrator-selected temp locations when practical.
• Add a task database (sqlite/Berkeley DB) only when cross-session resume or external query requirements are explicit.