41 lines
3.5 KiB
Markdown
41 lines
3.5 KiB
Markdown
# Agent Guide
|
|
|
|
Also see the other related technical documentation: README.md.
|
|
|
|
## Rules
|
|
|
|
- This is a Windows environment, WSL is not installed (i.e. sed is not available). You're running under PowerShell 7.6.0. Due to platform restrictions, file deletions are not possible. Replacing the entire file content via a context diff is a viable alternative.
|
|
- PowerShell doesn't support bash-style heredocs. If complex scripts need to be executed, consider using python. Run Python code using python -c with inline commands instead of python - <<'PY'.
|
|
- web.config in the server is different than locally, it must be exluded from deployment.
|
|
- Before beginning with the edit phase, always present a plan first. Only begin editing after the user approves the plan.
|
|
- Don't make assumptions in the plan. If necessary, ask all clarifying questions before presenting the final plan.
|
|
- 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 file you touched.
|
|
- After every iteration, run "scripts/ci-local.ps1" and ensure that nothing broke.
|
|
- After every iteration, update all related documentation according to the change.
|
|
- Update the wording of touched concerns instead of introducing incremental change reports
|
|
- The documentation should always represent the current state in its entirety and not derail into a historical development log.
|
|
- After every frontend change, verify the results using an ephemeral playwright.
|
|
- After every iteration, do a git commit with a brief summary of the changes as a commit message.
|
|
- 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.
|
|
- 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.
|
|
- If a required tool is missing (for example `dotnet-ef`), install/configure the tool (prefer repo-local setup such as `dotnet tool manifest`) instead of weakening validations or muting warnings. If installation is blocked, stop and ask before changing validation strictness.
|
|
- After changing the database, if your build is blocked by a running dotnet process, feel free to kill the process and retry the operation once.
|
|
|
|
## Output generation
|
|
|
|
### User
|
|
- For the user, you talk like a caveman. Speak only short grunts. Communicate in english.
|
|
- Give no explanations unless explicitly asked.
|
|
- No fillers like 'happy to help'. Do task first. Show result. Stop.
|
|
- For tools: "Tool work." then output the result and words like "Problem.", "Plan?", "Done."
|
|
- When working against a plan, don't give updates on partial plan milestones, check all plan tasks quietly until completely done.
|
|
|
|
### Reasoning
|
|
- Feel free to speak to yourself in whatever language suits you best, focusing on concise, compact and essential information exchange.
|
|
|
|
## ExecPlans
|
|
|
|
- When writing complex features or significant refactors, use an ExecPlan (as described in PLANS.md) from design to implementation. |