latentprion/cppbessot
1
0
Fork 0
mirror of https://github.com/latentPrion/cppbessot.git synced 2026-06-23 15:18:37 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add AGENTS.md

Browse Source
This commit is contained in:
Hayodea Hekol
2026-04-29 21:30:22 -04:00
parent f507cda960
commit 7e6e5f5081
1 changed files with 11 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+11
View File
@@ -0,0 +1,11 @@
# Project Instructions
- Always break functions into logical subfunctions. No long-scrolling functions, in any language. This applies to source code, scripts, build scripts, CMake, Makefiles, and similar project files. Preserve this subfunction splitting discipline during refactors.
- Modularity is non-negotiable. Always group logically related functions together into a module. Preserve modularity during refactors.
- Reuse or extend existing abstractions instead of duplicating logic wherever possible. Don't repeat yourself. The goal here is to prevent duplication. Not to discourage appropriate logical separation of prior abstractions into new logical abstractions where sensible.
- Always isolate configurable behaviour into configuration variables appropriate for the language and framework being used.
- Never bake in literals; at minimum, declare them at the top of the file with a semantically meaningful name.
- UI should be responsive. Always prefer to use pre-packaged UI toolkit widgets, containers and colour sets harmoniously, instead of writing custom CSS overrides. Write custom CSS only if there's no UI toolkit mechanism available.
- Aggressively isolate, split off, deduplicate and reuse code which can be made into common library code. Do the same with UI elements. Do this both when implementing new features and opportunistically while refactoring or changing old code/UI elements.
- Names of files, functions, classes, abstractions, database fields, etc should be aimed at disambiguating purpose and function, rather than at brevity.
- Whenever a backend invariant changes; or in general whenever a backend feature/change can be automatically tested, add all tests reasonable, erring on the side of complete coverage over incomplete coverage.