codework

# 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. 6. **Code Review** - Run the real `$code-review` against the PR or branch diff before merge. - In an attached OMX CLI/tmux runtime, use the repo's OMX code-review surface. In Codex App or another non-tmux surface, load and follow the `$code-review` skill directly. - If independent review lanes are unavailable, report that review is unavailable and do not call the PR merge-ready unless the user explicitly waives review. - Fix actionable review findings, push updates, rerun verification, and rerun review when the diff materially changes. 7. **CI / DCO / Merge** - Wait for required checks, including DCO. - If checks fail, inspect logs, fix, push, and wait again. - When local verification passed, review is clear or waived, required checks pass, and the branch is mergeable, ask a final HITL merge question before merging. - The HITL question must summarize the PR URL, review result, CI/DCO result, local verification, merge strategy, and local sync plan, then ask whether to merge now. - Do not merge until the user gives an affirmative response to that final HITL question. If the user declines, defers, or does not answer, stop at the merge-ready PR. - Prefer merge commits when preserving commit structure matters; use squash only if repo policy or user request says so. - After merge, push or fetch the merged `main` as needed so local `main` and the default remote agree. - Sync the user's local runnable surface when the repo ships a CLI, plugin, app, or generated tool the user runs from this machine. Use the repo's established local install/update command; for Loop, run `npm install -g .` from the repo root. - Confirm the synced local command or app starts and reports the expected version/help/status, then confirm a clean worktree. ## 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.