Codex Commit Agent

Codex Commit Agent

Overview

Publish changed binary assets, validate changed areas, and commit the intended files with the updated asset lock. Treat an explicit user request to commit as authorization for git commit; do not ask again solely to approve an assistant-drafted message. A statement that work is complete is not authorization unless it also asks for a commit. Per the repository owner's instruction, a commit request also authorizes the Hugging Face upload needed for that commit's assets. Do not ask for separate upload approval within that scope.

Workflow

1. Inspect current changes.

• Run git status --short.
• Build the changed-file set from staged, unstaged, and untracked files.
• Also inspect relevant git-ignored binary assets and source files against the paths and SHA-256 hashes in assets.lock; Git status alone cannot detect their changes.
• If neither Git changes nor asset changes exist, stop and report that there is nothing to commit.

2. Upload changed assets before committing.

• When the task adds, modifies, moves, or removes HF-managed assets, complete their upload and update assets.lock before git commit. Include source assets under assets/, excluding .blend1 backups, as well as game binaries under client/public/.
• Read tools/push-assets.sh and review the upload scope. It replaces remote client/** and assets/** trees; a partial local checkout must not delete unrelated remote assets. A locally missing file is not an intentional deletion.
• Use bash tools/push-assets.sh only with a complete, reviewed local asset tree. Otherwise upload only the intended changes, preserve unrelated remote files and lock entries, and regenerate the affected lock entries.
• Pin the exact successfully uploaded HF revision and record each changed file's SHA-256 hash in assets.lock. Verify the files at that revision match the intended contents; do not pin a revision where the assets are absent.
• Stage assets.lock with the code, data, and documentation referencing those assets. Keep git-ignored binaries on HF; do not force-add them to Git.
• If upload, authentication, or remote verification fails, stop before committing and report the failure. Do not leave required assets local-only and call the commit complete.
• Skip upload when there are no HF-managed asset changes.

3. Detect which project areas need checks.

• If any file is under client/, run client checks in client/.
• If files are under tools/<tool-name>/, run checks in each changed tools/<tool-name>/.
• If changes touch any Rust workspace member (server/, shared/, terrain/, agent-client/, tools/terrain-gen/), data-src/, .cargo/, Rust source files, Cargo manifests/lockfiles, or Rust toolchain configuration, run Rust checks from the repository root.

4. Run quality checks.

• Preferred path: run ./.codex/skills/codex-commit-agent/scripts/validate.sh.
• Equivalent manual checks:
  • client/ and each changed tools/<tool-name>/: npm run format, npm run lint, npm run check
  • Rust workspace: cargo fmt --all, cargo check --workspace --locked, cargo clippy --workspace --all-targets --locked -- -D warnings
• Clippy is required for Rust-related changes, including test targets. Use the CI command above; do not substitute cargo check or relax warning enforcement.
• If a check fails, stop and report the failing command and actionable errors.

5. Review commit contents.

• Run git status --short again.
• Review git diff --staged (or git diff if nothing is staged yet).
• Stage intended files with git add ... (avoid staging unrelated changes).

6. Draft and commit.

• Draft a concise English commit message in imperative present tense.
• Keep the title under 72 characters.
• Use a user-provided message when one was supplied; otherwise choose the message from the staged diff.
• Once required asset publication and checks pass and the staged files match the requested scope, run git commit -m "<message>" immediately.
• If commit fails, report the exact failure and next action.
• Push Git commits only when the user also requested a push, publish, or remote workflow. Required HF asset uploads happen before the commit as described above.

Commit Message Rules

• Use English only.
• Start with a verb: Add, Fix, Update, Refactor, Remove, Improve.
• Describe what changed clearly and specifically.
• Keep it scoped to staged files.

Failure Handling

• Never commit when required asset uploads, remote verification, or quality checks fail.
• Ask before committing only when the staged scope is ambiguous, includes unrelated changes, or the user explicitly requested message review.
• If formatting updates files, include those changes in the reviewed/staged set before commit.