Workflow

Big-task path for work that is too large for normal turn-by-turn orchestration: system-wide changes, large migrations, repo-wide audits, high-confidence verification, and task prompts that explicitly ask for a workflow.

• In Claude Code, use the host dynamic workflow runtime.
• In Codex, run the portable workflow adapter with Codex subagents when exposed; otherwise run the same phases inline in the current thread.
• In OpenCode, run the portable workflow adapter with Task/subagent dispatch when exposed; otherwise run the same phases inline in the current session.
• In Grok, run the portable workflow adapter with spawn_subagent when enabled; otherwise run the same phases inline in the current session.
• In Antigravity, Desktop/web bridge mode, or any host that cannot preserve the adapter phases, say so in one line and route to /hyperflow:plan with chain-mode=auto.

Claude Code dynamic workflows require Claude Code v2.1.154 or later and can be disabled by /config, managed settings, ~/.claude/settings.json, or CLAUDECODEDISABLE_WORKFLOWS=1. When disabled, use the portable adapter if the host is Codex, OpenCode, or Grok; otherwise route to /hyperflow:plan with chain-mode=auto.

Routing Rules

• Run this skill in Claude Code, Codex, OpenCode, and Grok.
• Auto-route here when triage returns flow=deep or flow=scientific, scope=system-wide, or the user says big task, large migration, repo-wide audit, run a workflow, or dynamic workflow.
• Do not route here for moderate multi-file work, routine bug fixes, or a task that needs user sign-off between implementation stages. Big-task workflow runs should not depend on arbitrary mid-run user input; split sign-off-heavy work into separate workflows or use spec -> scope -> dispatch.
• Do not set /effort ultracode or xhigh automatically. The user can enable /effort ultracode manually for session-wide workflow selection.

Provider Contracts

Claude Code Native Workflow

When this skill runs, ask the Claude Code workflow runtime to create a dynamic workflow for $ARGUMENTS. The generated workflow must preserve Hyperflow's doctrine inside the worker prompts and must include these phases:

1. Research and planning

• Map affected files, dependency edges, tests, docs, and risk boundaries.
• Read .hyperflow/profile.md, .hyperflow/architecture.md, .hyperflow/conventions.md, .hyperflow/testing.md, and .hyperflow/memory/index.md when present.
• Produce a concise execution graph with parallelizable units and dependencies.

1. Parallel implementation or investigation

• Fan out independent agents by subsystem or file family.
• Keep each agent brief specific: objective, files in scope, constraints, acceptance criteria, and test expectations.
• Use the lightest model/stage that can safely do the work when the runtime supports model routing.

1. Adversarial verification

• Run independent verification agents against each implementation or finding.
• For audits, verify each finding before reporting it.
• For implementation, check cross-file integration, regression risk, security-sensitive paths, and missed tests.

1. Quality gates and repair loop

• Run the project lint, typecheck, build, and relevant tests from .hyperflow/testing.md or detected package scripts.
• Retry focused fixes only for verified failures.
• Never use --no-verify; never force-push to main or master.

1. Final synthesis

• Return one coordinated result with completed work, verification evidence, unresolved risks, changed files, and next actions.
• For durable project learnings, identify what should be appended to .hyperflow/memory/, but do not invent memory entries unrelated to the run.

Codex Portable Workflow Adapter

Codex does not provide Claude Code's dynamic workflow runtime. Treat /hyperflow:workflow as a custom Hyperflow workflow envelope around Codex subagents and inline fallback:

1. Research and planning

• Read the same .hyperflow/ cache files listed above when present.
• Write or update .hyperflow/tasks/.md for implementation or audit work that needs durable progress tracking.
• Build an execution graph with parallelizable units, dependencies, expected commits, and verification commands.

1. Parallel implementation or investigation

• If Codex subagent tools are exposed, dispatch independent searcher/worker/writer units together and collect their results before review.
• Map implementation and writing tasks to worker subagents; map codebase research to explorer/search subagents.
• If subagents are unavailable, run each unit inline with explicit worker and reviewer labels.

1. Adversarial verification

• Run a separate verification pass for each completed unit before reporting it.
• Use Codex thinking defaults for verification and final integration review.

1. Quality gates and commits

• Run the detected lint, typecheck, build, and relevant tests.
• Commit each accepted unit separately using conventional commits.
• Never use --no-verify; never request xhigh.

1. Final synthesis

• Return changed files, verification evidence, unresolved risks, and next actions.

OpenCode Portable Workflow Adapter

OpenCode does not provide Claude Code's dynamic workflow runtime. Treat /hyperflow:workflow as a custom Hyperflow workflow envelope around OpenCode's task/subagent facilities and inline fallback:

1. Research and planning

• Read the same .hyperflow/ cache files listed above when present.
• Write or update .hyperflow/tasks/.md for implementation or audit work that needs durable progress tracking.
• Build an execution graph with parallelizable units, dependencies, expected commits, and verification commands.

1. Parallel implementation or investigation

• If OpenCode exposes Task/subagent dispatch, send independent implementation or investigation units through that path.
• Keep each subtask bounded by objective, files in scope, constraints, acceptance criteria, and tests.
• If task dispatch is unavailable, run each unit inline with explicit worker and reviewer labels.

1. Adversarial verification

• Run a separate verification pass for each completed unit before reporting it.
• Run verification and the final integration review as decision-agent passes on the current session model.

1. Quality gates and commits

• Run the detected lint, typecheck, build, and relevant tests.
• Commit each accepted unit separately using conventional commits.
• Never use --no-verify.

1. Final synthesis

• Return changed files, verification evidence, unresolved risks, and next actions.

Grok Portable Workflow Adapter

Grok does not provide Claude Code's dynamic workflow runtime. Treat /hyperflow:workflow as a custom Hyperflow workflow envelope around Grok spawn_subagent and inline fallback:

1. Research and planning

• Read the same .hyperflow/ cache files listed above when present.
• Write or update .hyperflow/tasks/.md for implementation or audit work that needs durable progress tracking.
• Build an execution graph with parallelizable units, dependencies, expected commits, and verification commands.

1. Parallel implementation or investigation

• If spawnsubagent is available and subagents are not disabled (GROKSUBAGENTS / config), dispatch independent units together:
• implementer/writer → subagent_type: general-purpose
• searcher/research → subagent_type: explore
• Collect results before review; spawn independent siblings in parallel when the runtime allows.
• If subagents are unavailable, run each unit inline with explicit worker and reviewer labels.

1. Adversarial verification

• Run a separate verification pass for each completed unit before reporting it.
• Run verification and the final integration review as decision-agent passes on the current session model.

1. Quality gates and commits

• Run the detected lint, typecheck, build, and relevant tests.
• Commit each accepted unit separately using conventional commits.
• Never use --no-verify.

1. Final synthesis

• Return changed files, verification evidence, unresolved risks, and next actions.

Claude Code Prompt Skeleton

Use this shape when handing the task to the workflow runtime:

Create a dynamic workflow for this Hyperflow big-task run.

Task:
<user task>

Doctrine:
- Preserve Hyperflow autonomy: execute reversible work without invented confirmations.
- Ask only for genuine ambiguity after codebase research.
- Keep plans, task decompositions, audits, and memory under .hyperflow/ when files are needed.
- Use conventional commits, one distinct task per commit.
- Never use --no-verify and never force-push to main/master.
- Respect the Hyperflow security blocklist in skills/hyperflow/security.md.

Required phases:
1. Research and planning.
2. Parallel implementation or investigation.
3. Adversarial verification.
4. Quality gates and focused repair loop.
5. Final synthesis.

Acceptance:
- Every substantive result is independently checked before being reported.
- Quality gates run or are explicitly marked unavailable with the command attempted.
- The final answer includes evidence, changed files, unresolved risks, and next actions.

Save For Reuse

When a run succeeds and the user will repeat it, mention that Claude Code can save the generated workflow from /workflows with s. Project workflows save under .claude/workflows/; personal workflows save under ~/.claude/workflows/. Do not create those files directly from this skill because plugin packaging does not currently ship .claude/workflows/ as a first-class component.

Codex, OpenCode, and Grok adapters are not saved through /workflows; repeatable behavior comes from this skill, .hyperflow/tasks/, project memory, and provider-specific subagent/task configuration.