workflow

# 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 Antigravity, Desktop/web bridge mode, or any host that cannot preserve the adapter phases, say so in one line and route to `/hyperflow:scope` 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 `CLAUDE_CODE_DISABLE_WORKFLOWS=1`. When disabled, use the portable adapter if the host is Codex or OpenCode; otherwise route to `/hyperflow:scope` with `chain-mode=auto`.

## Routing Rules

- Run this skill in Claude Code, Codex, and OpenCode.
- 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.

2. 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.

3. 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.

4. 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.

5. 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/<slug>.md` for implementation or audit work that needs durable progress tracking.
   - Build an execution graph with parallelizable units, dependencies, expected commits, and verification commands.

2. 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.

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

4. 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`.

5. 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/<slug>.md` for implementation or audit work that needs durable progress tracking.
   - Build an execution graph with parallelizable units, dependencies, expected commits, and verification commands.

2. 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 worke