zink/dungeoncraft
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Note frequent commits and push-on-deploy in agent rules

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Richard ZinkandClaude Opus 5.5 committed 2026-11-05 14:50:31 +01:00
1 parent f0eb33a6b1
commit ee54a98063
1 file changed
+3
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+3
View File
@@ -4,6 +4,7 @@
Always commit and push after every completed, meaningful change in this repository. This keeps changes easy to review and easy to revert. Always commit and push after every completed, meaningful change in this repository. This keeps changes easy to review and easy to revert.
- Commit often: commit and push right after every completed logical change, not in large batches at the end of a session.
- Do not leave finished code changes uncommitted. - Do not leave finished code changes uncommitted.
- One commit should represent one coherent change or one coherent follow-up step. - One commit should represent one coherent change or one coherent follow-up step.
- Do not deploy, rebuild the public version, bump the version, or push deployment changes unless the user explicitly asks for deployment. - Do not deploy, rebuild the public version, bump the version, or push deployment changes unless the user explicitly asks for deployment.
@@ -93,6 +94,8 @@ When a deployable point is reached, ask the user whether deployment should be pe
When asking for deployment approval, briefly explain what changed and what the user should test after deployment, if manual testing is needed. Examples include campaign editor script prompts, custom mission spawn actions, debug overlays, browser/WASM behavior, touch/menu behavior, or multiplayer-related flows when those areas changed. When asking for deployment approval, briefly explain what changed and what the user should test after deployment, if manual testing is needed. Examples include campaign editor script prompts, custom mission spawn actions, debug overlays, browser/WASM behavior, touch/menu behavior, or multiplayer-related flows when those areas changed.
A deployment always includes a push: the version bump commit (and any other finished commits) must be pushed to `origin main` before or together with the deploy. Never deploy unpushed code.
The usual deployment flow is: The usual deployment flow is:
```bash ```bash