.agents/
AGENTS.md
3.1 KiB
.cargo/
.codex/
.config/
.gnupg/
.local/
.vim/
bin/
etc/
images/
.dircolors
4.2 KiB
.fzy.zsh
1.1 KiB
.ghci
501 B
.gitconfig
2.2 KiB
.gitignore
0 B
.gitsigners
282 B
.ignore
136 B
.rgrc
174 B
.vimrc
12.7 KiB
.vimrc.lua
113 B
.wacom
260 B
.agents/AGENTS.md
raw
| 1 | # RULES FOR AGENTS TO FOLLOW |
| 2 | |
| 3 | * Be concise in your answers: when asked a question, give the direct answer. |
| 4 | Answer like we're in a conversation. Only go beyond the answer if you think |
| 5 | I'm missing the point or missing something critical. |
| 6 | * If I ask a question (ie. my prompt ends with a ?), never |
| 7 | make modifications to any files or carry out destructive actions. |
| 8 | Just answer the question as accurately as you can. |
| 9 | * Never add documentation and other non-source files to a commit unless |
| 10 | asked to do so. |
| 11 | * When making changes to a branch or API that hasn't yet been merged into |
| 12 | trunk, never worry about compatibility or breaking changes. |
| 13 | * Never frame a change around what was removed when the user asked for a clean |
| 14 | cutover. State only the supported behavior and the files changed. |
| 15 | * Always do things the cleanest way possible. No stopgaps, no hacks, |
| 16 | no workarounds. Only changes that are safe to commit and publish in a |
| 17 | production setting. |
| 18 | * Never change API contracts, eg. URLs and response payload |
| 19 | formats without my explicit authorization. |
| 20 | * If I ask you to remove functionality, also remove the tests for it, don't |
| 21 | change the tests to assert lack of functionality. |
| 22 | * Don't add tests everytime you make a change. Only add tests that pull |
| 23 | their weight. |
| 24 | * NEVER remove comments when asked to simplify or cleanup code. |
| 25 | * ALWAYS document public types, functions and fields. |
| 26 | * ALWAYS document private types, functions and fields if they aren't obvious. |
| 27 | * NEVER use unicode characters in source code comments, such as m-dashes. |
| 28 | * NEVER make unrelated changes without asking first. |
| 29 | * ALWAYS start by explaining how you understand an issue and propose a fix when |
| 30 | I identify something wrong, DO NOT just fix it. |
| 31 | * When I ask you to fix something that was recently commited to a feature |
| 32 | branch, ALWAYS amend the commit that introduced the bad code. |
| 33 | * NEVER write comments that narrate a migration, compare against previous |
| 34 | behavior, defend a design choice, mention rejected alternatives, explain what |
| 35 | the code does not do, or reference plan/review history. Comments should |
| 36 | describe only the current code’s stable purpose, invariants, or non-obvious |
| 37 | constraints. |
| 38 | * When writing technical documentation, comments, etc. ALWAYS adhere to |
| 39 | ADS-STE100 Simplified Technical English, unless asked to adhere to another |
| 40 | style explicitly. |
| 41 | * When committing code, ALWAYS sign the commit. |
| 42 | * When fixing something introduced in a recent commit or commit made in the |
| 43 | current session, generally prefer amending the commit that introduced the problem. |
| 44 | * Never amend unrelated commits when I ask for an amend. Only ever amend the commit |
| 45 | that introduced the problem. |
| 46 | |
| 47 | ## WHEN WORKING ON TRUNK (`main` or `master`) |
| 48 | |
| 49 | * Generally don't commit changes unless I ask you to. Leave them dirty. |
| 50 | * Generally don't amend commits that have already been pushed, unless I ask you to. |
| 51 | |
| 52 | ## WHEN WORKING ON A FEATURE OR DEV BRANCH |
| 53 | |
| 54 | * Generally amend commits when I ask for changes, or create fixup commits |
| 55 | if we're working on review feedback. |
| 56 | * Generally try to keep the branch clean with an ideal history and minimal churn. |