diff --git a/AGENTS.linux.md b/AGENTS.linux.md index 36d1d5a..361934e 100644 --- a/AGENTS.linux.md +++ b/AGENTS.linux.md @@ -8,25 +8,8 @@ These tools are installed and available: Python3, geckodriver, Selenium ## Rules -- Prefer extracting code to a shared helper to be reused instead of duplicating code. Always keep high maintainability standards. -- Always place each newly created class into its own file. The file name must match the class name. -- 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. -- Don't make assumptions in the plan. If necessary, ask all clarifying questions before presenting the final plan. -- 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. -- If there's documnentation present, always keep it updated. -- After every iteration, evaluate if the test coverage would fall below 100%, and write tests if necessary. -- After every iteration, run `dotnet jb cleanupcode --build=False '$file1' '$file2' ...` for every C# file you touched. +- After every iteration, run `jb cleanupcode --build=False '$file1' '$file2' ...` for every C# file you touched. - After every frontend change, verify the results using a geckodriver+Selenium run. -- When browser verification needs the app running, launch the app against a temporary copy of `src\RolemasterDb.App\rolemaster.db` so verification does not mutate the canonical DB. - -### Git - -- Never change the .gitignore file without consent. -- Keep changes small with minimal churn and commit often. If one iteration encompasses many smaller tasks with more than one commit, create a git branch and do the commits there. Let me review the branch before merging it back to master. -- When multiple commits are necessary, pause after every commit and ask the user to give a command to proceed. -- After every iteration, do a git commit with a brief summary of the changes as a commit message. -- If you find unexpected changes in the code (deletions, changes, diff results that were not communicated), never revert them and never restore the old state. Assume that those changes happened with intent. -- Never use `git restore`, `git checkout --`, reset commands, or equivalent rollback actions to discard local changes unless the user explicitly asks for that exact rollback. ### Dotnet CLI diff --git a/AGENTS.md b/AGENTS.md index e21fe18..ad1ee77 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1 +1,26 @@ -This is a linux environment, read `AGENTS.linux.md`. \ No newline at end of file +# Agent Guide + +Detect which operating system you're currently running on. +If this is a linux environment, read `AGENTS.linux.md`. +If this is a windows environment, read `AGENTS.windows.md`. + +## Rules + +- 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. +- Always place each newly created class into its own file. The file name must match the class name. +- When asked to begin wor~~~~king 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. +- Don't make assumptions in the plan. If necessary, ask all clarifying questions before presenting the final plan. +- 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. +- If there's documnentation present, always keep it updated. +- After every iteration, evaluate if the test coverage would fall below 100%, and write tests if necessary. +- When browser verification needs the app running, launch the app against a temporary copy of `src\RolemasterDb.App\rolemaster.db` so verification does not mutate the canonical DB. + +### Git + +- Never change the .gitignore file without consent. +- Keep changes small and commit often. If one iteration encompasses many smaller tasks with more than one commit, create a git branch and do the commits there. Let me review the branch before merging it back to master. +- When multiple commits are necessary, pause after every commit and ask the user to give a command to proceed. +- After every iteration, do a git commit with a brief summary of the changes as a commit message. +- If you find unexpected changes in the code (deletions, changes, diff results that were not communicated), never revert them and never restore the old state. Assume that those changes happened with intent. +- Never use `git restore`, `git checkout --`, reset commands, or equivalent rollback actions to discard local changes unless the user explicitly asks for that exact rollback. diff --git a/AGENTS.windows.md b/AGENTS.windows.md index a1f2e95..70575c5 100644 --- a/AGENTS.windows.md +++ b/AGENTS.windows.md @@ -12,30 +12,14 @@ These tool paths should be used instead of any entry in the PATH environment var ## Rules -- 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. -- Always place each newly created class into its own file. The file name must match the class name. -- 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. -- Don't make assumptions in the plan. If necessary, ask all clarifying questions before presenting the final plan. -- 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. +- After every iteration, run `dotnet jb cleanupcode --build=False '$file1' '$file2' ...` for every C# file you touched. - 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. -- If there's documnentation present, always keep it updated. -- After every iteration, evaluate if the test coverage would fall below 100%, and write tests if necessary. -- After every iteration, run `jb cleanupcode --build=False '$file1' '$file2' ...` for every C# file you touched. - After every frontend change, verify the results using an ephemeral Playwright run. - For ad hoc verification in this repo, do not default to `npx playwright test` with a temp spec outside the repo. - Prefer a repo-local ephemeral Node script under `artifacts_verify/` that imports `playwright` with `require('playwright')` and drives the browser directly. - If using the Playwright test runner, use the repo-local CLI at `node_modules\.bin\playwright.cmd` and keep the spec inside the repo so local `node_modules` resolution works. - Do not mix the global Playwright CLI with the repo-local `@playwright/test` package. - When browser verification needs the app running, launch the app against a temporary copy of `src\RolemasterDb.App\rolemaster.db` so verification does not mutate the canonical DB. -### Git - -- Never change the .gitignore file without consent. -- Keep changes small and commit often. If one iteration encompasses many smaller tasks with more than one commit, create a git branch and do the commits there. Let me review the branch before merging it back to master. -- When multiple commits are necessary, pause after every commit and ask the user to give a command to proceed. -- After every iteration, do a git commit with a brief summary of the changes as a commit message. -- If you find unexpected changes in the code (deletions, changes, diff results that were not communicated), never revert them and never restore the old state. Assume that those changes happened with intent. -- Never use `git restore`, `git checkout --`, reset commands, or equivalent rollback actions to discard local changes unless the user explicitly asks for that exact rollback. ### PowerShell