Parallel

/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

1. Check that acceleration does not conflict with project taste. Speed must not

outrank evidence, safety, or surgical diffs.

1. 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 co

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: waitdeadai
• Source: waitdeadai/minmaxing
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.