parallel-swarm-implementation

---

LIBRARY-FIRST PROTOCOL (MANDATORY)

Before writing ANY code, you MUST check:

Step 1: Library Catalog

• Location: .claude/library/catalog.json
• If match >70%: REUSE or ADAPT

Step 2: Patterns Guide

• Location: .claude/docs/inventories/LIBRARY-PATTERNS-GUIDE.md
• If pattern exists: FOLLOW documented approach

Step 3: Existing Projects

• Location: D:\Projects\*
• If found: EXTRACT and adapt

Decision Matrix

Match	Action
Library >90%	REUSE directly
Library 70-90%	ADAPT minimally
Pattern exists	FOLLOW pattern
In project	EXTRACT
No match	BUILD (add to library after)

---

STANDARD OPERATING PROCEDURE

Purpose

Execute concurrent swarm tracks that coordinate via shared checkpoints, avoid contention, and converge into validated outputs without overconfidence.

Trigger Conditions

• Positive: parallel tracks for large tasks, multi-lane feature delivery, concurrent research/build/test efforts, shard/merge workflows.
• Negative: sequential single-lane tasks, prompt-only edits (route to prompt-architect), or new skill creation (route to skill-forge).

Guardrails

• Skill-Forge structure-first: ensure SKILL.md, examples/, tests/ exist; add resources/ and references/ or log remediation.
• Prompt-Architect hygiene: capture HARD/SOFT/INFERRED constraints per lane, define merge criteria, and present pure-English outputs with ceilings.
• Parallel safety: prevent resource contention, define isolation and merge windows, and enforce registry agents plus hook latency budgets.
• Adversarial validation: test merge conflicts, data skew, and race conditions; run COV and capture evidence.
• MCP tagging: store run artifacts with WHO=parallel-swarm-implementation-{session} and WHY=skill-execution.

Execution Playbook

1. Intent & lanes: identify goals, shard plan, and constraints; confirm inferred dependencies.
2. Topology & roles: assign lanes with owners, milestones, and communication cadence; define merge gates.
3. Execution controls: allocate quotas, set retries/backoff, and monitor health per lane.
4. Safety nets: plan contention avoidance, rollback paths per lane, and conflict resolution rules.
5. Validation loop: dry-run merges, test failure injection, measure latency/throughput, and log evidence.
6. Delivery: summarize lane outputs, merge decisions, residual risks, and confidence ceiling.

Output Format

• Lane map with owners, milestones, and merge criteria.
• Constraint matrix and risk register.
• Validation evidence (merge tests, conflict handling) and telemetry.
• Confidence: X.XX (ceiling: TYPE Y.YY) - rationale.

Validation Checklist

• Structure-first assets present or ticketed; examples/tests aligned to parallel patterns.
• Merge/rollback rules defined; registry and hook budgets validated.
• Adversarial/COV runs stored with MCP tags; confidence ceiling declared; English-only output.

Completion Definition

Parallel work is complete when lanes deliver outputs, merge tests pass, conflicts are resolved, evidence is stored, and risks are owned with next steps.

Confidence: 0.70 (ceiling: inference 0.70) - Parallel swarm SOP rewritten with skill-forge scaffolding and prompt-architect constraint/evidence discipline.