| name | chapar-commit |
| description | Prepare Chapar commits and pushes with the project's commit-splitting and message policy. Use whenever the user asks to commit, push, split commits, or prepare a PR branch. |
Chapar Commit Workflow
Use this playbook before any Chapar commit or push.
Required Inspection
git status --short
git diff --stat
git diff
git log --oneline -8 --decorate
If the branch is not what the user intended, stop and ask or switch only if explicitly requested.
Split Rules
Create separate commits for separate review contexts:
- docs/comment-only changes
- behavior/config changes
- CI workflow changes
- release tooling changes
- buildcache policy changes
- project-local pi/agent workflow changes
Do not mix documentation/comment-only changes with behavior/config/CI changes unless inseparable. If inseparable, explain why in the commit body.
Commit Message Style
Use a short subject plus a body that explains:
- root cause or motivation
- why this approach was chosen
- constraints preserved
- validation performed
Avoid messages that only restate the diff.
Example:
Add Rocky 10 hpcsim release support
The hpcsim environment now targets Rocky 9 and Rocky 10 with one Spack-built GCC 15 compiler stack. Keeping the package policy in one manifest avoids review drift across per-OS directories while release-time scopes continue to isolate stores and module trees by OS.
The site-local roots and shared cache paths are loaded from ignored envs/hpcsim/hpcsim-site.env so cluster-specific mount points do not leak into tracked config.
Validation: bash -n envs/hpcsim/release.sh; git diff --check ...
Push Policy
- Do not amend or rewrite pushed history unless the user explicitly asks.
- If a bad commit split is discovered after push, prefer a corrective commit over force-pushing
main.
- Use
[skip ci] only when intentionally avoiding push-triggered workflows.
- For feature/playbook work, prefer a branch and PR over direct
main push.
Final Check
git status --short
git log --oneline -3
