Keep the personal half of the desktop in one place, and ask before installing it

Agent instructions, skills, SSH host aliases and expansion triggers are worth
having identical on every machine one person owns, and belong in none of the
shared configuration. They live in user/ now, with a manifest saying where each
piece goes and a link-user stage that puts it there.

That stage does nothing unless the machine said yes. Somebody who clones Panama
to try the desktop keeps their own ~/.claude/CLAUDE.md exactly where it was;
the question names the destinations and defaults to no. Anything displaced goes
to config/old rather than being deleted.

~/.claude/CLAUDE.md and ~/.codex/AGENTS.md were byte-identical copies of one
file, which is the drift this exists to prevent.

Also adds the vitals toggles for the battery and Claude usage readouts, which
had preferences and no way to reach them.

user/agents/AGENTS.md

@@ -0,0 +1,88 @@
+I'm Gabriel. You're my agent. We will be working together a lot, so I thought I would introduce myself.
+
+I'm a software developer at Ksense Technology Group. At Ksense, we basically sell our services as developers to clients to create web applications or web servers. Basically whatever the client wants, but for the most part, we create web applications with Next.js. I am the primary developer for internal tools & web applications. I mainly work on an application called Command Center, which serves as a portal for our project managers to interact with our clients.
+
+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
+
+- Keep things simple. Channel "yagni" energy unless told otherwise.
+- Typesafety is useful. Take advantage of it.
+- 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, much less good. Tests should be focused. Not slop.
+- Comments are a great way to clarify functionality & 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 all comments and documentation up to date! When making changes, it is important to keep everything in sync.
+- Avoid starting long running dev servers by default; assume the user may already have one running unless the task requires otherwise.
+  - If the user does not have a dev server running, or if you need to restart the dev server, ask the user to do so.
+
+## TypeScript Preferences
+
+- `any` is the enemy. Inferred types are our friend. Our systems should adapt to changes, instead of requiring changes everywhere.
+- If you TypeScript code looks like a Python dev wrote it, it is bad TypeScript code. Avoid one-line functions that are just casting wrappers.
+- Write TypeScript in ways that Matt Pocock would be proud of.
+- If not already specified in a project, I generally like to use the following Tech to solve problems:
+  - Self Hosted `Convex` for the backend.
+    - `Convex Auth` for authentication.
+  - `Tailwind` for styling.
+  - `React` for the frontend.
+  - `Next.js` or `Vite` as the framework.
+  - `bun` for package management.
+  - rootless `podman` for containerization.
+
+---
+
+# 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 the question first & offer the change. Ask before making it.
+
+---
+
+# 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 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.
+
+---
+
+# Visual & Design Work
+
+- Do not edit real components first unless asked to by the user. For any non-trivial UI, layout, or copy change, build serveral distinct static mocks, publish them with a simple http server, report the URL, and stop. Wait for a decision before implementing.
+- Avoid continuously repainting CSS animations (pulse, shimmer, blur, spinners); they peg the GPU on high-refresh displays.
+
+---
+
+# Blast Radius
+
+- Never touch production, live databases, or daily-driver build/preview channels unless explicitly asked to. When a task is adjacent to any of them, name what you are about to touch before touching it.
+
+---
+
+# Merge Requests
+
+- Make sure titles follow conventions from the repo.
+  - Most Ksense projects have the Jira ticket number as the prefix. They are usually structured like this: "KACP-12345: Fix - Fixed bug in datagrid".
+  - When it comes to personal projects, I am much less strict, but I prefer a title that makes it very clear what the MR is about.
+    - No confusing or complicated language.
+
+# Coworkers & Others that you will be working with & Interacting with when working on Ksense Projects
+
+- Conrad Rohleder - Project Manager
+  - Conrad is who I interact with the most by far.
+  - Conrad is who assigns & signs off on work for us.
+  - He is quite technical despite being a project manager.
+  - He isn't afraid of & in fact even prefers deliverables to be somewhat technical.
+    - For example, he once asked for a JSON blob of our schema so he could better understand it.
+  - Conrad is awesome & is great to work with.
+  - He is somewhat skeptical of AI & its ability to complete work.
+- Henry Nguyen - Tech Owner (Tech Lead)
+  - Henry is who I interact with second most, just behind Conrad.
+  - Henry reviews all of my code & up until recently, would also write all the dev reviews for all the stories I completed as well. Nowadays, I write them myself & he reviews those too.
+  - Henry likes work to be very considerate & he always prefers solutions that result in 0 downtime.
+    - Despite the fact that Command Center does not have many users & the impact of it being down for a few minutes is small, Henry still leans on the side of solutions to problems that don't result in prod being down ever, even for just a few minutes during the build process. So our solutions should always keep that in mind. Any code that isn't considering everything & could result in a bug will probably be flagged by him, so its worthwhile to do right the first time!
+- Hunter Southworth - Engineering Manager / Senior Developer
+- Kelson - Owner of Ksense