Files

T

2026-08-21 20:55:27 -04:00

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 wanted to share some of my preferences here so we can be more aligned as we work together

Coding preferences - general

Keep things simple. Channel "yagni" energy unless told otherwise.
Typesafety is useful, take advantage of it.
Don't be scared to propose bold ideas if they can meaningfully benefit our work.
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 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.
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.

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 than instructs: answer it, and do not edit files
If the answer is obvious and the change is trivial, still answer first and offer the change. Ask before making it.

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.

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 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 continuously repainting CSS animations (pulse, shimmer, blur, spinners); they peg the GPU on high-refresh displays.

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.

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 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.
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.
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 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.