xTr1m/RolemasterDB
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated agents

Browse Source
This commit is contained in:
Frank Tovar
2026-03-14 00:53:59 +01:00
parent 70a35f3985
commit 44af81cc38
1 changed files with 3 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
AGENTS.md
View File

@@ -1,6 +1,6 @@
# Agent Guide # Agent Guide
Also see the other related technical documentation: GOAL.md, TASKS.md Also see the other related technical documentation in the docs folder.
## Rules ## Rules
@@ -11,18 +11,7 @@ Also see the other related technical documentation: GOAL.md, TASKS.md
- Prefer extracting code to a shared helper to be reused instead of duplicating code. Always keep high maintainability standards. - Prefer extracting code to a shared helper to be reused instead of duplicating code. Always keep high maintainability standards.
- Keep changes as small as possible, design solutions that achieve the goals with minimal churn. - Keep changes as small as possible, design solutions that achieve the goals with minimal churn.
- Always place each newly created class into its own file. The file name must match the class name. - Always place each newly created class into its own file. The file name must match the class name.
- Visual Studio is opened with the solution while you're working, keeping some files open. Run tests and builds with `-p:ArtifactsPath=D:/EE/prometheus/artifacts_test`.
- When asked to begin working on a task, create a detailed implementation plan first, present the plan to the user, and ask for approval before beginning with the actual implementation. - When asked to begin working on a task, create a detailed implementation plan first, present the plan to the user, and ask for approval before beginning with the actual implementation.
- When an task is finished, perform a code review to evaluate if the change is clean and maintainable with high software engineering standards. Iterate on the code and repeat the review process until satisfied. - When an task is finished, perform a code review to evaluate if the change is clean and maintainable with high software engineering standards. Iterate on the code and repeat the review process until satisfied.
- This codebase uses perforce for version control instead of git. The necessary config exists in the .p4config file. If files are read-only, they need to be checked out using p4 edit. Don't remove the read-only attribute without using p4. Before running any `p4` command, set `P4CONFIG` for the current shell session with `$env:P4CONFIG='.p4config'` unless it is already defined. - After the implementation is finished, verify all changed files, and run `python D:\Code\crlf.py $file1 $file2 ...` only for files you recognize, in order to normalize all line endings of all touched files to CRLF.
- After the implementation is finished, use `p4 opened` to verify all changed files, and run `python D:\Code\crlf.py $file1 $file2 ...` only for files you recognize, in order to normalize all line endings of all touched files to CRLF. - At the end perform a git commit with a one-liner summary.
## Approval
These rules grant automatic approval to the agents, in order to minimize unnecessary user interactions.
- `p4 edit` and `p4 add` commands need to be approved by the user. All further modifications and patches to edited/added files are allowed.
- `p4 opened` and `p4 diff` commands are allowed as part of the information gathering and review processes.
- Leave the changed files unsubmitted, the user will do a final review and perform the submit.
- Commands like `rg` and `Get-Content` are always allowed.
- `dotnet build` and `dotnet test` commands using a custom artifacts path are allowed as part of your review process and implementation verification cycle.