# Parallel > Run dense minmaxing work as a hardware-aware, main-orchestrated parallel workflow with bounded packets, explicit ownership, sync barriers, aggregation, and independent verification. - **Type:** Skill - **Install:** `agentstack add skill-waitdeadai-minmaxing-parallel` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [waitdeadai](https://agentstack.voostack.com/s/waitdeadai) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [waitdeadai](https://github.com/waitdeadai) - **Source:** https://github.com/waitdeadai/minmaxing/tree/main/.claude/skills/parallel ## Install ```sh agentstack add skill-waitdeadai-minmaxing-parallel ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # /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. ```text 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 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 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: ```text 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: ```bash 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: ```markdown # 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 ```markdown | 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 ```markdown ## 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 ```markdown | 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 ```markdown | 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: ```text .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 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: ```text 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: ```markdown ## 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](https://github.com/waitdeadai) - **Source:** [waitdeadai/minmaxing](https://github.com/waitdeadai/minmaxing) - **License:** Apache-2.0 Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-waitdeadai-minmaxing-parallel - Seller: https://agentstack.voostack.com/s/waitdeadai - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.