Claude Code added Dynamic Workflows.
Dynamic Workflows are a way to run larger coding tasks as a sequence of planned steps. Claude Code can split the work, run independent parts, check the results, and integrate the final answer.
For small tasks, this is unnecessary. One agent can edit directly.
For larger tasks, the sequence is:
plan -> split -> run independent work -> check results -> integrate -> verify
Anthropic also describes an ultracode setting for Claude Code. It uses higher effort and can decide when to turn a task into a Dynamic Workflow.
Codex does not have that exact feature.
However, Codex already has two relevant pieces:
- skills, loaded from
SKILL.md - subagents, when the host environment exposes them
Codex can follow the same sequence, but it is not the same native implementation.
Summary:
Claude Code has native Dynamic Workflows.
Codex can approximate the same procedure with a skill.
Repo:
https://github.com/PabloNAX/ultracode-skill
What Claude Code added
Dynamic Workflows are for tasks that are too large for a single pass.
For example:
- repo-wide bug hunts
- migrations
- security audits
- work that needs independent verification
- work where several files or systems have to be understood before editing
The workflow is:
The orchestration does not happen inside one normal reply.
In a normal chat loop, the model has to keep planning, editing, checking, and summarizing in one stream. That works for small jobs. It gets messy when the task is large.
Dynamic Workflows make the work explicit:
- first plan
- then split
- then run independent parts
- then check
- then integrate
There is a cost trade-off. Anthropic warns that Dynamic Workflows can use much more than a normal Claude Code session, and the first workflow trigger asks for confirmation.
Parallel agents increase usage.
What Codex already has
Codex is different.
It does not expose Claude Code's Dynamic Workflows as a native feature. There is no official Codex ultracode mode that automatically runs the same system.
But Codex has skills.
A skill is a small instruction package. It can teach the agent how to behave for a class of tasks.
For this use case, the skill defines:
- when to keep the task direct
- when to make a plan
- when to split work
- when to use subagents
- what stays in the parent session
- how the final result gets checked
Codex can reproduce the operating procedure, not the native Claude Code implementation.
The practical mapping
The Ultracode skill uses three modes.
Direct mode is for small tasks.
Fix one typo. Read one file. Answer one narrow question. No workflow folder needed.
Workflow mode is for non-trivial work that needs a plan but does not need parallel agents.
The skill writes simple local artifacts:
.workflow/ultracode/<run-slug>/
plan.md
orchestration.md
state.json
packets/
results/
integration.md
final-report.md
Delegated mode is for tasks that can be split into independent checks or edits.
When native subagent tools are available, Codex can use spawn_agent for independent work.
In practice:
-
exploreragents inspect code and gather facts -
workeragents only edit when the write scope is clear - the parent session integrates the result
- tests, builds, linters, or browser checks verify the final state
The parent session still owns the final answer.
Subagents produce partial results. The parent session integrates them.
Shared procedure
The shared behavior is:
- a large task gets planned
- independent work is separated
- parallelism is used only for independent work
- results are checked before integration
- verification happens at the end
This reduces one common failure mode in AI coding: a polished final answer without evidence.
The model is still capable of making mistakes. The difference is that the workflow leaves evidence: plans, separate results, integration notes, and verification output.
Implementation differences
The implementation is different.
Claude Code Dynamic Workflows are an official Claude Code feature.
Claude Code's ultracode setting is tied to Claude Code behavior.
Codex does not have that exact feature.
The Codex version is a skill. It defines how Codex should use skills, subagents, local artifacts, and verification commands.
In plain terms: Claude Code owns the native feature. Codex follows the procedure through a skill.
Prompt examples
For a normal task:
Use $ultracode to implement this feature end to end and verify it.
For a task where parallel work may help:
Use $ultracode. Use parallel agents when the task can be split, keep integration in the parent session, and verify the final patch.
That second sentence defines the delegation rule.
A skill can describe when to delegate. The current host environment still controls whether delegation is available.
Install
Codex:
mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
cp -R ultracode "${CODEX_HOME:-$HOME/.codex}/skills/"
Claude Code:
mkdir -p "$HOME/.claude/skills"
cp -R ultracode "$HOME/.claude/skills/"
Antigravity workspace install:
mkdir -p .agents/skills
cp -R /path/to/ultracode .agents/skills/
Restart the tool after installing so it reloads the skill list.
Why there is no required Python runner
Some workflow systems use helper scripts. That can help with scaffolding or validation.
But the core of this skill is not a runner.
In Codex, subagents are launched by Codex.
In Claude Code, Dynamic Workflows are launched by Claude Code.
A portable skill should leave orchestration to the host tool.
The core file is SKILL.md.
When to use it
Good fit:
- repo-wide audits
- migrations
- feature work with discovery and tests
- security review
- risky changes that need independent checking
Bad fit:
- tiny edits
- one-file fixes
- tasks where agents would duplicate the same search
- tasks where low usage takes priority over extra checking
Rule:
Small tasks should stay small.
Large tasks should leave evidence.


Top comments (2)
Dynamic workflows packaged as a skill is the right shape, because it's the difference between an agent that improvises every time and one that follows a structure you can inspect and trust. A skill is essentially a reusable, named procedure with a contract, which is exactly what you want when a workflow needs to be repeatable: same triggers, same steps, same guardrails, instead of hoping the model reconstructs the right plan from scratch on every run. The dynamic part is where it gets interesting, because the win is a workflow that has structure where structure matters (the order, the checkpoints, the irreversible-step gates) but flexibility where judgment matters (which branch, what content), rather than a rigid script that breaks on anything unexpected or a free-for-all that's different every time. That structured-but-adaptive middle is hard to hit and it's the whole game. Bringing Claude-style skills to Codex is a nice portability point too, the methodology generalizes across models, which reinforces that the leverage is in the skill/harness, not any one model. Encode the workflow as an inspectable skill, keep the dynamism inside the guardrails. That structure-where-it-matters-flexibility-where-it-helps instinct is core to how I think about Moonshift. In your dynamic workflows, what stays fixed in the skill versus what you let the model decide at runtime?
top !