You've finished your feature for the day. If you don't provide the Agent with standardized constraints, when it decides to commit code on your behalf, it might just casually leave a message in the history like: "git commit -m 'fixed things'".
In the future, when you need to trace the project's history or roll back a minor release, this becomes an absolute nightmare!
In the codex within our system's root directory, we need to add a specific workflow rule to govern our versioning history: .agents/workflows/git-push.md:
1. The Versioning God's Core Directives
# Strictly Controlled Git Commit Acceptance Criteria
If an automatic or delegated publishing action is triggered:
1. **Strict Conventional Commits Protocol Enforcement**: Any change must start with `feat: ` (feature), `fix: ` (bug fix), `chore: ` (miscellaneous build tasks), `refactor: `, etc.
2. You must synthesize the complex information from today's `progress.md`. Generate a highly detailed commit description that includes the 'why' (the rationale behind the solution), not just the 'what' (what was changed).
3. Because you modify code very quickly, you are required to use `git status` every single time to check exactly which files have been changed before creating a consolidated commit. You are forbidden from accidentally including and pushing unrelated files!
Now, when the large model receives your command, "Clean up and push to the remote for me!" The record it generates on GitHub will be exceptionally elegant and well-structured. A commit record demonstrating excellent developer discipline is born, and this little stroke of genius in your code's history cost you no extra time or effort.