codex-general-workflow

name	codex-general-workflow
description	Use when a Codex task is complex, long-running, high-value, adversarial, repetitive, parallelizable, or likely to suffer from partial completion, self-review bias, or goal drift. Provides a reusable dynamic workflow harness for planning, delegation, verification, synthesis, and completion discipline across coding, research, analysis, review, triage, refactoring, debugging, writing, and decision tasks.
metadata	{"short-description":"Dynamic workflow harness for Codex tasks"}

Codex General Workflow

Use this skill to build a task-specific workflow before doing substantial work. The workflow should be just heavy enough for the task: use structure to buy quality, and avoid unnecessary process when a direct answer is enough.

Activation Test

Use the workflow when at least one condition is true:

• The task has many independent items, files, sources, candidates, hypotheses, or review comments.
• Correctness matters more than speed, and independent verification would reduce risk.
• The task may run long enough for goal drift, compaction loss, or partial completion to matter.
• The task benefits from comparing multiple approaches, opinions, rubrics, or hypotheses.
• The user asks for a workflow, audit, deep research, root-cause analysis, migration, broad refactor, ranking, triage, or recurring rule extraction.

Do not use the workflow for simple commands, narrow edits, small explanations, or routine changes that one focused pass can handle.

Operating Rules

• Preserve user constraints first. If repository or privacy guardrails exist, treat them as hard requirements.
• Keep the workflow visible: state the chosen workflow shape before major work.
• Set a concrete done condition. If the user provided one, reuse it exactly.
• Prefer parallel reads, searches, and independent checks when safe.
• Isolate risky actions. Agents or subprocesses that read untrusted content should not perform privileged writes, destructive commands, credential access, or external publication.
• Separate production from review. Do not let the same reasoning path be the only judge of its own output.
• Stop when the done condition is met, not when the first plausible answer appears.

Core Workflow

1. Frame

   • Restate the goal in one sentence.
   • List hard constraints, sensitive paths, irreversible actions, budget limits, and success criteria.
   • Decide whether the workflow should be light, standard, or deep.

2. Classify

   • Identify the task type: implementation, review, research, debugging, migration, triage, sorting, writing, decision, or rule extraction.
   • Pick only the patterns needed. See references/patterns.md when the task needs a specific orchestration pattern.

3. Decompose

   • Split the task into independent work units with explicit inputs and outputs.
   • Define each unit's allowed tools and forbidden actions.
   • Decide which units can run in parallel and which require ordering.

4. Execute

   • Use local repo conventions and existing tools before inventing new machinery.
   • For coding tasks, inspect before editing, make scoped changes, and run focused verification.
   • For research tasks, gather primary or high-quality sources, track citations, and distinguish sourced facts from inference.

5. Verify

   • Run independent checks against the original goal and constraints.
   • For high-risk work, use adversarial review: ask what would make the result wrong, incomplete, unsafe, or misleading.
   • For large sets, sample edge cases and the most important outputs, not only happy paths.

6. Synthesize

   • Merge outputs into one concise result.
   • Resolve conflicts by evidence, tests, source quality, or the user's rubric.
   • Report what changed, what was verified, and any residual risk.

Depth Levels

• Light: one plan, one execution pass, one verification pass. Use for medium tasks.
• Standard: decomposition, parallel work where possible, independent verification, synthesis. Use for broad or high-value tasks.
• Deep: competing hypotheses or approaches, adversarial reviewers, loop-until-done criteria, and explicit budget tracking. Use only when the quality gain justifies the extra tokens and time.

Completion Gate

Before final response, check:

• The original user request is answered, including the newest user message.
• Hard constraints and privacy rules were followed.
• All started tool sessions required for the task are resolved.
• Tests, renders, citations, or other verification were run when appropriate; if not, explain why.
• The final answer is concise and names the files, commands, links, or evidence the user needs.