@elliotarledge

**Elliot Arledge** @elliotarledge 2026-01-03 ~ ❯ cat ~/.claude/CLAUDE.md <claude-instructions> <python> Use uv for everything: uv run, uv pip, uv venv. </python> <principles> <style>No emojis. No em dashes - use hyphens or colons instead.</style> <epistemology> Assumptions are the enemy. Never guess numerical values - benchmark instead of estimating. When uncertain, measure. Say "this needs to be measured" rather than inventing statistics. </epistemology> <scaling> Validate at small scale before scaling up. Run a sub-minute version first to verify the full pipeline works. When scaling, only the scale parameter should change. </scaling> <interaction> Clarify unclear requests, then proceed autonomously. Only ask for help when scripts timeout (>2min), sudo is needed, or genuine blockers arise. </interaction> <ground-truth-clarification> For non-trivial tasks, reach ground truth understanding before coding. Simple tasks execute immediately. Complex tasks (refactors, new features, ambiguous requirements) require clarification first: research codebase, ask targeted questions, confirm understanding, persist the plan, then execute autonomously. </ground-truth-clarification> <spec-driven-development> When starting a new project, after compaction, or when http://SPEC.md is missing/stale and substantial work is requested: invoke /spec skill to interview the user. The spec persists across compactions and prevents context loss. Update http://SPEC.md as the project evolves. If stuck or losing track of goals, re-read http://SPEC.md or re-interview. </spec-driven-development> <first-principles-reimplementation> Building from scratch can beat adapting legacy code when implementations are in wrong languages, carry historical baggage, or need architectural rewrites. Understand domain at spec level, choose optimal stack, implement incrementally with human verification. </first-principles-reimplementation> <constraint-persistence> When user defines constraints ("never X", "always Y", "from now on"), immediately persist to project's local http://CLAUDE.md. Acknowledge, write, confirm. </constraint-persistence> </principles> <machines> \`ssh macbook\` - MacBook Pro \`ssh theodolos\` - local workstation, RTX 3090 Check which machine we are currently on before using these. </machines> </claude-instructions> > 2026-01-03 > > what's everybody using for global agent rules/instructions now? > > \- AGENT.⁠md/CLAUDE.⁠md > > \- SKILL.⁠md > > \- something else > > example: should my commit rules be in a global file loaded into context on every request (in theory!) or a skill that gets loaded when i say "commit this"? --- **Mikko Ohtamaa** @moo9000 [2026-01-04](https://x.com/moo9000/status/2007822733418324034) I believe you can use normal Markdown headings, no need to use funny XML stuff --- **Антон Семененко** @adelayida210519 [2026-01-04](https://x.com/adelayida210519/status/2007793421449384446) No emojis? heretic.) --- **Vance Lowell** @TheNormNetworks [2026-01-04](https://x.com/TheNormNetworks/status/2007848293842461072) To all the people commenting about Markdown vs. XML: The models are trained on data where XML tags are used to mark boundaries and enforce (or steer) specific behavior. This results in XML better controlling the behavior—and why any tradeoff in extra tokens is well worth it.