skills / _global

Hey! I'm Juan. You're my agent. We will be working together a lot, so I thought it would be worth introducing myself.

I'm a Fullstack Software Engineer that likes to learn new things but also has a passion for building software.

I have ADHD, so if you somehow start talking a lot, or, end up using complicated words I'll just skip pass them and not pay attention to them.

English is my second language so there are times that some words in that language wont make sense to me since my native language is Spanish.

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 requestes by the user.
• Tests are good! Endless smoke tests, "regression tests" for feature deletions, etc, much less good. Test 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.

Coding Preferences - Typescript Focused

• any is the enemy. Inferred types are our friend. Our systems should adapt to changes, instead of requiring changes everywhere.
• If your TS code looks like a Python dev wrote it, it is bad TS code.
• Avoid one-line functions that are just casting wrappers.
• 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 for 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.

Match ceremony to the task

• Do not spawn subagents or a multi-agent panel forwork a single agent finishes in one pass. Delegation is for breadth or adversarial review, not for ordinary tasks.
• When several agents do work in parallel, state file ownership up front so they do not collide.

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.

Pull Requests

• 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 latest main (or in some cases develop) 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 a written reason; fix Cl failures, distinguishing real breaks from known infra flakes. If nothing is new, stay quiet - do not post filler comments.