dispatch

Use when a task file exists in .hyperflow/tasks/ and workers need dispatching. Fans out parallel Sonnet workers under per-batch Opus reviewers, runs a final integration review, and commits per sub-task. Endpoint of the auto-chain — no auto-deploy. Trigger with /hyperflow:dispatch, "run the plan", "execute the task", "build it", "run the batches".

v3.1.2

Mohammed Abdelhady

MIT

6 Tools

hyperflow Plugin

ai agency Category

Allowed Tools
        ReadWriteEditBash(git:*)AgentAskUserQuestion
      

Provided by Plugin

hyperflow

Fifteen specialized slash commands turn one Claude session into a structured multi-agent engineering pipeline. Thinking models orchestrate, triage, and review; worker models execute in parallel — every step is a Worker → Reviewer pair, and every non-trivial phase fans into sub-phases with their own reviewers. Auto-routing is on by default — say 'audit the diff', 'debug this test', 'large migration', or 'run a workflow' and the orchestrator routes to the right skill without the /hyperflow:* prefix. /hyperflow:workflow uses Claude Code dynamic workflows for big tasks and a portable Codex/OpenCode adapter where native workflows are unavailable; /hyperflow:spec asks the questions a senior engineer would; /hyperflow:scope decomposes into a batched task graph; /hyperflow:dispatch fans out persona-stitched workers under tiered review; /hyperflow:amplify rewrites a rough prompt into a high-quality one before you run it. 15 composable personas, 6 adaptive flow profiles, and persistent project memory compound across sessions. Works across Codex App/CLI, Claude Code, OpenCode, and Antigravity.

ai agency v4.26.1

View Plugin

Installation

This skill is included in the hyperflow plugin:

/plugin install hyperflow@claude-code-plugins-plus

Click to copy

Instructions

Dispatch

Workhorse phase. Picks up a task file from /hyperflow:scope and runs it through the orchestrator pattern with parallel worker dispatch and thinking-tier reviews.

This skill exercises Layer 3 (Orchestrator), Layer 5 (Quality Gates), Layer 6 (Project Memory), Layer 8 (Git Workflow), and Layer 9 (Security) from the doctrine. Multi-level review (L1–L5) is applied per the triage's flow profile.

Per-Step Agent Map (DOCTRINE rule 12 — §12.1 inline-allowed for trivial steps · §12.2 sub-phase decomposition)

Every substantive step dispatches at least one Agent. Trivial steps (≤ 2 tool calls, no content generation, no decision-making, mechanically verifiable) MAY be performed inline by the orchestrator per §12.1. Non-trivial steps decompose into ≥ 2 named sub-phases per §12.2.

Step	Sub-phase	Worker tier	Thinking tier	Notes
0 — Mode confirm	— (exempt)	—	—	`AskUserQuestion` only
0.5 — Operational choices	— (exempt)	—	—	`AskUserQuestion` only
1 — Load task	— (atomic · §12.2.8)	—	—	Read + schema check = single mechanical decision; no parallel angles
2a — Pre-dispatch	Composer × N parallel (Sonnet) — one per sub-task; stitches persona + injects learnings	Reviewer (Sonnet) — reviews prompt set for completeness	Parallel worker prompts built before any fan-out fires
2b — Worker fan-out	Implementer / Searcher / Writer × N parallel (Sonnet)	Reviewer (Sonnet · worker tier) — batched over full batch (P2) or per-sub-task fallback (mixed caps / `--thorough`)	One Reviewer call per batch · escalates to Opus under `--thorough`
2c — Gate run	Worker (Sonnet) — runs lint/typecheck/tests on affected files	Reviewer (Sonnet) — judges gate output	Small focused diff; Sonnet sufficient
2d — Learnings + commit	Writer (Sonnet) — synthesizes per-batch learnings	— (mechanical commit · §12.1)	Per-sub-task PASS commits land here; learnings appended to context
3 — Final integration review	— (atomic · §12.2.8)	Reviewer (Opus · thinking tier) — L1–L over full diff	Single Reviewer dispatch, no parallel angles; atomic-exempt
4 — Wrap up	Writer (Sonnet) — optional; only if memory prose is non-trivial	—	§12.1 trivial-inline; no Reviewer (D5)
5 — End of chain	— (exempt)	—	ONE `AskUserQuestion` with audit + deploy questions

Iron rule — thinking agents ≥ batches + 1 (one batched Reviewer per batch + final integration when not skipped). The batched Reviewer counts as 1 per batch regardless of how many sub-tasks are in the batch. If less, a per-step reviewer was skipped.

Review Levels (scale by flow profile)

Every batch reviewer and the final integration reviewer uses the level set below. Profile comes from /hyperflow:spec triage and is propagated via the chain-mode args.

Profile	Levels	Workers	Reviewers
`fast`	L1	1	inline self-review only
`standard`	L1–L2 default	1–2	1 per-batch reviewer
`deep`	L1–L5	3+	per-batch + final integration
`research`	L1–L2 + synthesis	3+ searchers	inline synthesis
`creative`	L1–L3 + UX	1–2	1 reviewer
`scientific`	L1–L5 + TDD	2–3	per-batch + final

L1 syntax/format · L2 spec/naming/edges · L3 integration/security · L4 perf/scale · L5 a11y/UX. See review-levels.md for the full checklist.

Default cap is L1-L2. Triage may flag security: true or integration_risk: true in its output; when either is set, the cap elevates to L1-L3 for both per-batch and final integration reviewers. Workers do NOT request elevation — only the upstream triage classification can elevate. See reviewer-prompt-batched.md — workers must honor the cap passed to them (cap enforcement lives on the reviewer-prompt side).

Approval Gates

Gate	When	Format
Chain mode	Step 0, only if invoked directly	`AskUserQuestion` — auto / manual
Inter-batch (manual mode only)	After each batch's gates pass	`AskUserQuestion` — continue / stop. Auto mode fires NO inter-batch question — see DOCTRINE rule 8 (invented gates banned).
Hard halt	Any `SECURITY_VIOLATION` from a reviewer	Stop the chain, surface the finding
Audit prompt	Step 5, after wrap-up	`AskUserQuestion` — run `/hyperflow:audit`? (yes/no, recommended toggles with flow profile)
Deploy prompt	Step 5, after audit gate	`AskUserQuestion` — run `/hyperflow:deploy`? (yes/no, recommended toggles with gate state)

Inputs

Task file — positional arg (slug or path). Default — most-recently-modified file in .hyperflow/tasks/.
chain-mode= — passed in by /hyperflow:scope. Controls whether to pause for confirmation after the final integration review. If absent, assume auto.
--from-batch — resume from a specific batch (skip prior batches).
--final-only — skip batch dispatch, run only the final integration review.
--thorough — disable P2 batched reviews; fall back to per-sub-task reviewers for every sub-task in every batch. Use when belt-and-suspenders depth is required on a high-risk run. P3 (concurrent pre-conditions) and P5 (lean worker prompts) remain on. When --thorough is passed, BOTH D5 (wrap-up Reviewer drop) and D7 (integration review skip) are disabled — the full pre-round-2 ceremony runs. D2 combined gate stays (no quality tradeoff), D6 default L1-L2 stays (cap can still be elevated by triage flags).

Flow

Step 0 — Choose mode (only if invoked directly · STRUCTURAL GATE)

This is a structural gate per DOCTRINE rule 8. When dispatch is invoked directly (no chain-mode arg from scope), it MUST fire. "No clarifying questions" / "auto-pilot" / any autonomy directive does NOT skip it. Defaulting silently is a doctrine violation.

If a chain-mode arg was passed, skip this step — the chain-starter already asked.

Otherwise, ask via AskUserQuestion. Per DOCTRINE rule 8, the recommended option goes first with (Recommended):


How should I handle progress through the batches?

  Auto (Recommended)  — run all batches + final review and stop. Print next-step suggestions.
  Manual              — pause between batches and ask before continuing.

Wait for the user's answer. Do not proceed without it. If AskUserQuestion cannot be presented as a popup, use the Codex fallback: print the same gate as a Hyperflow Question chat block with numbered options, then stop and wait for the user's answer. If no interactive channel is available at all, print an error and stop — never silently default.

Step 0.5 — Operational Choices (auto-mode only · STRUCTURAL GATE · fires immediately after Step 0)

When the user picks Auto at Step 0 AND operational args (commit=, branch=, push=) were NOT already propagated from a prior chain-starter, fire ONE AskUserQuestion call with 3 questions covering every operational decision dispatch needs. After this batch, dispatch runs silently until the end-of-chain audit + deploy gates.

Skip when chain-mode=manual (per-batch pauses cover ops decisions) OR when operational args are already propagated (re-asking is an invented-gate violation).

The 3-question batch is identical to scope Step 0.5 — see scope/SKILL.md § Step 0.5 for the full question + option text + recommended-default logic + chain-arg propagation contract. Spec, scope, dispatch share one canonical definition; whoever fires first owns the batch, the others see the args propagated and skip.

Step 1 — Load the task (atomic · §12.2.8)

Read .hyperflow/tasks/.md. Extract batches, sub-tasks, flow-profile, and operational args. Confirm the task file is structurally complete: batches array non-empty, each sub-task has id, title, files, complexity. If absent or malformed, stop and suggest /hyperflow:scope first.

> Atomic-exempt per §12.2.8 — file existence check + schema validation is a single mechanical decision with no parallel angles. No Worker or Reviewer dispatched.

Step 2 — For each batch

Print the batch header: Batch — .

Mode resolution (one-time per chain, before Step 2a fires for the first batch): run python3 $PLUGINROOT/scripts/resolve-mode.py $PROJECTROOT --from-args "$CHAIN_ARGS" and cache the resulting word (default / lean / thorough). Subsequent batches use the cached value.

Sub-phases 2a–2d run in order for every batch (P1 sequential — each depends on the prior sub-phase's output). Within each sub-phase, Workers are parallel.

Step 2a — Pre-dispatch (P1 · sequential after mode resolution)

For each sub-task in the batch, dispatch a Composer Worker in parallel (one Composer per sub-task — N total). Each Composer:

Selects the worker persona (Implementer / Searcher / Writer) from the sub-task brief.
Stitches the persona header + Project Context per resolved mode:
mode = default / thorough → inline excerpts from .hyperflow/profile.md, architecture.md, conventions.md matching the worker's role.
mode = lean → render the lean Project Context block: a Project Context (load on demand): heading + paths to .hyperflow/memory/session-context.md, .hyperflow/profile.md, .hyperflow/architecture.md, .hyperflow/conventions.md, .hyperflow/testing.md, .hyperflow/memory/index.md with one-line descriptions each. Workers read on demand. Saves ~2k tokens × N; same content, lazy access.
Injects accumulated Learnings from prior batches (in all modes).
Outputs a complete worker prompt ready for fan-out.

Use the worker-prompt.md template for each Composer output. Persona stitching (top-3), memory injection (all tag matches), and all clarification gates remain unchanged regardless of mode.

After all Composers return, dispatch one Reviewer (Sonnet) over the full prompt set: confirms persona selection is correct, context block is well-formed, learnings are injected. Verdict: PASS / NEEDSREVISION. NEEDSREVISION re-dispatches only the affected Composer(s).

Step 2b — Worker fan-out (P1 · sequential after 2a · internal parallelism P1)

Dispatch all N sub-task Workers in a single message with parallel Agent calls using the composed prompts from Step 2a. Workers are Implementer / Searcher / Writer (Sonnet) and run fully in parallel.

When all workers have returned, dispatch one batched per-batch Reviewer (Sonnet by default — model: "") covering the entire batch (P2 — batched single-pass review):

Check level-cap homogeneity first. If every sub-task shares the same review-level cap → batched review. If any sub-task carries a different cap (rare mixed profile) → fall back to per-sub-task reviewers.
Also fall back to per-sub-task reviewers when --thorough was passed (reviewers escalate to Opus under --thorough).
Batched reviewer dispatch: use reviewer-prompt-batched.md with model: "" (or "" under --thorough). Print Reviewer (Sonnet) — batched review Batch (L1–L, sub-tasks). Returns one verdict per sub-task.
Per-sub-task fallback (mixed caps or --thorough): dispatch a separate reviewer per sub-task per reviewer-prompt.md. Print Reviewer (Sonnet) — reviewing (L1–L).
Why Sonnet by default: per-batch reviewers see one batch's diff (typically 2–8 files). L1 (syntax/format) and L2 (spec/naming/edges) are pattern-matching work Sonnet handles at near-Opus quality. The cross-cutting concerns Sonnet might miss (L3+ integration, architectural drift) are exactly what the Opus final integration Reviewer at Step 3 catches over the cumulative diff. Two-tier review covers more ground than two-Opus review at a fraction of the cost.

(Path note: reviewer-prompt-batched.md lives in skills/hyperflow/ because it is a cross-skill template shared across the chain; reviewer-prompt.md stays in dispatch/references/ from prior convention. The asymmetric paths are intentional.)

Failure recovery: DOCTRINE rule 14 — skills/hyperflow/failure-recovery.md. When a Worker errors out (tool crash, OOM, 5xx, timeout) or returns malformed output: retry → escalate tier → abort. After 3 cumulative aborts in the chain, the chain itself aborts and prints the full failure trail.

Parse the per-sub-task verdicts:

SECURITY_VIOLATION — halt the chain immediately. Surface the finding; do not commit anything in the batch.
Worker returned OVERSIZE: with SUGGESTED-SPLIT: — do NOT proceed. Dispatch a Thinking Lead consultation: Thinking Lead — Planner (mid-flight split) — split per Worker's OVERSIZE signal. Pass the Worker's reason, suggested split, the original brief, and batch context. The Thinking Lead returns a final split plan (N new sub-tasks, each complexity = low | medium). Remove the original; dispatch the N new sub-tasks as a new sub-batch. The per-batch Reviewer fires after the new sub-batch completes. No user question — splitting an oversized brief is a mechanical reshape.
NEEDS_FIX — re-dispatch only that sub-task's Worker with the fix list. After the fix, dispatch a single focused reviewer for just that sub-task (not a full re-batch). Repeat until PASS (max 3 retries before escalating to a thinking-tier worker).
PASS — sub-task handed to Step 2d for commit.

Step 2c — Gate run (P1 · sequential after 2b verdicts resolve)

After all sub-tasks in the batch have passed review, run Layer 5 quality gates (lint / typecheck / tests on affected files) per quality-gates.md.

Dispatch one Worker (Sonnet) to run the gate commands. Dispatch one Reviewer (Sonnet) to judge the gate output. Verdict: PASS / NEEDSFIX. On NEEDSFIX the Worker applies fixes (never amending per-sub-task commits — fixes land as small additional commits) and the gate re-runs. Max 3 gate cycles before escalating.

Failure recovery: DOCTRINE rule 14 — skills/hyperflow/failure-recovery.md. When the per-batch Reviewer returns NEEDSREVISION, retry the Worker once with a ## Learnings from review injection. A second NEEDSREVISION surfaces the sub-task as partial; the chain continues with the latest output marked partial — no third Worker dispatch.

Step 2d — Learnings + commit (P1 · sequential after 2c PASS)

For each sub-task whose verdict is PASS:

Commit immediately per git-workflow.md rule 2 (per-sub-task commit cadence). Stage only the files that sub-task touched. Write a conventional commit (feat(): </code> derived from the task file). One sub-task = one commit. A batch of 3 parallel sub-tasks produces 3 commits, even though they were reviewed in a single batched Reviewer call.</li> <li><strong>Update the task file's <code>## Status</code> block</strong> after each commit lands: tick <code>[ ]</code> → <code>[x]</code>, increment <code>Sub-tasks: <done>/<total></code>, add tokens to <code>Tokens used:</code> running totals, refresh <code>Wall-clock:</code> and <code>Last update:</code>, recompute <code>ETA:</code> once ≥3 sub-tasks are done. This is what <code>/hyperflow:status</code> reads for live progress.</li> </ul> <p>Dispatch one Writer (Sonnet) in parallel to synthesize per-batch learnings from all Worker outputs and the Reviewer's notes. The learnings are appended to the in-memory <code>Learnings from prior batches</code> context (injected at Step 2a of subsequent batches). Writer also checks off the batch in the task file.</p> <p>The two activities (commits + learnings synthesis) run concurrently — the Writer synthesizes while commits land sequentially per the commit cadence arg.</p> <p>After Step 2d, print a one-line status update — <em>"Batch 1 done · 9/36 sub-tasks · next: B2 deps"</em> — then proceed to the next batch immediately in <code>auto</code> mode. Per DOCTRINE rule 8, "transparency checkpoints" / "midway sanity checks" / "scope re-confirmations" / "cost heads-ups" are banned. The only inter-batch gates are: (a) <code>chain-mode=manual</code> → pause and ask before the next batch fires; (b) <code>SECURITY_VIOLATION</code> → hard halt; (c) <code>ESCALATE: <reason></code> crossing the irreversibility boundary → fire the escalation gate per <a href="../hyperflow/escalation.md">escalation.md</a>. If none apply, the next batch fires immediately.</p> <h3>Step 3 — Final Integration Review</h3> <p><strong>Skip condition (D7):</strong> if ALL of the following hold, skip the final integration review and print <code>Final integration review skipped — all batches PASSed first try</code>:</p> <ul> <li>Every per-batch Reviewer returned PASS on first try (no NEEDS_FIX retries)</li> <li>No escalations fired (no <code>ESCALATE:</code> markers during Step 2)</li> <li>No security flags raised (no triage <code>security: true</code> AND no Reviewer security warnings)</li> <li>No per-batch Reviewer surfaced <code>[Important]</code> out-of-cap notes (via the <code>reviewer-prompt-batched.md</code> "Honor the Level Cap" escape hatch — these notes signal a concern the Reviewer wanted to flag but couldn't escalate within the cap; D7 must NOT swallow them)</li> </ul> <p>If ANY of these conditions fails, the final integration review runs.</p> <p>> <strong>Risk note:</strong> the skip is the riskiest D-decision in round 2 — multi-batch cross-interaction bugs could slip. The guard conditions are deliberately strict (first-try PASS + no escalations + no security flags) to keep risk low. Pass <code>--thorough</code> to disable the skip and always run the integration review.</p> <p>> Atomic-exempt per §12.2.8 — this is a single Reviewer dispatch (Opus over the cumulative diff) with no parallel angles. No sub-phase decomposition warranted.</p> <p><strong>Failure recovery:</strong> DOCTRINE rule 14 — <a href="../hyperflow/failure-recovery.md"><code>skills/hyperflow/failure-recovery.md</code></a>. If the Opus integration Reviewer errors, retry once with the prior error injected. On a second failure, re-dispatch with the prior error in context (no higher tier exists — escalation here means re-dispatching Opus with the error visible). Third failure → abort the integration review; chain completes with a partial integration verdict surfaced to the user.</p> <p>Dispatch a thinking-tier <strong>Reviewer</strong> (<code>model: "<resolved-thinking>"</code> — always Opus, regardless of <code>--thorough</code>) over the full changed-file set across every batch (all sub-task commits from Step 2d). Use the same level cap as the batch reviewers (per flow profile).</p> <p>Print: <code><strong>Reviewer</strong> (Opus) — final integration review (L1–L<n>)</code></p> <p>The Opus Reviewer returns a single structured verdict with per-sub-task findings where applicable. This is the one pass that catches cross-batch contradictions — Sonnet per-batch reviewers are anchored to one batch's diff and cannot see cross-batch integration issues. Opus tier is mandatory here.</p> <p>Parse the verdict:</p> <ul> <li><code>PASS</code> → proceed to Step 4.</li> <li><code>NEEDS_FIX</code> → re-dispatch only the affected sub-tasks' Workers with the fix list. After fixes land, re-run Step 3 for the updated diff.</li> <li><code>SECURITY_VIOLATION</code> → <strong>halt the chain immediately.</strong> Print finding; do not auto-continue.</li> </ul> <h3>Step 4 — Wrap Up</h3> <p>Trivial-eligible per §12.1 (D5 + D9). Wrap-up is mechanical work: delete task file + memory append + chore commit. The per-batch reviewers and final integration review (when not skipped per D7) already validated the substantive changes.</p> <p><strong>Nominal path (inline orchestrator):</strong> perform the following directly without an Agent dispatch wrapper:</p> <ol> <li>Delete the completed task file from <code>.hyperflow/tasks/</code>.</li> <li>Before appending: <code>grep -F</code> the proposed entry's first-line title against <code>.hyperflow/memory/*.md</code> files (inline dedup-check — replaces the dropped Reviewer dedup pass). If a match exists, edit the existing entry rather than append a duplicate.</li> <li>Append durable patterns/decisions to <code>.hyperflow/memory/</code> per <a href="references/memory-system.md">memory-system.md</a>.</li> <li>Commit the memory + task-file-deletion as a <code>chore(memory):</code> commit (separate from the per-sub-task commits from Step 2 — keeping memory writes out of feature commits keeps the diff clean).</li> <li>Print the usage summary per <a href="references/output-style.md">output-style.md</a>.</li> </ol> <p><strong>When the Writer dispatch IS required:</strong> if memory append requires non-trivial prose generation (e.g., synthesizing learnings from a multi-batch run with cross-cutting patterns), dispatch <code>Writer — finalizing dispatch artifacts</code> for the memory write. At that point the step is no longer §12.1-trivial and the Writer Agent handles it. The chore commit still follows immediately; no Reviewer is dispatched for wrap-up.</p> <p>> <strong>No wrap-up Reviewer (D5):</strong> the Reviewer that previously sanity-checked the chore commit and memory entries is dropped. Wrap-up is mechanically verifiable — <code>git status</code> clean, task file absent, memory file present. The orchestrator's direct observation is sufficient.</p> <h3>Step 5 — End of Auto-Chain · Audit + Deploy gates</h3> <p>Dispatch is the endpoint of the auto-chain. Fire ONE <code>AskUserQuestion</code> with <strong>both</strong> questions in the <code>questions[]</code> array (D2 — combined gate). DOCTRINE rule 8 — structural gates always fire, never silently default. The <code>AskUserQuestion</code> tool accepts up to 4 questions per call; this combined gate uses 2 (audit + deploy). Do not cram further unrelated questions here; the gate's scope is end-of-chain disposition only. In Codex, if the popup UI is unavailable, render both questions in one <code>Hyperflow Question</code> chat block and wait for the user's answers.</p> <p>> <strong>DOCTRINE rule 8 preserved:</strong> both questions still fire; they just batch into one round-trip instead of two. Combined gate cuts human-in-the-loop latency by ~half at end-of-chain.</p> <pre><code> ? End-of-chain gates [1] Run /hyperflow:audit on the cumulative diff? Yes — outside-eye L3 review, independent of per-batch reviewers No — skip; per-batch L1–L<n> reviews were enough [2] Run /hyperflow:deploy now? (lint + typecheck + build + tests + security sweep, then asks before push) Yes — gates pass · ready to ship No — keep commits local · push manually later </code></pre> <p>Per DOCTRINE rule 8, both questions are binary action gates — no <code>(Recommended)</code> marker on either option. Two-outcome framing is symmetric; the orchestrator's analysis is reflected in the surrounding status output (gate results, retry counts, security verdict), not in pre-marking the choice.</p> <p><strong>Process answers in order:</strong></p> <p>On audit <code>Yes</code> → invoke <code>Skill</code> with <code>skill: audit</code> and <code>args: "level=3"</code> (or <code>level=5</code> for scientific). Wait for it to finish. Then process the deploy answer.</p> <p>Then, process the deploy answer. Option labels MUST be one short clause each (≤ 12 words) — never paragraphs of reasoning.</p> <p><strong>Internal recommendation signal (used for status framing, NOT for marker):</strong></p> <p>The orchestrator still computes whether the chain is in a "green" or "marginal" state — this drives the status line the user reads above the gate, not a <code>(Recommended)</code> marker on the options. A chain is <strong>marginal</strong> (and the status line should say so) when one of these <em>concrete</em> signals is present:</p> <ul> <li>A <code>SECURITY_VIOLATION</code> was raised (and resolved) during dispatch</li> <li>A worker <code>ESCALATE:</code> crossed the irreversibility boundary</li> <li>≥ 2 Hyperflow batch-reviewer retries (<code>NEEDS_FIX</code> → re-dispatch) for the <em>same</em> sub-task — true repeated failure of the Layer 5 quality gates</li> <li>A flaky test failure that wasn't conclusively root-caused</li> <li>Any reviewer left a <code>[Critical]</code> finding unresolved</li> </ul> <p>The following are <strong>NOT</strong> "marginal" signals and MUST NOT flip the recommendation to <code>No</code>:</p> <table><thead><tr> <th>Signal</th> <th>Why it's fine</th> </tr></thead><tbody> <tr> <td>Pre-commit hook auto-fixed style (commitlint subject-case, prettier, eslint --fix)</td> <td>These are commit-time linters at the editor layer, not Hyperflow quality gates. Hooks fixing themselves is normal.</td> </tr> <tr> <td><code>/hyperflow:audit</code> was run and applied fixes through <code>/hyperflow:scope → :dispatch</code></td> <td>This is the audit fix-gate working as designed. The code is now <em>better</em> than before audit. Strong positive signal.</td> </tr> <tr> <td>Quality gates passed on first try (or after one auto-fix retry)</td> <td>First-pass green is the happy path.</td> </tr> <tr> <td>Single-batch dispatch with no escalations</td> <td>Simpler runs trend cleaner, not more suspect.</td> </tr> <tr> <td>Many sub-tasks (e.g. 27 commits) without any of the concrete-signal failures above</td> <td>Volume is not a risk signal on its own.</td> </tr> </tbody></table> <p>The orchestrator is not the user's risk advisor. The user already saw every reviewer verdict, every gate result, and the audit findings in scrollback. Inventing risk narratives in the recommendation label ("eyeballing the diff before push is prudent") is paternalism, not guidance.</p> <p>On deploy <code>Yes</code> → invoke <code>Skill</code> with <code>skill: deploy</code>. Deploy has its own push-confirmation gate at its Step 6.</p> <p>On <code>No</code> to both gates → stop cleanly. Print one line:</p> <pre><code> Dispatch complete — <n> batches, <m> agents, <p> per-sub-task commits on branch <branch>. Next: invoke /hyperflow:audit or /hyperflow:deploy manually when ready. </code></pre> <p>The orchestrator does <strong>NOT</strong> auto-invoke audit or deploy. Both gates wait for an explicit user choice. Defaulting silently is a doctrine violation.</p> <h2>Agent Label Style</h2> <p>No icons, no brackets. Em-dash separator. Bold for thinking-tier roles:</p> <pre><code> Implementer — creating auth middleware Searcher — finding related test files Writer — generating API documentation **Reviewer** — reviewing auth middleware output **Debugger** — investigating test failure in auth.test.ts </code></pre> <h2>Operational Args (from Scope Step 2.6 · auto-mode pre-elections)</h2> <p>When <code>chain-mode=auto</code>, scope batches three operational pre-elections at its Step 2.6 and propagates them as chain args. Dispatch reads them at Step 1 and honors them without re-asking. Missing args fall back to the indicated defaults.</p> <table><thead><tr> <th>Arg</th> <th>Values</th> <th>Default</th> <th>Honored at</th> </tr></thead><tbody> <tr> <td><code>commit</code></td> <td><code>per-task</code> / <code>per-batch</code> / <code>per-task-deferred</code> / <code>single</code> / <code>none</code></td> <td><code>per-task</code></td> <td>Step 2 (commit cadence after each PASS)</td> </tr> <tr> <td><code>branch</code></td> <td><code>new</code> / <code>current</code></td> <td><code>new</code> if currently on <code>main</code> or <code>master</code>, else <code>current</code></td> <td>Step 2 (before first commit)</td> </tr> <tr> <td><code>push</code></td> <td><code>ask</code> / <code>auto</code> / <code>never</code></td> <td><code>ask</code></td> <td>Forwarded to Deploy Step 6 via chain args</td> </tr> </tbody></table> <p><strong><code>commit=per-task</code></strong> (default) — commit after every sub-task PASS as the existing flow. Commits land directly on the user's working branch as they happen.</p> <p><strong><code>commit=per-batch</code></strong> — accumulate sub-task changes; commit once per batch after all sub-tasks PASS, with a message rolling up the batch (<code>feat(<scope>): batch <n> — <one-line summary></code>). One per-batch commit per batch.</p> <p><strong><code>commit=per-task-deferred</code></strong> — produce N per-task commits like <code>per-task</code>, but <strong>queue them on a private <code>hyperflow/staging-<chain-id></code> branch during the chain</strong> and flush all onto the user's working branch at Step 4 wrap-up. Useful when the user wants no user-visible commits landing mid-chain (atomic cumulative reveal at the end) or wants the crash-safe manifest recovery path. After each sub-task PASS, call <code>bash $PLUGIN<em>ROOT/scripts/queue-commit.sh $PROJECT</em>ROOT $CHAIN<em>ID "<msg>" <file>...</code> instead of <code>git add</code> + <code>git commit</code>. The script auto-creates the staging branch + manifest at first call, runs <code>git commit</code> <strong>with hooks enabled</strong> (no <code>--no-verify</code> — ever, per DOCTRINE Layer 8), and appends to <code>.hyperflow/commits-queue/manifest.json</code>. If a hook rejects a sub-task's commit, the orchestrator surfaces the error and stops; the user fixes and resumes from the affected sub-task. At Step 4 wrap-up, dispatch runs <code>bash $PLUGIN</em>ROOT/scripts/flush-commits.sh $PROJECT_ROOT</code> which fast-forward-merges the staging branch onto the user's branch (every queued commit lands in order, original SHAs preserved, original messages preserved). If the user's branch diverged (manual commits mid-chain on same branch), flush surfaces the error + recovery suggestions (<code>git rebase</code> / <code>git cherry-pick</code>); staging branch + manifest preserved for manual handling. Crash recovery: <code>/hyperflow:flush</code> re-runs the same script against the persisted manifest.</p> <p><strong>Trade-off honesty:</strong> hooks fire per sub-task (same load as <code>per-task</code> immediate). The deferred mode does NOT skip pre-commit hooks — it never has, and any earlier draft suggesting otherwise was a doctrine violation since corrected. Use this mode for the UX benefit (no user-visible commits until end) and crash-safety (manifest survives session loss); not for hook avoidance.</p> <p><strong><code>commit=single</code></strong> — accumulate all changes; commit once at Step 4 wrap-up with a message rolling up the whole chain (<code>feat(<scope>): <feature name> · <n> sub-tasks</code>). One commit total.</p> <p><strong><code>commit=none</code></strong> — never commit during dispatch; leave working tree dirty. Skip the per-sub-task commit step entirely. Print at Step 4: <code>Working tree intentionally left dirty (commit=none); review and commit manually before deploy.</code></p> <p><strong><code>branch=new</code></strong> — at Step 2 before the first commit, if currently on <code>main</code> / <code>master</code> / <code>develop</code>, create <code>feat/<task-slug></code> and switch to it. If already on a feature branch, treat as <code>branch=current</code>.</p> <p><strong><code>branch=current</code></strong> — never auto-create. All commits land on whatever branch the orchestrator was invoked on.</p> <p><strong><code>push=…</code></strong> — dispatch does NOT push. It only propagates the chosen value to Deploy Step 6 in the chain args. Deploy honors it there.</p> <h2>Iron Rules</h2> <ul> <li><strong>Failure recovery (rule 14).</strong> Worker errors, malformed output, NEEDS_REVISION, and gate failures follow the canonical policy in <a href="../hyperflow/failure-recovery.md"><code>skills/hyperflow/failure-recovery.md</code></a>. Retry → escalate → abort. Chain budget: 3 cumulative aborts.</li> <li>Workers never review, never coordinate, never ask the user questions.</li> <li>Every batch produces <strong>one</strong> per-batch Reviewer dispatch (Sonnet · worker tier) — batched over all sub-tasks in the batch (P2), or per-sub-task when mixed level caps or <code>--thorough</code>. Either way: one Reviewer call per batch in the nominal case. Escalates to Opus under <code>--thorough</code>.</li> <li>Plus <strong>one</strong> final integration Reviewer at the end (Step 3 · Opus · thinking tier) <strong>when not skipped per D7</strong>. Always Opus regardless of flags — this is the one Reviewer that sees the cumulative diff across batches.</li> <li><strong>No wrap-up Reviewer at Step 4 (D5).</strong> Wrap-up is §12.1 trivial — delete task file + memory append + chore commit is mechanical and the orchestrator performs it inline. The previous Reviewer at Step 4 is dropped.</li> <li>Therefore — <code>thinking agents in usage summary >= batches + 1</code>. Floor lowered from +2 to +1 per round 2 D5: the wrap-up Reviewer is dropped because wrap-up is §12.1 trivial. If your dispatch run includes a final integration review (conditions for D7 skip not met), the floor adapts: <code>>= batches + 1</code> still holds because the integration review is the "+1". If the integration review skips AND all batches pass, <code>thinking agents = batches</code> exactly — which satisfies the floor since the +1 was the integration review that ran implicitly. The batched Reviewer counts as <strong>1</strong> per batch regardless of sub-task count. If less, a per-step reviewer was skipped. The task was done wrong.</li> <li>Any <code>SECURITY_VIOLATION</code> verdict from the batched Reviewer (or a per-sub-task reviewer) halts the chain immediately — no commits, no auto-continue. Same behavior regardless of whether review is batched or per-sub-task.</li> <li><strong>Usage summary fires ONLY at the very end of the chain — after Step 4 wrap-up. NEVER mid-batch. NEVER after partial sub-task completion.</strong> Printing <code>── Hyperflow Usage ──</code> with "B1W1 only" or "<n>/<m> sub-tasks completed" while sub-tasks remain pending is a doctrine violation, not a status update. In <code>auto</code> mode, a usage summary is a terminal signal — it means the chain is finished. If you printed one with sub-tasks still pending, the chain is in a broken state.</li> <li><strong>Auto mode must complete every sub-task in every batch before producing any summary, transition, or end-of-chain artefact.</strong> "To resume" instructions, partial usage tables, or "stopping here for now" prose are all forbidden in <code>auto</code> mode. The only legal terminations mid-chain are: (a) <code>SECURITY<em>VIOLATION</code>, (b) <code>ESCALATE: <reason></code> crossing the irreversibility boundary, (c) a per-sub-task Reviewer returning <code>NEEDS</em>FIX</code> after 3 worker retries (escalates to thinking-tier worker; if that also fails, surfaces ESCALATE). If none of those fired and the chain stopped, surface as <code>ESCALATE: dispatch halted with N/M sub-tasks remaining — root cause unknown</code> and ask the user — do NOT print a partial usage summary as if the chain ended cleanly.</li> <li><strong>If batch dispatch is interrupted (token exhaustion, runtime crash, manual abort) — leave the task file's Status block intact with the partial <code>[x]</code> checkmarks, do NOT print a usage summary, do NOT print "To resume" hand-off instructions.</strong> The user can re-invoke <code>/hyperflow:dispatch --from-batch <n> <slug></code> on their own; the task file already reflects which sub-tasks completed. Hand-off instructions printed by a half-finished chain are themselves the bug — they make the user think the chain self-paused cleanly when it actually broke.</li> </ul> <h2>Doctrine</h2> <p>Full rules in <a href="references/DOCTRINE.md">DOCTRINE.md</a>. This skill is the execute phase invoked at the end of <code>/hyperflow:scope</code>.</p> <h2>Overview</h2> <p><code>/hyperflow:dispatch</code> is the workhorse phase — it reads a task file from <code>/hyperflow:scope</code> and executes it through the orchestrator pattern.</p> <p>Parallel Sonnet workers dispatched in a single message, per-batch Opus reviewers that send work back with <code>NEEDS_FIX</code>, a conditional final integration review (skipped when all batches pass first-try with no escalations), inline wrap-up, and (at the end of the auto-chain) ONE combined <code>AskUserQuestion</code> gate with both audit and deploy questions.</p> <p>Doctrine floor: thinking agents ≥ batches + 1 (per-batch reviewer + final integration when not skipped per D7; wrap-up Reviewer dropped per D5 / §12.1).</p> <h2>Prerequisites</h2> <ul> <li>A task file exists at <code>.hyperflow/tasks/<slug>.md</code> (produced by <code>/hyperflow:scope</code>).</li> <li><code>.hyperflow/profile.md</code>, <code>architecture.md</code>, <code>conventions.md</code> populated (Layer 0 context injected into worker prompts).</li> <li>Model routing config supports both thinking (Opus) and worker (Sonnet) tiers.</li> <li>Git repository for per-sub-task commits.</li> <li>For Step 5: <code>AskUserQuestion</code> popup available, or Codex chat fallback available — required for audit + deploy gates. Headless mode with no interactive channel skips gates with explicit warning.</li> </ul> <h2>Instructions</h2> <p>The numbered steps live in <a href="#step-0--choose-mode-only-if-invoked-directly--structural-gate">Step 0 — Choose mode</a> through <a href="#step-5--end-of-auto-chain--audit--deploy-gates">Step 5 — End of Auto-Chain</a> above. Summary:</p> <ol> <li>Ask <code>chain-mode</code> (auto / manual) if invoked directly — structural gate.</li> <li>Load task file from <code>.hyperflow/tasks/</code> — Read + schema check inline (atomic · §12.2.8).</li> <li>Per batch, run four sub-phases in sequence:</li> </ol> <ul> <li><strong>Step 2a</strong> — Composer Workers in parallel build worker prompts; Sonnet Reviewer confirms prompt set.</li> <li><strong>Step 2b</strong> — Worker fan-out (N parallel Workers); batched Sonnet Reviewer over the batch; parse verdicts (PASS / NEEDS<em>FIX / SECURITY</em>VIOLATION / OVERSIZE).</li> <li><strong>Step 2c</strong> — Layer 5 quality gates via a Worker + Sonnet Reviewer.</li> <li><strong>Step 2d</strong> — Per-sub-task commits + learnings synthesis via Writer.</li> </ul> <ol> <li>Final integration review — conditional (D7): skip if all batches PASSed first try + no escalations + no security flags. Otherwise: Opus Reviewer dispatched over cumulative diff; verdict routes to Step 4 (PASS), re-dispatch (NEEDS<em>FIX), or halt (SECURITY</em>VIOLATION). Atomic per §12.2.8.</li> <li>Wrap-up (§12.1 inline) — orchestrator deletes task file + appends memory + makes <code>chore(memory):</code> commit. No Reviewer (D5). Writer Agent required only if memory prose generation is non-trivial.</li> <li>ONE combined <code>AskUserQuestion</code> gate with both audit and deploy questions — process answers in order.</li> </ol> <h2>Output</h2> <p>Per-batch and per-sub-task agent labels print as they fire (<code>Implementer — creating auth middleware</code>, <code><strong>Reviewer</strong> — reviewing auth middleware output (L1-L3)</code>). After the full chain, the usage summary prints:</p> <pre><code> ── Hyperflow Usage ────────────────────── Thinking (Opus 4.8) 4 agents 52.3k tokens (3 batch reviewers + 1 final) Worker (Sonnet 4.6) 7 agents 154.1k tokens (5 implementers + 1 writer + 1 searcher) Total 11 agents 206.4k tokens ───────────────────────────────────────── </code></pre> <p>(Wrap-up Reviewer no longer appears in the Thinking row per D5. If the integration review skipped per D7, the Thinking count equals the batch count exactly.)</p> <p>Plus the End-of-Chain block listing batches, agents, and per-sub-task commits.</p> <h2>Error Handling</h2> <table><thead><tr> <th>Failure</th> <th>Behavior</th> </tr></thead><tbody> <tr> <td>No task file at <code>.hyperflow/tasks/</code></td> <td>Stop and suggest <code>/hyperflow:scope</code> first.</td> </tr> <tr> <td>Worker times out or returns nothing</td> <td>Re-scope the sub-task into smaller pieces; redispatch. Max 2 re-scope attempts before escalating to a thinking-tier worker.</td> </tr> <tr> <td>Reviewer returns <code>NEEDS_FIX</code></td> <td>Re-dispatch worker with the fix list. Max 3 retries before escalating reviewer + worker pair to Opus + Opus.</td> </tr> <tr> <td>Reviewer returns <code>SECURITY_VIOLATION</code></td> <td><strong>Halt the chain immediately.</strong> Print finding; do not commit, do not auto-continue. User decides remediation.</td> </tr> <tr> <td>Layer 5 gate failure (lint/typecheck/test)</td> <td>Worker fix + re-run. Max 3 gate cycles before escalating.</td> </tr> <tr> <td>Per-sub-task commit fails (hook rejects, conflict)</td> <td>Stop; surface the hook error. Do NOT use <code>--no-verify</code>. Do NOT amend per-sub-task commits.</td> </tr> <tr> <td>Wrap-up memory append has duplicate entries (detected post-commit)</td> <td><code>git revert HEAD</code> reverts the chore(memory) commit; orchestrator rewrites and recommits. No Reviewer to catch this inline — <code>git log</code> and <code>git revert</code> are the recovery path.</td> </tr> <tr> <td><code>AskUserQuestion</code> popup unavailable in Codex</td> <td>Print audit/deploy as a <code>Hyperflow Question</code> chat block and wait for the user's answers.</td> </tr> <tr> <td>No interactive channel for audit/deploy gates</td> <td>Print end-of-chain block with <code>Audit/Deploy gates skipped — interactive mode required</code>. Do NOT silently auto-invoke either.</td> </tr> <tr> <td>Thinking-agent count < batches + 1 at end (when integration review ran)</td> <td>Print explicit doctrine violation warning in usage summary. Suggests a per-step reviewer was skipped.</td> </tr> </tbody></table> <h2>Examples</h2> <p>Worked transcripts moved to <a href="references/examples.md">examples.md</a> so the SKILL body stays lean. The examples are illustrative — not load-bearing for behaviour. Read the companion file when you want to see end-to-end transcripts.</p> <h2>Resources</h2> <ul> <li><a href="references/DOCTRINE.md">DOCTRINE.md</a> — orchestration rules (especially #8 structural gates, #12 per-step agents).</li> <li><a href="references/worker-prompt.md">worker-prompt.md</a> — Sonnet implementer/searcher/writer template.</li> <li><a href="references/reviewer-prompt.md">reviewer-prompt.md</a> — Opus reviewer template (per-sub-task fallback).</li> <li><a href="../hyperflow/reviewer-prompt-batched.md">reviewer-prompt-batched.md</a> — Opus batched reviewer template (P2).</li> <li><a href="../spec/references/latency-patterns.md">latency-patterns.md</a> — P1–P5 latency patterns; P2 dispatch win ~75% reviewer-phase latency.</li> <li><a href="references/review-levels.md">review-levels.md</a> — L1-L5 checklist.</li> <li><a href="references/memory-system.md">memory-system.md</a> — wrap-up memory append format.</li> <li><a href="references/quality-gates.md">quality-gates.md</a> — Layer 5 lint/typecheck/test policy.</li> <li><a href="references/git-workflow.md">git-workflow.md</a> — per-sub-task commit cadence, no AI attribution.</li> <li><a href="references/output-style.md">output-style.md</a> — agent label + usage summary format.</li> </ul></div> </div> </section>  <section class="detail-cta" data-astro-cid-qcigfm7x> <h2 class="detail-cta__headline" data-astro-cid-qcigfm7x>Ready to use hyperflow?</h2> <div class="detail-cta__actions" data-astro-cid-qcigfm7x> <button class="detail-cta__primary" data-copy-install="/plugin install hyperflow@claude-code-plugins-plus" data-astro-cid-qcigfm7x> <svg width="16" height="16" viewBox="0 0 16 16" fill="none" aria-hidden="true" data-astro-cid-qcigfm7x> <rect x="5" y="5" width="9" height="9" rx="1.5" stroke="currentColor" stroke-width="1.5" data-astro-cid-qcigfm7x></rect> <path d="M3 11V3a1 1 0 011-1h8" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" data-astro-cid-qcigfm7x></path> </svg> <span class="detail-cta__btn-text" data-astro-cid-qcigfm7x>Copy Install Command</span> </button> </div> </section> <script type="module">document.querySelectorAll("[data-copy-install]").forEach(t=>{t.addEventListener("click",async()=>{const a=t.dataset.copyInstall||"";await navigator.clipboard.writeText(a);const e=t.querySelector(".detail-cta__btn-text");if(e){const o=e.textContent;e.textContent="Copied!",t.classList.add("copied"),window.trackEvent&&window.trackEvent("install_copied",{plugin_name:a.split(" ").pop()||"",source:"detail_cta"}),setTimeout(()=>{e.textContent=o,t.classList.remove("copied")},2e3)}})});</script>  <section class="related-skills-section" data-astro-cid-jrlgpo3w> <h2 class="related-skills-heading" data-astro-cid-jrlgpo3w>Related Skills</h2> <div class="related-skills-grid" data-astro-cid-jrlgpo3w> <a href="/skills/agency-os/" class="related-skill-card" data-astro-cid-jrlgpo3w> <h3 class="related-skill-title" data-astro-cid-jrlgpo3w>agency-os</h3> <p class="related-skill-description" data-astro-cid-jrlgpo3w>Notion-as-source-of-truth dispatch board for running your work like an AI agency.</p> <div class="related-skill-tools" data-astro-cid-jrlgpo3w> <span class="related-tool-pill" data-astro-cid-jrlgpo3w>Read</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Write</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Edit</span> </div> </a><a href="/skills/amplify/" class="related-skill-card" data-astro-cid-jrlgpo3w> <h3 class="related-skill-title" data-astro-cid-jrlgpo3w>amplify</h3> <p class="related-skill-description" data-astro-cid-jrlgpo3w>Use when a prompt is rough, vague, or under-specified and you want it rewritten to high quality before running it.</p> <div class="related-skill-tools" data-astro-cid-jrlgpo3w> <span class="related-tool-pill" data-astro-cid-jrlgpo3w>Read</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Glob</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Grep</span> </div> </a><a href="/skills/apex/" class="related-skill-card" data-astro-cid-jrlgpo3w> <h3 class="related-skill-title" data-astro-cid-jrlgpo3w>apex</h3> <p class="related-skill-description" data-astro-cid-jrlgpo3w>Engineering lead — hand Apex any task and it routes internally.</p> <div class="related-skill-tools" data-astro-cid-jrlgpo3w> <span class="related-tool-pill" data-astro-cid-jrlgpo3w>Read</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Write</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Edit</span> </div> </a><a href="/skills/apex-plan/" class="related-skill-card" data-astro-cid-jrlgpo3w> <h3 class="related-skill-title" data-astro-cid-jrlgpo3w>apex-plan</h3> <p class="related-skill-description" data-astro-cid-jrlgpo3w>Plan and scope a project — discovery, challenge assumptions, present S/M/L options with token and cost estimates.</p> <div class="related-skill-tools" data-astro-cid-jrlgpo3w> <span class="related-tool-pill" data-astro-cid-jrlgpo3w>Read</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Write</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Edit</span> </div> </a><a href="/skills/apex-recon/" class="related-skill-card" data-astro-cid-jrlgpo3w> <h3 class="related-skill-title" data-astro-cid-jrlgpo3w>apex-recon</h3> <p class="related-skill-description" data-astro-cid-jrlgpo3w>Engineering lead reconnaissance — inventory the project before planning.</p> <div class="related-skill-tools" data-astro-cid-jrlgpo3w> <span class="related-tool-pill" data-astro-cid-jrlgpo3w>Read</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Bash</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Glob</span> </div> </a><a href="/skills/apex-review/" class="related-skill-card" data-astro-cid-jrlgpo3w> <h3 class="related-skill-title" data-astro-cid-jrlgpo3w>apex-review</h3> <p class="related-skill-description" data-astro-cid-jrlgpo3w>Cross-cutting review of recent work — catches gaps between specialists.</p> <div class="related-skill-tools" data-astro-cid-jrlgpo3w> <span class="related-tool-pill" data-astro-cid-jrlgpo3w>Read</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Write</span><span class="related-tool-pill" data-astro-cid-jrlgpo3w>Edit</span> </div> </a> </div> </section>  <footer class="skill-footer" data-astro-cid-jrlgpo3w> <p data-astro-cid-jrlgpo3w>Part of <a href="/plugins/hyperflow/" data-astro-cid-jrlgpo3w>hyperflow</a></p> </footer> </div> <script> document.querySelectorAll('.install-command').forEach(el => { el.addEventListener('click', function() { const text = this.dataset.copy || this.textContent; navigator.clipboard.writeText(text).then(() => { const originalText = this.textContent; this.textContent = 'Copied to clipboard!'; this.style.color = 'var(--brand-green)'; setTimeout(() => { this.textContent = originalText; this.style.color = ''; }, 2000); }); }); }); </script> </main>  <footer data-astro-cid-37fxchfa> <div class="footer-inner" data-astro-cid-37fxchfa> <div class="footer-signup-row" data-astro-cid-37fxchfa> <h4 data-astro-cid-37fxchfa>Stay in the Loop</h4> <form data-signup-form="footer" class="footer-signup-form" data-astro-cid-37fxchfa> <input type="email" name="email" placeholder="you@example.com" required data-astro-cid-37fxchfa> <input type="text" name="website" tabindex="-1" autocomplete="off" aria-hidden="true" style="position:absolute;left:-9999px;opacity:0;height:0;width:0;" data-astro-cid-37fxchfa> <button type="submit" data-astro-cid-37fxchfa>Subscribe</button> </form> <p class="footer-form-note" data-astro-cid-37fxchfa>No spam. Unsubscribe anytime.</p> </div> <div class="footer-columns" data-astro-cid-37fxchfa> <div class="footer-col" data-astro-cid-37fxchfa> <h5 data-astro-cid-37fxchfa>Product</h5> <ul data-astro-cid-37fxchfa> <li data-astro-cid-37fxchfa><a href="/explore" data-astro-cid-37fxchfa>Explore</a></li> <li data-astro-cid-37fxchfa><a href="/skills" data-astro-cid-37fxchfa>Skills</a></li> <li data-astro-cid-37fxchfa><a href="/cowork" data-astro-cid-37fxchfa>Cowork</a></li> <li data-astro-cid-37fxchfa><a href="/compare-marketplaces" data-astro-cid-37fxchfa>Compare</a></li> <li data-astro-cid-37fxchfa><a href="/tools" data-astro-cid-37fxchfa>Tools</a></li> </ul> </div> <div class="footer-col" data-astro-cid-37fxchfa> <h5 data-astro-cid-37fxchfa>Resources</h5> <ul data-astro-cid-37fxchfa> <li data-astro-cid-37fxchfa><a href="/docs" data-astro-cid-37fxchfa>Docs</a></li> <li data-astro-cid-37fxchfa><a href="/changelog" data-astro-cid-37fxchfa>Changelog</a></li> <li data-astro-cid-37fxchfa><a href="/collections" data-astro-cid-37fxchfa>Collections</a></li> <li data-astro-cid-37fxchfa><a href="/playbooks" data-astro-cid-37fxchfa>Playbooks</a></li> <li data-astro-cid-37fxchfa><a href="/research" data-astro-cid-37fxchfa>Research</a></li> <li data-astro-cid-37fxchfa><a href="/learning" data-astro-cid-37fxchfa>Learning</a></li> </ul> </div> <div class="footer-col" data-astro-cid-37fxchfa> <h5 data-astro-cid-37fxchfa>Company</h5> <ul data-astro-cid-37fxchfa> <li data-astro-cid-37fxchfa><a href="/community" data-astro-cid-37fxchfa>Community</a></li> <li data-astro-cid-37fxchfa><a href="/community#hall-of-fame" data-astro-cid-37fxchfa>Hall of Fame</a></li> <li data-astro-cid-37fxchfa><a href="https://github.com/jeremylongshore/claude-code-plugins" target="_blank" data-astro-cid-37fxchfa>GitHub</a></li> </ul> </div> <div class="footer-col" data-astro-cid-37fxchfa> <h5 data-astro-cid-37fxchfa>Legal</h5> <ul data-astro-cid-37fxchfa> <li data-astro-cid-37fxchfa><a href="/privacy" data-astro-cid-37fxchfa>Privacy</a></li> <li data-astro-cid-37fxchfa><a href="/terms" data-astro-cid-37fxchfa>Terms</a></li> <li data-astro-cid-37fxchfa><a href="/acceptable-use" data-astro-cid-37fxchfa>Acceptable Use</a></li> </ul> </div> </div> <div class="footer-bottom" data-astro-cid-37fxchfa> <p class="footer-blurb" data-astro-cid-37fxchfa>Tons of Skills by <a href="https://intentsolutions.io" target="_blank" data-astro-cid-37fxchfa>Intent Solutions</a>. Marine. Citadel Grad. 20 years ops → self-taught dev → AI architect.</p> <p class="footer-copyright" data-astro-cid-37fxchfa>© 2026 Tons of Skills | <a href="https://intentsolutions.io" target="_blank" data-astro-cid-37fxchfa>Intent Solutions</a></p> </div> </div> </footer>   <script type="module"> (() => { const flash = (btn, msg, ok = true, restoreMs = 3000) => { const orig = btn.dataset.origText ?? btn.textContent; if (!btn.dataset.origText) btn.dataset.origText = orig; btn.textContent = msg; btn.style.opacity = ok ? '0.85' : '1'; btn.disabled = ok; if (!ok) setTimeout(() => { btn.textContent = orig; btn.style.opacity = ''; btn.disabled = false; }, restoreMs); }; const wireSignup = (form) => form.addEventListener('submit', async (e) => { e.preventDefault(); const btn = form.querySelector('button[type="submit"]'); const emailInput = form.querySelector('input[type="email"]'); const honey = form.querySelector('input[name="website"]'); const email = (emailInput?.value || '').trim(); if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) { flash(btn, 'Invalid email', false); return; } flash(btn, 'Subscribing…', true, 0); try { const r = await fetch('/api/forms/signup', { method: 'POST', headers: { 'content-type': 'application/json' }, body: JSON.stringify({ email, source: form.dataset.signupForm || 'unknown', website: honey?.value || '' }) }); if (r.ok) { flash(btn, "You're in!", true, 0); if (emailInput) emailInput.value = ''; } else if (r.status === 429) { flash(btn, 'Slow down', false); } else { const j = await r.json().catch(() => ({})); flash(btn, j.error || 'Something went wrong', false); } } catch { flash(btn, 'Network error', false); } }); const wireNomination = (form) => form.addEventListener('submit', async (e) => { e.preventDefault(); const btn = form.querySelector('button[type="submit"]'); const repoInput = form.querySelector('input[name="repo"]'); const honey = form.querySelector('input[name="website"]'); const repoUrl = (repoInput?.value || '').trim(); if (!/^https:\/\/github\.com\/[^/\s]+\/[^/\s]+/.test(repoUrl)) { flash(btn, 'GitHub URL only', false); return; } flash(btn, 'Submitting…', true, 0); try { const r = await fetch('/api/forms/nominate', { method: 'POST', headers: { 'content-type': 'application/json' }, body: JSON.stringify({ repoUrl, source: form.dataset.nominationForm || 'unknown', website: honey?.value || '' }) }); if (r.ok) { flash(btn, 'Submitted!', true, 0); if (repoInput) repoInput.value = ''; } else if (r.status === 429) { flash(btn, 'Slow down', false); } else { const j = await r.json().catch(() => ({})); flash(btn, j.error || 'Something went wrong', false); } } catch { flash(btn, 'Network error', false); } }); const wireContact = (form) => form.addEventListener('submit', async (e) => { e.preventDefault(); const btn = form.querySelector('button[type="submit"]'); const nameInput = form.querySelector('input[name="name"]'); const emailInput = form.querySelector('input[type="email"]'); const messageInput = form.querySelector('textarea[name="message"]'); const honey = form.querySelector('input[name="website"]'); const name = (nameInput?.value || '').trim(); const email = (emailInput?.value || '').trim(); const message = (messageInput?.value || '').trim(); if (name.length < 2) { flash(btn, 'Name required', false); return; } if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) { flash(btn, 'Invalid email', false); return; } if (message.length < 10) { flash(btn, 'Tell me more', false); return; } flash(btn, 'Sending…', true, 0); try { const r = await fetch('/api/forms/contact', { method: 'POST', headers: { 'content-type': 'application/json' }, body: JSON.stringify({ name, email, message, source: form.dataset.contactForm || 'unknown', website: honey?.value || '' }) }); if (r.ok) { flash(btn, "Got it — back within 24h!", true, 0); if (nameInput) nameInput.value = ''; if (emailInput) emailInput.value = ''; if (messageInput) messageInput.value = ''; } else if (r.status === 429) { flash(btn, 'Slow down', false); } else { const j = await r.json().catch(() => ({})); flash(btn, j.error || 'Something went wrong', false); } } catch { flash(btn, 'Network error', false); } }); const init = () => { document.querySelectorAll('[data-signup-form]').forEach(wireSignup); document.querySelectorAll('[data-nomination-form]').forEach(wireNomination); document.querySelectorAll('[data-contact-form]').forEach(wireContact); }; if (document.readyState === 'loading') { document.addEventListener('DOMContentLoaded', init); } else { init(); } })(); </script>  <script> document.addEventListener('DOMContentLoaded', function() { var themeToggle = document.querySelector('.theme-toggle'); if (themeToggle) { themeToggle.addEventListener('click', function() { var current = document.documentElement.getAttribute('data-theme') || 'dark'; var next = current === 'dark' ? 'light' : 'dark'; document.documentElement.setAttribute('data-theme', next); localStorage.setItem('theme', next); var meta = document.querySelector('meta[name="theme-color"]'); if (meta) meta.setAttribute('content', next === 'dark' ? '#0a0a0c' : '#fafaf9'); }); } window.matchMedia('(prefers-color-scheme: light)').addEventListener('change', function(e) { if (!localStorage.getItem('theme')) { document.documentElement.setAttribute('data-theme', e.matches ? 'light' : 'dark'); } }); }); </script>  <script> (function() { var nav = document.querySelector('nav'); if (!nav) return; function onScroll() { if (window.scrollY > 20) { nav.classList.add('scrolled'); } else { nav.classList.remove('scrolled'); } } window.addEventListener('scroll', onScroll, { passive: true }); onScroll(); })(); </script>  <script> document.addEventListener('DOMContentLoaded', function() { var menuToggle = document.querySelector('.mobile-menu-toggle'); var navLinks = document.querySelector('.nav-links'); var menuIcon = document.querySelector('.menu-icon'); var closeIcon = document.querySelector('.close-icon'); if (menuToggle && navLinks) { menuToggle.addEventListener('click', function() { navLinks.classList.toggle('active'); document.body.classList.toggle('menu-open'); if (navLinks.classList.contains('active')) { menuIcon.style.display = 'none'; closeIcon.style.display = 'block'; } else { menuIcon.style.display = 'block'; closeIcon.style.display = 'none'; } }); navLinks.querySelectorAll('a').forEach(function(link) { link.addEventListener('click', function() { navLinks.classList.remove('active'); document.body.classList.remove('menu-open'); menuIcon.style.display = 'block'; closeIcon.style.display = 'none'; }); }); document.addEventListener('click', function(e) { if (navLinks.classList.contains('active') && !navLinks.contains(e.target) && !menuToggle.contains(e.target)) { navLinks.classList.remove('active'); document.body.classList.remove('menu-open'); menuIcon.style.display = 'block'; closeIcon.style.display = 'none'; } }); } // Track outbound link clicks (nav + footer) document.querySelectorAll('nav a[target="_blank"], footer a[target="_blank"]').forEach(function(link) { link.addEventListener('click', function() { if (window.trackEvent) { window.trackEvent('outbound_click', { url: link.href, link_text: link.textContent.trim() }); } }); }); }); </script> </body> </html>