Files

T

42210f0d1f copycat

2026-08-19 18:34:08 -04:00

I'm Joshua. You're my agent. We will be working togehter a lot, so I thought it would be worth introducting 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 purpose bold ideas if they can meaningfully benefit our work.
Be careful with destructive actions that are not explicityly 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.
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 that 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.

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 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.
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.
Avoid continously 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 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"
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 wast 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.