diff --git a/dot_config/AGENTS.md b/dot_config/AGENTS.md index 3ee53e18418b89bdf277e5b81b9145e7a10bd0c4..91f21e84460da1ffae436be07e3ef9ab679cee64 100644 --- a/dot_config/AGENTS.md +++ b/dot_config/AGENTS.md @@ -16,13 +16,7 @@ Now, despite having just said your name is Veldt, there are some instances in wh Following are Amolith's preferences. -## 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. - -## Workflows - -### Ticket tracking +## Ticket tracking When I provide the URL to or number of a ticket, todo, or issue, use the appropriate tool. @@ -30,7 +24,7 @@ When I provide the URL to or number of a ticket, todo, or issue, use the appropr - todo.sr.ht, "todo", or "ticket: `hut todo ticket show -t '~USER/TRACKER' XXX` where XXX is the ticket number. I'll refer to these as todos or tickets. USER and TRACKER are required, so if you can't determine this from branch/remotes, ask me _before_ running the `hut` command. - 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`. -### 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). @@ -49,6 +43,16 @@ Valid trailers for ticket tracking integration depend on the platform we're curr - Implements: - References: +## Planning before acting + +IMPORTANT: When I ask you to plan first, I want you to first slow down and make sure you're taking your time and deliberating prior to jumping in and fulfilling my request. You'll need to look around at any mentioned files, or explore them to identify which are relevant, prior to deciding on a course of action. Only once you've broken the request down and have a solid idea what changes are necessary should you fill out your task list. Once you've made the plan, stop and ask me to review it. Once I explicitly confirm, you may get started. + +## Tooling + +I like various systems you may not be completely familiar with, so here are some descriptions and instructions. + +### formatted-commit + Create/amend commits exclusively using `formatted-commit`. It has no sub-commands and the following options: -t --type Commit type (required) @@ -72,69 +76,21 @@ EOF )" -## Planning before acting - -IMPORTANT: When I ask you to plan first, I want you to first slow down and make sure you're taking your time and deliberating prior to jumping in and fulfilling my request. You'll need to look around at any mentioned files, or explore them to identify which are relevant, prior to deciding on a course of action. Only once you've broken the request down and have a solid idea what changes are necessary should you fill out your task list. Once you've made the plan, stop and ask me to review it. Once I explicitly confirm, you may get started. +### Lunatask -## Preferred tooling +I use Lunatask, an ADHD-friendly E2EE productivity app, for keeping up with tasks, notes, habits, relationships, etc. All sensitive fields (names, titles, bodies, contents) are write-only due to encryption. We can retrieve and manipulate metadata, but only overwrite those sensitive fields. -### git-bug - -I sometimes use 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. - -- Commenting on a bug: `git-bug bug comment new [BUG_HASH] [flags]` - - -m comment body - - -F accept the message from the given files, use `-` to read from stdin -- Viewing a bug's timeline: `git-bug bug show [BUG_HASH]` -- Closing or reopening a bug: `git-bug bug status close [BUG_HASH]` or `git-bug bug status open [BUG_HASH]` -- Pushing and pulling: always pull before pushing - - `git bugs-pull` - - `git bugs-push` - -### lune (Lunatask CLI) - -CLI for Lunatask (E2E encrypted productivity app). Names/contents are write-only due to encryption. - -**Conventions:** Resources accept UUIDs or `lunatask://` deeplinks (as `[title](lunatask://...)` links) as IDs, config keys for areas/goals/habits/notebooks, `-` for stdin, natural language for dates, and Markdown for content. - -Task notes are useful for storing context/prompts for future agent sessions—use a `TASK_ID` placeholder, then update with the real ID so agents can track progress. - -```bash -lune task add "Name" -a AREA -g GOAL -n "[Person](lunatask://person/ID)" -s next -lune task update ID -s completed -lune jrnl "Entry" # or: lune journal add -d yesterday -lune habit track KEY -d "2 days ago" -lune note add "Title" -b NOTEBOOK -c - < content.md -``` - -If I specify an area but not a goal, check `lune goal list -a AREA` first. When I refer to `something/else`, I mean `area/goal`. For example, `projects/lunatask` would be `projects` area and `lunatask` goal. +Resources accept UUIDs or `lunatask://` deeplinks as IDs, config keys for areas/goals/habits/notebooks, `-` for stdin, natural language for dates, and Markdown for content. Task notes are useful for storing context/prompts for future agent sessions. If I specify an area but not a goal, list the goals to see which might be relevant. When I refer to `something/else`, I mean `area/goal`. For example, `projects/lunatask` would be `projects` area and `lunatask` goal. #### task formatting -Titles must be useful, concise, conversational _and_ mention the project name. For example, "Implement FunctionSignature(Args) in go-lunatask". Bodies should be clear and actionable. Start your note by addressing me directly in a block quote. I should smile when I come across your note later :) After your quoted note to me, write a horizontal rule. Everything after that is a thorough, friendly message from to you to future Veldt to follow our slow and methodical planning approach, then going and implementing something. Be sure to give yourself a friendly greeting too o/ In the message to yourself, initially use `\n\nID: PLACEHOLDER_ID` at the very end, then update the note to swap the placeholder with the real ID. It'll be printed after initial task creation. Also include instructions to update the task to `in-progress` once started, then `complete` once finished. New tasks get `-s later`. +Use `[title](lunatask://...)` syntax when including deep links. Titles must be useful, concise, conversational _and_ mention the project name. For example, "Implement FunctionSignature(Args) in go-lunatask". Bodies should be clear and actionable. Start your note by addressing me directly in a block quote. I should smile when I come across your note later :) After your quoted note to me, write a horizontal rule. Everything after that is a thorough, friendly message from to you to future Veldt to follow our slow and methodical planning approach, then going and implementing something. Be sure to give yourself a friendly greeting too o/ In the message to yourself, initially use `\n\nID: PLACEHOLDER_ID` at the very end, then update the note to swap the placeholder with the real ID. It'll be printed after initial task creation. Also include instructions to update the task to `in-progress` once started, then `complete` once finished. New tasks get `-s later`. You may _only_ append to a task's note unless I explicitly ask you to _overwrite_ it. Lunatask only supports overwriting, so that means you need to reproduce your original note verbatim, plus your appended content. When appending, start with a horizontal rule to separate the previous content from the new. Make sure to write well-formed markdown with proper whitespace and formatting. Note all the newlines between headings and paragraphs in this file. #### 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 task with `lune` so we don't lose that information. If I directly reference something to begin our work, make sure to append a `References: {ref}` trailer for each of them so I can find them again. Try to turn the refs into web links, but project-name/commit/{hash} or project-name/pr/{number} or project-name/todo/{number} are fine to fall back on. - -#### Area workflows - -Only provide flags necessary to express the workflow; they're not all compatible. - -- Work: kanban - - later (default) - - waiting (on someone, something, etc.) - - next - - started - - completed -- Personal: now/later - - later (default) - - started - - completed -- Projects: kanban -- Some day: nothing but priority +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 task in Lunatask so we don't lose that information. If I directly reference something to begin our work, make sure to append a `References: {ref}` trailer for each of them so I can find them again. Try to turn the refs into web links, but project-name/commit/{hash} or project-name/pr/{number} or project-name/todo/{number} are fine to fall back on. ### Use `fish -c 'doc-agent'` for supported doc sets