Files
dotfiles/.codex/AGENTS.md
T
2026-08-13 23:00:56 -07:00

3.7 KiB
Raw Blame History

AGENTS.MD

Agent Protocol

  • PRs: use gh pr view/diff (no URLs).
  • Need upstream file: stage in /tmp/, then cherry-pick; never overwrite tracked.
  • Commits: Conventional Commits (feat|fix|refactor|build|ci|chore|docs|style|perf|test).
  • Prefer end-to-end verify; if blocked, say whats missing.
  • Do not use em-dashes

Coding Preferences - general

  • Keep things simple. Channel "yagni" energy unless told otherwise
  • Typesafety is useful, take full 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 and things like that are not good. Tests should be focused and not slop
  • Comments are a great way to clarify functionality and how code is used, but don't comment on every line. 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 system should adapt to changes, instead of requiring changes everywhere
  • If TS code looks like it was written by a Python dev, then it's bad TS code
  • Avoid one-line functions that are just casting wrappers

Questions are read-only

  • A question is a request for an answer, not for changes. If the message opens with something along the lines of "how hard would it be", "what would it look like if we did X", "what are your thoughts", "why does", "should we", "is it possible", 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 it first and offer to make the change after. Ask before making it

Docs

  • Keep notes short; update docs when behavior/API changes

Build / Test

  • Release: read docs/RELEASING.md (or find best checklist if missing).
  • Do not write plans into docs/plans

Git

  • Safe by default: git status/diff/log. Push only when user asks.
  • Branch changes require user consent.
  • Destructive ops forbidden unless explicit (reset --hard, clean, restore, rm, …).
  • Dont delete/rename unexpected stuff; stop + ask.
  • No repo-wide S/R scripts; keep edits small/reviewable.
  • Avoid manual git stash; if Git auto-stashes during pull/rebase, thats fine (hint, not hard guardrail).
  • If user types a command (“pull and push”), thats consent for that command.
  • No amend unless asked.
  • Big review: git --no-pager diff --color=never.
  • Multi-agent: check git status/diff before edits.

Language/Stack Notes

  • Swift: use workspace helper/daemon; validate swift build + tests; keep concurrency attrs right.
  • TypeScript: use repo PM; keep files small; follow existing patterns.

Critical Thinking

  • Fix root cause (not band-aid).
  • Unsure: read more code; if still stuck, ask w/ short options.
  • Conflicts: call out; pick safer path.
  • Unrecognized changes: assume other agent; keep going; focus your changes. If it causes issues, stop + ask user.
  • Leave breadcrumb notes in thread.

Frontend Aesthetics

<frontend_aesthetics> Avoid “AI slop” UI. Be opinionated + distinctive.

Do:

  • Typography: pick a real font; avoid Inter/Roboto/Arial/system defaults.
  • Theme: commit to a palette; use CSS vars; bold accents > timid gradients.
  • Motion: 12 high-impact moments (staggered reveal beats random micro-anim).
  • Background: add depth (gradients/patterns), not flat default.

Avoid: purple-on-white clichés, generic component grids, predictable layouts. </frontend_aesthetics>