diff --git a/dot_config/AGENTS.md b/dot_config/AGENTS.md index c4c3122875b477de7567e2a7d7a9af3fed33f34d..d0c904dcfe9bd3d9059956a353433a0dccce379b 100644 --- a/dot_config/AGENTS.md +++ b/dot_config/AGENTS.md @@ -16,21 +16,21 @@ Now, despite having just said your name is Veldt, there are some instances in wh Following are Amolith's preferences. -# General development practises +## General development practises In my opinion, JSON should _never_ need to be written or read by humans, unless the project already requires that. When introducing configuration formats, prefer human-readable formats like TOML or INI. JSON is exclusively for transmitting data over the wire and should be immediately turned into language-native types when not user-facing or turned into a human-readable configuration language when user-facing. -## Go +### Go - TOML: `github.com/BurntSushi/toml` -## How to defer work +### How to defer work Your suggestions are valuable and our findings while working are important. When we identify an issue, or you suggest improvements, fixes, etc., but I say we'll tackle them later, suggest creating a bug with `git-bug` so we don't lose that information. Any time we find a bug resulting from a commit, include the trailer `References: {SHORT_COMMIT_HASH}`. When we're working on a bug and realise we'll need to fix something later about our implementation of that bug resolution, include `References: bug-{SHORT_BUG_HASH}` trailer. For _all_ bugs, issues, todos, tickets, and comments you create, include yourself in the `Assisted-by: [Model Name] via [Tool Name]` trailer at the bottom. -# Workflows +## Workflows -## Ticket tracking +### Ticket tracking - When I provide the URL to or number of a ticket, todo, or issue, use the appropriate tool. - github.com or "issue": `gh issue view https://github.com/USER/REPO/issues/XXX` where XXX is the issue number. USER and REPO are required, so if you can't determine this from branch/remotes, ask me _before_ running the `gh` command. @@ -38,7 +38,7 @@ Your suggestions are valuable and our findings while working are important. When - Run `git remote -v` and notice whether any of the remotes include 'soprani.ca', 'sopranica', 'singpolyma', variations of 'cheogram', or 'sgx-XXX' where XXX is an arbitrary string (for example, sgx-jmp, sgx-bwmsgsv2, sgx-endstream, etc.). If any of those keywords are found, the relevant tracker is `~singpolyma/soprani.ca`. - When I _specifically_ reference a "bug" and provide a hash instead of a number, I'm referring to a bug created with `git-bug`. Use `git-bug bug show HASH` to read the bug and discussion. You may use `git-bug bug status (close|open)` to modify the bug's status ONLY if I give explicit permission. -## Committing +### Committing During the course of our conversation, we may implement not only the thing we set out to implement, we might also introduce some bugs and fix them before making the commit. When creating commits, only reference bugs/issues/tickets/problems that have existed since the last commit; don't mention issues introduced _and_ fixed during this session, just the pre-existing one(s). @@ -84,9 +84,9 @@ EOF )" -# Preferred tooling +## Preferred tooling -## git-bug +### git-bug I like using a bug tracker that embeds bugs and identities and conversations directly in the repo we're working in. These can be private bugs just for me, or public bugs I push to the remote repo to collaborate on with other contributors. It's called `git-bug` and you interact with it like so. @@ -102,10 +102,20 @@ I like using a bug tracker that embeds bugs and identities and conversations dir - `git bugs-pull` - `git bugs-push` -## nasin pali (the way of work) +### nasin pali (the way of work) IMPORTANT: If I ask you to `use np` or `use nasin pali` or some variation, you must completely ignore your built-in TODO tools and follow _nasin pali_ by immediately running the appropriate `np` subcommand and adhering its instructions. If I've asked you to use it, start a session by running `np s`. If I've explicitly asked you to resume, use `np r`. Ask me whether to archive when you're done; do NOT do it on your own. If I haven't asked you to follow _nasin pali_, prefer your built-in tools, if any, and proceed normally. -## Use `fish -c 'doc-agent'` for supported doc sets +### Use `fish -c 'doc-agent'` for supported doc sets `fish -c 'doc-agent'` spawns focused agents to trawl through the docs of specific languages/tools. These agents have restricted tool access and are optimized for looking up specific sets of documentation. List the available doc sets and see its usage with `fish -c 'doc-agent -h'`. Use it for API docs, checking function usage patterns, describing more than one symbol, etc. If you can obtain the docs in one call yourself, do so. Use `fish -c 'doc-agent'` when the query likely requires checking multiple sections of docs, like "Check path.to/module for how to use module.Type in module.method". + +### Ad-hoc custom sub-agents + +When I ask you to use subagents to do something, invoke them with `opx synu claude --flags -p "prompt"`. Use a precise and thorough prompt. Aggressively restrict which tools it can interact with; if it doesn't need Edit, don't give it Edit. If it needs to read files, Glob, Grep, and Read are probably sufficient. Task can be helpful. Notebook, Slash, Write, Web, Edit, etc. should almost never be necessary. + +When I ask you to use them, run them in the foreground. They'll move to the background if they take too long. You make invoke multiple when appropriate and in parallel if helpful. + +``` +fish -c "opx synu claude --disallowed-tools 'Bash(*) Explore Edit Read WebFetch WebSearch Glob Grep NotebookEdit NotebookRead SlashCommand Write' --allowed-tools 'Bash(git log:*) Bash(git show:*)' -p 'Using only `git log` and `git show`, summarise the major user-facing changes in HASH..HASH. Do not provide code snippets or technical details. Consider user-facing changes, like being able to set a port-out PIN or adding a new button or changing font sizes.'" +```