parallel

name	parallel
description	Run dense minmaxing work as a hardware-aware, main-orchestrated parallel workflow with bounded packets, explicit ownership, sync barriers, aggregation, and independent verification.
argument-hint	["dense task"]
disable-model-invocation	true

/parallel

Run a hardware-aware parallel workflow for:

$ARGUMENTS

/parallel is a whole-workflow acceleration mode. The main agent remains the orchestrator and keeps taste alignment, research sufficiency, architecture, SPEC ownership, security decisions, aggregation, hard introspection, and final verification. Workers only execute bounded packets with explicit ownership.

This is not /sprint. /sprint is an execution-wave primitive. /parallel decides whether the whole request merits parallel orchestration, chooses the execution substrate, writes the packet DAG, supervises sync barriers, and verifies the aggregate result against the active contract.

For file-changing packet work, /opusworkflow is the default outer route and /parallel is the inner contract. Direct /parallel invocation remains valid, but mutating packets must inherit the Claude/Opus planner-reviewer plus MiniMax-M2.7-highspeed executor policy before execution.

outer_route: opusworkflow
inner_contract: parallel

Non-Negotiable Contract

• Never parallelize just to use slots.
• Never delegate taste decisions, SPEC.md creation, architecture, security, quality-gate enforcement, final verification, or closeout judgment.
• Always run a Parallel Eligibility Audit before spawning or instructing parallel work.
• Always run a Hardware Capacity Profile before selecting a budget.
• Always record an Agent-Native Estimate before freezing the packet plan.
• Use the smallest effective budget that shortens the critical path.
• Use subagents by default for bounded same-workspace sidecar packets.
• Use parallel-instances only when disjoint ownership, speed need, and aggregation evidence justify the extra coordination cost.
• Agent View can be an operator-managed monitor for independent parallel-instances, but it is not a substrate value and does not satisfy packet DAG, ownership matrix, worker sidecar, aggregation, /introspect, /verify, or parent-verification requirements.
• Native /goal can be used manually inside an already-owned packet to keep one Claude Code session working toward bounded command evidence, but it does not create packet governance and does not satisfy ownership, aggregation, or verification requirements.
• Treat agent teams as opt-in experimental. Agent teams are opt-in experimental and must not be required for default /parallel behavior.
• Record all packet ownership, dependencies, sync barriers, and returned evidence in a workflow artifact.
• For executed packet runs, also record machine-readable run artifacts under .taste/parallel/{run_id}/ and aggregate them with scripts/parallel-aggregate.sh before accepting worker claims.
• Estimate elapsed time from the longest dependency path, including sync barriers, aggregation, verification, review, and rework risk.
• Block when workers would touch the same files or make conflicting authority claims.
• Run /introspect as a hard gate before freezing the packet plan, after aggregation, after failed verification, and before any push/ship decision.
• Run /verify against SPEC.md after aggregation. Worker success is not final success.
• Keep .minimaxing/state/CURRENT.md or the workflow artifact current enough to survive /compact.

Auto-Use Policy

/workflow should automatically consider /parallel when all conditions hold:

• The task is dense: research-heavy, audit-heavy, broad verification, or implementation with at least two independent packets.
• The expected critical-path reduction is larger than coordination cost.
• File, surface, or evidence ownership can be written cleanly.
• The host capacity profile supports at least two safe concurrent packets.
• The main agent has enough review capacity to inspect returned evidence.

Downgrade to normal /workflow or local execution when:

• The task is one tight reasoning loop.
• The task mostly touches one file or one shared context.
• Dependencies are unclear or workers would need constant back-and-forth.
• Verification cannot be split or aggregated safely.
• Host capacity, memory pressure, or tooling limits make parallelism noisy.

When the user explicitly requests parallel mode, still run the eligibility audit. If the audit fails, explain the downgrade and proceed with the safest non-parallel path.

Phase 0: Taste Gate

1. Read taste.md and taste.vision.
2. Rehydrate current state:

bash scripts/state.sh status 2>/dev/null || true

3. Check that acceleration does not conflict with project taste. Speed must not outrank evidence, safety, or surgical diffs.
4. Record the decision in the workflow artifact.

Hard gate: if the task conflicts with taste or open-core boundaries, stop or ask for an explicit alignment decision.

Phase 1: Parallel Eligibility Audit

Before research, planning, or spawning, answer:

Question	PASS Condition	BLOCK/DOWNGRADE Condition
Are there at least two independent packets?	Distinct files, surfaces, research branches, tests, or audits.	One shared file/context/reasoning loop.
Does parallelism shorten the critical path?	Workers can return useful evidence before the main is blocked.	Coordination cost exceeds speedup.
Can ownership be written explicitly?	Each packet has owned files/surfaces and do-not-touch list.	Ownership overlaps or is unknown.
Can dependencies be expressed as a DAG?	Packet order and sync barriers are clear.	Circular or hidden dependencies.
Can the main verify the aggregate?	SPEC.md criteria and evidence commands exist or can be written.	Final correctness depends on worker trust.
Is the host capacity sufficient?	Recommended ceiling is at least 2 and tools are available.	Capacity script says local-only or degraded host.

Decision values:

• PARALLEL_READY: continue.
• LOCAL_BETTER: use normal /workflow.
• NEEDS_SPEC_FIRST: write or update SPEC.md before packetizing.
• BLOCKED: stop because ownership, safety, or verification cannot be proven.

Phase 2: Hardware Capacity Profile

Run:

bash scripts/parallel-capacity.sh --json 2>/dev/null || bash scripts/detect-hardware.sh 2>/dev/null || true

Record:

• CPU cores
• RAM GB
• hardware class: low, standard, high, or workstation
• MAX_PARALLEL_AGENTS
• Codex max_threads
• recommended ceiling
• default substrate
• whether experimental agent teams are enabled

Budget formula:

effective_parallel_budget = min(
  capacity.recommended_ceiling,
  independent_packets,
  supervisor_review_capacity,
  verification_capacity
)

Hardware guidance:

• low: keep local or use at most 2 packets.
• standard: use 2-3 packets when ownership is crisp.
• high: use up to 4-6 packets for independent work.
• workstation: use up to 7-10 only for large, disjoint, evidence-rich work.

Hard gate: if the capacity profile cannot be produced, assume conservative standard only when the task is low risk. Otherwise downgrade.

Phase 3: Execution Substrate Selector

Choose one substrate and justify it:

Substrate	Use When	Do Not Use When
local	One tight reasoning loop, shared files, low hardware, or fast direct edit.	Multiple independent evidence branches are waiting.
subagents	Default for bounded same-workspace research, audit, implementation, and review packets.	Packets need independent working trees or incompatible tool states.
parallel-instances	Large disjoint work where separate sessions, shells, worktrees, or independent Claude/Codex instances materially reduce elapsed time.	Same files, permission storm, unowned state, or weak aggregation plan.
agent-teams	Opt-in experimental peer coordination when CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 and the task genuinely needs agents coordinating with each other.	Default use, production-critical path without fallback, or untested team behavior.

Claude Code Agent View (claude agents) may help the operator see operator-managed parallel-instances at a glance. It does not make a parallel-instances run governed; this route still needs explicit packet ownership, sidecars, sync barriers, aggregation, and parent verification before any worker claim is accepted.

Native Claude Code /goal may keep one packet session persistent after the packet contract already exists. Use only bounded conditions with command evidence and a stop clause. /goal status is not a worker result, not a sidecar, not aggregation, and not parent verification.

Selection rule:

• Prefer local for small or coupled work.
• Prefer subagents for most parallel work.
• Promote to parallel-instances only when the packet DAG is wide, ownership is disjoint, and speed need justifies separate contexts.
• Promote to agent-teams only with explicit experimental opt-in and fallback.

Phase 4: Deep Research And Code Audit

Follow the same research discipline as /workflow:

• Draft a collaborative research plan before the first search wave.
• Use search -> read -> refine loops.
• Keep a source ledger with cited, reviewed-but-not-cited, and rejected sources.
• Run code audit before planning edits.
• Use the capacity profile as a ceiling, not a target.
• Keep the main agent responsible for research sufficiency.

Parallel research packets must be distinct. Do not assign multiple workers to the same broad question.

Phase 5: Packet DAG And Ownership Matrix

Create a durable artifact:

mkdir -p .taste/workflow-runs
STAMP="$(date +%Y%m%d-%H%M%S)"
PARALLEL_ARTIFACT=".taste/workflow-runs/${STAMP}-parallel.md"
PARALLEL_RUN_DIR=".taste/parallel/${STAMP}"
mkdir -p "${PARALLEL_RUN_DIR}/worker-results"

Required section order:

# Parallel Run: {task}

## Task
## Taste Gate
## Parallel Eligibility Audit
## Hardware Capacity Profile
## Execution Substrate Selector
## Agent-Native Estimate
## Deep Research Brief
## Code Audit
## Pre-Plan Introspection
## SPEC Decision
## Packet DAG
## Ownership Matrix
## Sync Barriers
## Worker Packets
## Aggregation Notes
## Post-Aggregation Introspection
## Independent Verification Evidence
## Closeout

Packet DAG

| Packet ID | Purpose | Depends On | Can Run With | Blocks | Estimated Duration | Confidence | Status |
|-----------|---------|------------|--------------|--------|--------------------|------------|--------|
| P1 | ... | none | P2, P3 | B1 | 45-90m | medium | pending |

Agent-Native Estimate

## Agent-Native Estimate

- Estimate type: agent-native wall-clock
- Execution topology: local | subagents | parallel-instances | agent-teams-experimental
- Capacity evidence: scripts/parallel-capacity.sh --json, Codex max_threads, MAX_PARALLEL_AGENTS
- Effective lanes: N of ceiling M
- Critical path: P1 -> B1 -> P4 -> verification
- Agent wall-clock: optimistic / likely / pessimistic
- Agent-hours: total active work across all packets
- Human touch time: review, approval, credentials, product decisions
- Calendar blockers: CI queue, deploy window, external account setup, rate limits, business-hours dependency
- Confidence: high | medium | low, with downgrade reason
- Human-equivalent baseline: optional secondary comparison only

Calculate elapsed time from the longest dependency path, not total packet effort. Show when adding lanes stops helping because the supervisor, verifier, shared files, sync barriers, CI, credentials, or deploy windows become the bottleneck.

Ownership Matrix

| Packet ID | Owner/Substrate | Owned Files/Surfaces | Do Not Touch | Shared Inputs | Conflict Risk |
|-----------|-----------------|----------------------|--------------|---------------|---------------|
| P1 | subagent | path/a | path/b | SPEC.md | low |

Sync Barrier

| Barrier ID | Waits For | Main-Agent Check | Continue When | Stop When |
|------------|-----------|------------------|---------------|-----------|
| B1 | P1, P2 | inspect evidence and diff | all pass | conflict, stale context, failed packet |

Hard gate: do not launch workers until the DAG, ownership matrix, and first barrier are written.

Machine-Readable Run Artifacts

When packets execute, write these sidecars before aggregation:

.taste/parallel/{run_id}/packet-dag.json
.taste/parallel/{run_id}/ownership.json
.taste/parallel/{run_id}/worker-results/{packet_id}.json

packet-dag.json records packets, dependencies, duration estimates, capacity evidence, supervisor review capacity, verification capacity, and sync-barrier capacity. ownership.json records each packet's owner, owned files/surfaces, do-not-touch paths, and any explicit cross-owned edit approvals. Each worker-results/{packet_id}.json must use the worker-result sidecar shape and include packet id, owned files, touched files, commands run, tests run, evidence, unresolved risks, changed-line trace, handoff notes, and parent_verified.

Before closeout, run:

bash scripts/parallel-aggregate.sh "$PARALLEL_RUN_DIR"

The aggregate output must include packet count, worker result count, effective lanes, capacity ceiling, bottleneck, critical path, and whether additional lanes would help. If the bottleneck is supervisor review, verification, a sync barrier, shared files, CI, or credentials, do not claim extra agents would shorten elapsed time.

Phase 6: SPEC.md And Worker Packet Contracts

If files will change, SPEC.md must exist before worker execution. The main agent writes or updates SPEC.md; workers do not.

Every packet uses this contract:

Packet ID: [P#]
Task: [specific outcome]
Why now: [why this shortens the critical path]
Substrate: [local|subagents|parallel-instances|agent-teams]
Owned files/surfaces: [exact list]
Do not touch: [exact list]
Inputs: [SPEC.md section, artifact section, source refs, constraints]
Dependencies: [packets/barriers required first]
Estimated duration: [optimistic / likely / pessimistic]
Estimate confidence: [high|medium|low with reason]
Success: [objective definition of done]
Verification to run: [commands or inspection]
Return: [Worker Result Schema]
Stop if: [overlap, stale spec, missing dependency, conflicting evidence, auth risk]

Worker Result Schema:

## Worker Result: P#

- Status: success|failed|blocked|partial
- Summary:
- Files inspected:
- Files changed:
- Commands run:
- Evidence:
- Assumptions:
- Risks:
- Conflicts or stale context:
- Follow-up needed:

Workers must stop instead of improvising when:

• their owned files changed unexpectedly
• SPEC.md conflicts with packet instructions
• they need a permission not granted in the packet
• they find a security, data, or irreversible-action risk
• they need to touch a do-not-touch file
• verification fails and the fix would broaden scope

Before worker claims are accepted, the parent workflow must lint the aggregate packet evidence when scripts/parallel-plan-lint.sh is available. The minimal claim validator rejects ambiguous ownership, same-file collisions, missing command evidence, unverified worker claims, and linear lane-scaling claims. When worker results are stored as JSON sidecars, also validate them with scripts/artifact-lint.sh so touched files, owned files, command evidence, and parent verification are machine-checked.

When a .taste/parallel/{run_id} folder exists, run scripts/parallel-aggregate.sh {run_dir} after individual sidecar validation. Aggregation is the parent-level proof that packet DAG, ownership, capacity, worker results, critical path, and bottlenecks agree. A passing worker sidecar does not bypass aggregate validation.

Phase 6.5: Introspect Hard Gate

Before aggregation is considered ready, run /introspect.

Parallel-specific checks:

• Did we choose the right substrate, or was parallelism theatrical?
• Did any packet exceed the hardware capacity profile or configured ceiling?
• Did any worker touch unowned files or shared state?
• Did any worker rely on stale context after a sync barrier?
• Did any worker claim success without evidence?
• Did workers produce split-brain decisions or conflicting assumptions?
• Did the main delegate architecture, security, SPEC, or verification judgment?
• Are packet results traceable back to SPEC.md?
• Does the Agent-Native Estimate use critical-path math instead of summed packet effort or linear lane scaling?
• Did the estimate include verification, aggregation, review, blockers, and confidence labels?
• Did parallel-instances or agent teams add unverified behavior?
• Does any Hermes/agentfactory output lack development_host_profile, target_runtime_profile, capacity_binding, or concurrency_budget when the task creates agents or fleets?

Decision:

• PASS: proceed to independent verification.
• FIX_REQUIRED: fix packet outputs or aggregation.
• REPLAN_REQUIRED: rewrite the packet plan or SPEC.
• BLOCKED: stop and ask for operator input or downgrade.

Phase 7: Independent Verification

Run /verify against SPEC.md after aggregation. Verification must inspect the aggregate result, not just worker summaries.

Required parallel verification:

Check	Evidence
Packet completion	Every packet has a Worker Result Schema entry.
Ownership compliance	Changed files match the ownership matrix.
Conflict check	No same-file collision or unresolved split-brain claim.
Barrier check	Sync barriers were honored before dependent work.
SPEC trace	Meaningful changes trace to success criteria.
Capacity check	Effective budget did not exceed profile or configured ceiling.
Substrate check	Chosen substrate matched the documented reason.
Aggregate test	Final commands or inspection prove the whole result works.
Claim validator	bash scripts/parallel-plan-lint.sh --fixtures or a run-specific lint passes when available.
Run aggregation	bash scripts/parallel-aggregate.sh .taste/parallel/{run_id} passes when run artifacts exist.

If verification fails, run /introspect after-test-failure, fix only the minimal failing slice, and re-verify.

Phase 8: Closeout

Closeout must include:

• eligibility decision and whether parallelism was used or downgraded
• capacity profile summary
• selected substrate and effective budget
• Agent-Native Estimate summary, including critical path, wall-clock range, agent-hours, blockers, confidence, and whether actual elapsed timing was recorded
• packet count and outcomes
• changed files by packet
• parallel-aggregate status, effective lanes, bottleneck, and critical path
• verification result and isolation metadata
• residual risks
• whether SPEC.md was archived

If /parallel created or updated Hermes agents through /agentfactory, closeout must also include each agent's development_host_profile, target_runtime_profile, host_capacity_profile, capacity_binding, concurrency_budget, runtime degradation policy, and kill-switch verification result.

AgentFactory And Hermes Integration

When /parallel is used to create Hermes agents, agent fleets, or enterprise workflow agents:

• /agentfactory remains the agent-generation authority.
• /parallel may accelerate repo audit, runtime audit, documentation mapping, capability review, and verification packet collection.
• The main agent must still own the Hermes manifest, Hermes SPEC, authority model, security review, and registry decision.
• Every generated Hermes agent or fleet must include development_host_profile, target_runtime_profile, host_capacity_profile, capacity_binding, concurrency_budget, maximum parallel runs, queue/backpressure behavior, and degrade policy.
• Local scripts/parallel-capacity.sh output describes the development host unless the target runtime is explicitly local.
• A Hermes fleet must not assume the developer machine can run every agent at once, and it must not assume a cloud/server target has the same specs as the dev PC. Target runtime capacity must be measured, read from infrastructure config/provider limits, or explicitly declared by the operator.

Anti-Patterns

• Using all slots because they exist.
• Splitting one file across multiple workers.
• Treating worker output as verified truth.
• Letting workers write or replace SPEC.md.
• Using parallel-instances without separate ownership or aggregation.
• Enabling experimental agent teams as a default dependency.
• Ignoring RAM/CPU and blaming model quality for host overload.
• Creating Hermes fleets without capacity budgets or kill switches.