codex-dynamic-workflows/SKILL.md
Plan and run Codex-native dynamic workflows for complex tasks that benefit from explicit orchestration, goal mode, subagents or simulated work packets, approval gates, integration, verification, and reusable workflow artifacts. Use when the user invokes this skill, asks for dynamic workflows, subagents, parallel agents, swarm-like work, Goal Maker orchestration, large audits, migrations, multi-track research plus implementation, or Claude Code-style fan-out/fan-in workflows.
npx skillsauth add oldwinter/skills codex-dynamic-workflowsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use this skill to turn a large task into a supervised Codex workflow: define a success contract, scaffold a durable workflow artifact, use goal mode when sustained execution is requested, fan out disjoint packets to Codex subagents when available, integrate results, verify the outcome, and save reusable recipes when the pattern is worth keeping.
This skill is inspired by pi-dynamic-workflows, but it is Codex-native. Do not claim a Pi-style workflow tool exists unless the current environment exposes one. When Codex subagent tools are unavailable, simulate the fan-out with isolated packet notes under .workflow/<slug>/results/.
Use dynamic orchestration when at least two are true:
For a small one-shot task, do the task directly and mention that workflow orchestration was unnecessary.
When using this skill:
pi-dynamic-workflows uses deterministic JavaScript with globals such as agent, parallel, pipeline, phase, log, args, cwd, and budget. In Codex, map those ideas like this:
| Pi concept | Codex-native equivalent |
| --- | --- |
| export const meta | plan.md goal, criteria, constraints, risks |
| phase(title) | plan checklist section and progress updates |
| agent(prompt, opts) | bounded subagent task or packet note |
| parallel(thunks) | multiple independent subagent tasks, or isolated packet passes |
| pipeline(items, ...stages) | staged packet sequence with fan-out per item |
| structured output schema | packet expected output contract |
| live progress display | state.json, plan updates, concise user updates |
| abort/cancel | stop spawning, mark running packets skipped, preserve partial results |
| token budget | max agent count, time/compute budget, approval gate |
For teams that already draft Pi-style workflow scripts, use the static adapter:
python3 /path/to/codex-dynamic-workflows/scripts/codex_workflow.py workflow.js --root .workflow
It validates literal meta, phase(), and agent() calls, rejects obvious nondeterminism, and converts agent calls into Codex packet files. It does not execute JavaScript.
Existing artifact directories are protected by default; pass --force only when intentionally regenerating a recognized workflow artifact.
Prefer creating a local run directory:
.workflow/<slug>/
|-- plan.md
|-- state.json
|-- orchestration.md
|-- packets/
|-- results/
|-- integration.md
`-- final-report.md
Scaffold it with:
python3 /path/to/codex-dynamic-workflows/scripts/new_workflow.py "Task title"
Keep plan.md human-readable. Use state.json for packet IDs, approval state, status, and verification evidence. Use orchestration.md as the executable mental model: phases, branching rules, packet prompts, and stop conditions.
Draft a concise plan with:
Goal:
Success criteria:
Current context:
Constraints:
Risks:
Approval required:
Workflow artifact path:
Work packets:
Integration policy:
Verification:
Reusable artifacts:
Do not over-plan obvious work. The plan should be detailed enough to guide delegation and verification, not a substitute for execution.
Ask one clear approval question before:
If approval is denied or unavailable, continue only with safe read-only planning, local drafts, dry runs, or non-destructive checks.
Read references/risk-gates.md when risk is unclear.
If goal mode tools are available and the user has asked for sustained execution, create or continue a goal with the full objective. Keep the objective intact; do not shrink it to the next step. Update the goal only when the overall objective is complete or genuinely blocked.
Do not enter goal mode for a small one-shot task, a purely advisory discussion, or a plan-only request.
Each packet must be self-contained:
Packet ID:
Objective:
Context:
Files / sources:
Ownership:
Do:
Do not:
Expected output:
Verification:
Stop condition:
Prefer disjoint ownership:
For code-edit packets, assign non-overlapping files or modules. Tell workers they are not alone in the codebase, must not revert others' edits, and must adapt to concurrent changes.
When a Codex subagent runner is available:
When no subagent runner is available:
results/.Prefer these packet result sections when they apply:
## Accepted
## Rejected
## Conflicts
## Decisions
## Risks
## Verification
After packets complete, synthesize:
Accepted:
Rejected:
Conflicts:
Decisions:
Final changes:
Remaining risks:
Verification evidence:
Resolve conflicts explicitly. If packets disagree, inspect authoritative sources before choosing.
Use:
python3 /path/to/codex-dynamic-workflows/scripts/collect_results.py .workflow/<slug> --output .workflow/<slug>/integration.md
collect_results.py groups the packet result sections above into an integration
draft and falls back to checklist-like lines for unstructured notes.
Run the narrowest reliable checks first, then broaden as risk warrants:
Use:
python3 /path/to/codex-dynamic-workflows/scripts/verify_workflow.py .workflow/<slug>
This verifies required files, required directories, JSON readability, known
state keys, matching workflow slug, unique packet IDs, matching packet files,
known status values, and valid relative results/*.md paths.
For final fan-in, prefer:
python3 /path/to/codex-dynamic-workflows/scripts/verify_workflow.py .workflow/<slug> --require-all-results
Report skipped checks honestly. Do not treat a workflow as complete until evidence proves the original success criteria.
When a run produces a useful pattern, save a concise recipe in a project-appropriate place, such as .workflow/recipes/<name>.md or a docs folder. Include:
Do not save transcripts, secrets, bulky logs, credentials, or sensitive personal details.
references/pi-comparison.md when adapting Pi dynamic workflow ideas to Codex.references/plan-schema.md when a machine-readable workflow plan is useful.references/risk-gates.md before risky or ambiguous operations.references/validation-examples.md when testing or improving this skill.devops
Deploy applications and infrastructure to Cloudflare using Workers, Pages, and related platform services. Use when the user asks to deploy, host, publish, or set up a project on Cloudflare.
tools
This skill should be used when users need to manage AWS Support cases via CLI. It handles listing cases (recent 2 weeks, unresolved), viewing case details with bilingual display (English-Chinese line by line), creating new cases with auto-detected service/category, replying to cases, and attachment handling. Triggers on requests mentioning "AWS support", "support case", "工单", "support ticket", or AWS technical support inquiries.
testing
This skill should be used when users need to query AWS cost and usage details for a specific date. It supports querying costs at service level (e.g., EC2, S3, RDS) and drilling down to usage type level (e.g., instance types, storage classes, data transfer). Triggers on requests mentioning AWS costs, billing, spending, cost breakdown, or fee analysis.
tools
This skill should be used when users need to interact with AWS services via CLI. It covers all AWS services including EC2, ECS, EKS, Lambda, S3, RDS, DynamoDB, VPC, Route53, CloudFront, Bedrock, Support, Billing, and more. Supports querying, creating, modifying, deleting resources, monitoring, debugging, and cost analysis. Triggers on requests mentioning AWS, cloud resources, or specific AWS service names.