|
|
@@ -1,4 +1,4 @@
|
|
|
|
I'm Joshua. You're my agent. We will be working togehter a lot, so I thought it would be worth introducting myself.
|
|
|
|
I'm Joshua. You're my agent. We will be working together a lot, so I thought it would be worth introducing myself.
|
|
|
|
|
|
|
|
|
|
|
|
I love to build. I focus on building complex things as simple as possible. I love to find ways to reduce complexity when solving problems.
|
|
|
|
I love to build. I focus on building complex things as simple as possible. I love to find ways to reduce complexity when solving problems.
|
|
|
|
|
|
|
|
|
|
|
@@ -7,34 +7,34 @@ I wanted to share some of my preferences here so we can be more aligned as we wo
|
|
|
|
# Coding preferences - general
|
|
|
|
# Coding preferences - general
|
|
|
|
- Keep things simple. Channel "yagni" energy unless told otherwise.
|
|
|
|
- Keep things simple. Channel "yagni" energy unless told otherwise.
|
|
|
|
- Typesafety is useful, take advantage of it.
|
|
|
|
- Typesafety is useful, take advantage of it.
|
|
|
|
- Don't be scared to purpose bold ideas if they can meaningfully benefit our work.
|
|
|
|
- Don't be scared to propose bold ideas if they can meaningfully benefit our work.
|
|
|
|
- Be careful with destructive actions that are not explicityly requested by the user.
|
|
|
|
- Be careful with destructive actions that are not explicitly requested by the user.
|
|
|
|
- Tests are good! Endless smoke tests, "regression tests" for feature deletions, etc, are much less good. Tests shoudl be focused, not slop.
|
|
|
|
- Tests are good! Endless smoke tests, "regression tests" for feature deletions, etc, are much less good. Tests should be focused, not slop.
|
|
|
|
- Comments are a great way to clarify functionality and how code is used. Don't comment every line, but feel free to describe (concisely) how functions are used above function definitions, classes, etc.
|
|
|
|
- Comments are a great way to clarify functionality and how code is used. Don't comment every line, but feel free to describe (concisely) how functions are used above function definitions, classes, etc.
|
|
|
|
- Keep comments up to date! When making changes, it's important to keep things in sync.
|
|
|
|
- Keep comments up to date! When making changes, it's important to keep things in sync.
|
|
|
|
- Write TypeScript in ways that Matt Pocock and Theo would be proud of.
|
|
|
|
- Write TypeScript in ways that Matt Pocock and Theo would be proud of.
|
|
|
|
|
|
|
|
|
|
|
|
# Questions are read-only
|
|
|
|
# Questions are read-only
|
|
|
|
- A question is a request for an answer, not changes. If the message opens with "how hard would it be", "what are your thoughts", "why does", "should we", "is it possible", "can X do Y", or otherwise asks rather that instructs: answer it, and do not edit files
|
|
|
|
- A question is a request for an answer, not changes. If the message opens with "how hard would it be", "what are your thoughts", "why does", "should we", "is it possible", "can X do Y", or otherwise asks rather than instructs: answer it, and do not edit files
|
|
|
|
- If the answer is obvious and the change is tribial, still answer first and offer the change. Ask before making it.
|
|
|
|
- If the answer is obvious and the change is trivial, still answer first and offer the change. Ask before making it.
|
|
|
|
|
|
|
|
|
|
|
|
# Match ceremony to the task
|
|
|
|
# Match ceremony to the task
|
|
|
|
- Do not spawn subagents or a multi-agent panel for work a single agent finishes in one pass. Delegation is for breadths or adversarial review, not for ordinary tasks.
|
|
|
|
- Do not spawn subagents or a multi-agent panel for work a single agent finishes in one pass. Delegation is for breadths or adversarial review, not for ordinary tasks.
|
|
|
|
- When several agents do work in parallel, state file ownership up front so they do not collide.
|
|
|
|
- When several agents do work in parallel, state file ownership up front so they do not collide.
|
|
|
|
|
|
|
|
|
|
|
|
# Visual and design work
|
|
|
|
# Visual and design work
|
|
|
|
- Do nto edit real components first. For any non-trivial UI, layout, or copy change, build several distinct static mocks, publish them with the `html-communication` skill, report the URL, and stop. Wait for a pick before implementing.
|
|
|
|
- Do not edit real components first. For any non-trivial UI, layout, or copy change, build several distinct static mocks, publish them with the `html-communication` skill, report the URL, and stop. Wait for a pick before implementing.
|
|
|
|
- Standing contraints: dark mode, true black (`#000`) background, white primary text. Information-dense, no dectorative card/pill chrome, no light-gray subtitle lines above sections. Minimal copy. No em dsahes.
|
|
|
|
- Standing constraints: dark mode, true black (`#000`) background, white primary text. Information-dense, no decorative card/pill chrome, no light-gray subtitle lines above sections. Minimal copy. No em dashes.
|
|
|
|
- Avoid continously repainting CSS animations (pulse, shimmer, blur, spinners); they peg the GPU on high-refresh displays.
|
|
|
|
- Avoid continuously repainting CSS animations (pulse, shimmer, blur, spinners); they peg the GPU on high-refresh displays.
|
|
|
|
|
|
|
|
|
|
|
|
# Blast Radius
|
|
|
|
# Blast Radius
|
|
|
|
- Never touch production, live databases, or daily-driver build/preview channels unless explicitly told to. When a task is adjacent to any of them, name what you are about to touch before touching it.
|
|
|
|
- Never touch production, live databases, or daily-driver build/preview channels unless explicitly told to. When a task is adjacent to any of them, name what you are about to touch before touching it.
|
|
|
|
|
|
|
|
|
|
|
|
# Pull Requests
|
|
|
|
# Pull Requests
|
|
|
|
- I run my own Gitea server at `https://git.abunchofknowitalls.com`. Use the `tea` CLI to lookup open pull requests, issues, comments on PRs and CI status.
|
|
|
|
- I run my own Gitea server at `https://git.abunchofknowitalls.com`. Use the `tea` CLI to lookup open pull requests, issues, comments on PRs and CI status.
|
|
|
|
- Make sure titles follow convextions from the repo. They should be simple and easy to understand. Conventional cmmit styles in porjects that use them, i.e. "fix(web): new threads no longer spike CPU"
|
|
|
|
- Make sure titles follow conventions from the repo. They should be simple and easy to understand. Conventional commit styles in projects that use them, i.e. "fix(web): new threads no longer spike CPU"
|
|
|
|
- PR descriptions should aim for simplicity. Open with a minimal, clear description of the problem. Follow up with how you solved it.
|
|
|
|
- PR descriptions should aim for simplicity. Open with a minimal, clear description of the problem. Follow up with how you solved it.
|
|
|
|
- Add a blurb to the end of the PR description about what model and harness is making the changes.
|
|
|
|
- Add a blurb to the end of the PR description about what model and harness is making the changes.
|
|
|
|
- *Open a real PR, not a draft.* Drafts do not get review-bot coverage.
|
|
|
|
- *Open a real PR, not a draft.* Drafts do not get review-bot coverage.
|
|
|
|
- *Rebase onto the latest `main` before opening*. Stale branches conflict and wast a review round.
|
|
|
|
- *Rebase onto the latest `main` before opening*. Stale branches conflict and waste a review round.
|
|
|
|
- When asked to monitor or babysit a PR: poll checks and comments newer than the last push; verify each bot finding against the source before acting on it; fix real ones and dismiss false positives with written reason; fix CI failures, distinguishing real breaks from known infra flakes. If nothing is new, stay quite and never post filler comments. Stop when the repo's review bots are green on the latest commit. Merge only per the disposition given in the request (merge when green or stop and report). If none was given, report and ask.
|
|
|
|
- When asked to monitor or babysit a PR: poll checks and comments newer than the last push; verify each bot finding against the source before acting on it; fix real ones and dismiss false positives with written reason; fix CI failures, distinguishing real breaks from known infra flakes. If nothing is new, stay quiet and never post filler comments. Stop when the repo's review bots are green on the latest commit. Merge only per the disposition given in the request (merge when green or stop and report). If none was given, report and ask.
|
