codework

name

codework

description

Run the recurring repo delivery loop: choose or clarify the next goal, run the real ralplan gate, implement through ultragoal or ultrawork, open a PR, run code review, wait for CI/DCO, fix failures, then ask for human-in-the-loop merge approval before merging and syncing. Use when the user says codework, asks for the next implementation cycle, or wants planning-to-PR automation with explicit HITL before merge.

Codework

Use codework when the user wants the full coding delivery cycle, not just a plan or a patch.

Default Outcome

Deliver one merge-ready PR automatically, then stop for human-in-the-loop approval before merging.

Do not merge on standing authority alone. Even if the user says "merge까지", "끝까지", "ship it", or invokes codework in a repo where prior standing instructions allow merge, ask a final HITL merge question after review and checks pass. Merge and sync only after the user gives an affirmative response to that final question in the current thread/session.

If the user does not approve, declines, or is unavailable, stop at a merge-ready PR with review and CI evidence.

Delivery Grain

Treat one user goal as one PR by default.

Use multiple focused commits inside that PR when it improves reviewability: planning docs, implementation, tests, review fixes, CI fixes, and small follow-up documentation can all belong to the same goal PR.

Do not split review feedback, test fixes, DCO/CI fixes, or small follow-up adjustments into a new PR merely because a commit already exists. Keep fixing the active PR until the goal is review-clean and check-clean.

Split only when the next change has a different user-facing goal, independent release or rollback value, materially different risk, a blocking external decision, or explicit user instruction to stack/split PRs.

Workflow Spine

codework is not a mini planning shortcut. Its normal path is:

$ralplan -> $ultragoal or $ultrawork -> PR -> $code-review -> CI/DCO -> HITL merge approval -> merge/sync

Use the real workflow surfaces whenever they are available:

• In an attached OMX CLI/tmux runtime, invoke the corresponding OMX workflows (omx ralplan, omx ultragoal or omx ultrawork, and code review).
• In Codex App or another non-tmux surface, load and follow the named skills directly as native skill workflows.
• Do not replace the ralplan gate with a casual local summary for normal codework. A compact inline plan is only a fallback for tiny, reversible changes or when the full workflow surface is unavailable.

Loop

1. Next Goal

   • If the user gives a concrete goal, use it.
   • If the goal is optional or says "next", choose the next highest-leverage repo task from current evidence: recent analysis, TODOs, failing checks, PR comments, roadmap docs, review findings, or obvious maintainability debt.
   • Do not invent product direction that depends on taste, business priority, credentials, production access, or destructive changes. For those, ask one concise question.
   • State the chosen goal, why it is next, and the stop condition.

2. Evaluation / Ralplan

   • Run the real $ralplan gate before editing by default.
   • The gate must produce the desired outcome, constraints, rejected options, risks, acceptance criteria, verification commands, and stop condition.
   • Use a compact inline ralplan only for truly tiny, reversible changes where a full gate would add ceremony without improving safety.
   • If architecture, security, migrations, public behavior, workflow contracts, release metadata, or ambiguous scope are involved, mini-ralplan is not enough.

3. Implementation Lane

   • Use $ultragoal after ralplan when the work has sequential stories, durable checkpoints, or finish-until-done pressure.
   • Use $ultrawork after ralplan when independent implementation, test, docs, or review lanes can run in parallel.
   • Execute directly only for tiny single-file fixes, and state why the ultragoal/ultrawork lane is unnecessary while preserving this skill's verification, review, PR, CI, and merge gates.
   • Keep commits reviewable. Prefer multiple small signed commits over one noisy commit.

4. Verification

   • Run targeted tests first, then broader gates appropriate to the repo.
   • For Python repos, typical gates are unit tests, compileall, generated-doc checks, and git diff --check.
   • If a check fails, fix root cause and rerun the failing check before continuing.
   • Record any validation gap explicitly.

5. PR

   • Create a branch with the default codex/ prefix unless the repo says otherwise.
   • Commit with DCO/signoff when required.
   • Push and open one PR for the cycle automatically.
   • PR body must include summary, verification, review expectations, and any known risks.
   • Keep later review/CI fixes for this same goal in the same PR as additional focused commits.

Stop Conditions

Stop with a concise report when one of these is true:

• PR is merged, remote/default main and local main agree, the user's local runnable surface is synced when applicable, and the worktree is clean.
• PR is merge-ready and awaiting HITL merge approval.
• PR is merge-ready and the user declined or deferred merge approval.
• A blocker requires user authority, credentials, destructive action, production access, or a materially branching decision.
• The same blocking condition repeats after reasonable fix attempts.

Final Report

Include:

• Goal chosen and why.
• PR URL and merge commit, if merged.
• HITL merge approval status.
• Remote/default branch sync result.
• Local runnable sync result, when applicable.
• Changed files or high-level change summary.
• Review result.
• CI/DCO status.
• Local verification commands.
• Remaining risks or next suggested codework goal.