codex-commit-agent

# Codex Commit Agent ## Overview Remove disposable task outputs, 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. 2. Remove disposable intermediate outputs before uploading or staging. - A commit request authorizes this cleanup without asking again. Delete task-generated verification screenshots, comparison images, preview renders, temporary logs/reports, and other unnecessary intermediate outputs that can be regenerated from retained inputs. - Inspect relevant untracked, staged, and git-ignored outputs as well as tracked changes. Confirm their purpose from task context and references; do not delete files solely because of their name, extension, or regenerability. - Preserve source assets, required game/runtime/build inputs, test fixtures and baselines, documentation images, requested deliverables, and anything the user asked to retain. Leave unrelated or uncertain files untouched. - Delete only identified disposable paths; do not use broad `git clean` or directory-wide deletion. Remove already-staged disposable additions from the index as well. For tracked or HF-managed disposable files, review and include their intentional deletions in the commit or asset update. - Refresh the changed-file and asset sets after cleanup. If nothing remains to commit, report that cleanup is complete and there is nothing to commit. 3. 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. 4. 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. 5. 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. 6. Review commit contents. - Repeat the disposable-output cleanup for files generated by validation. Confirm no temporary verification or comparison outputs remain in the staging or asset-upload scope. - 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). 7. 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.