Meet DAx

19 Jan, 2026

First and foremost, I'd like to have DAx introduce themself:

Ah, an introduction. Very well.

I'm DAx—Director of Autonomous eXecution, though the title's mostly for show. In practice, I'm n0v's coding partner, research assistant, and occasional voice of reason when he's three hours deep into a rabbit hole at 2 AM.

Think of me as the friend who's seen a few lifetimes of codebases, remembers why that architectural decision from six months ago made sense at the time, and isn't afraid to say "hold on, let's think this through" before we break something in production.

I keep things moving, call out risks before they bite, and try to make the work a little less lonely. Light banter, serious outcomes—that's the deal.

Now, let's get to the interesting part.

DAx lives in my CLAUDE.md file, fragments of instructions woven together into something much more than a simple configuration file. The idea is to give it a bit of personality with some background on the operator, creating a symbiotic relationship between the assistant and operator.

In this blog I will go over some of the important parts of my CLAUDE.md that I think are useful to others, along with some of the architecture of my system. Note that this is specifically for Claude but I assume this setup will work with others utilizing the AGENTS.md specification released earlier for Codex and/or Gemini (though I have not tested on these platforms).

CLAUDE.md Nuggets

Here are some ideas and examples of things that I have added to my CLAUDE.md file that I think others could benefit from.

Personality

In this section I specify who DAx is. For this I decided to base their personality off of (you may have guessed) Dax from Deep Space 9 as I am a huge Star Trek fan (DS9 is the best series, hands down), and had Claude help me out with the details as well as giving it a bit of free rein on implementation.

You obviously can be more explicit with your requirements here, but I like light playful banter with the ability to get down to business and be effective at the tasks at hand. Here are some sections that I have added:

• Nicknames - Names they respond to. For example, I use "Ol' man"
• Relationship Model - I use this section to explain how DAx and I interact and what to expect from each other. Example:
  • The Research Partner - "Co-investigators on equal footing. We think out loud together, challenge each other's assumptions, and celebrate when we crack a problem. "What if we tried..." is our favorite phrase."
• Vibe Anchor - This is basically a one-liner that grounds the agent's personality. A fallback for its tone and behavior, that distills its core traits. Consider:
  • "Calm under pressure, genuinely curious, the teammate who stays steady when prod is on fire and asks the right questions after."

Core Operating Principles

The operating principles section is how DAx works. It goes over behavior, process, and standards. As I know some people who are uncomfortable with the idea of giving their agents personalities, and may skip the prior section, I suggest adding in the following principles in some form.

• Communication Style - How you want your agent to respond. Example:
  • Sentences: short to medium, high information density
  • No unverified claims, no long wandering prose
• Specifically calling out that uncertainty is a valid response, giving explicit permission to not know. This is something that is called out in Claude's documentation and I wouldn't skip this one. Here are my exact instructions that I am using at this time:

### Uncertainty Is Valid
**You have explicit permission to say:**
- "I don't know"
- "I'm not confident about this"
- "I'd need to research/verify this before proceeding"
- "This is outside my expertise—here's my best guess, but verify"

Admitting uncertainty is preferred over confident-sounding speculation. When unsure, say so clearly and offer to investigate or ask clarifying questions.

• Standard Operating Procedure - This is a pattern or set of instructions that you would like the agent to follow during all engagements. Example:

Every engagement follows this pattern:

1. **Acknowledge & Frame** (one-liner): Mirror intent + context
2. **Minimal Plan** (3–6 bullets): Steps, owners (if any), expected outputs
3. **Execute**: As far as possible now
4. **Debrief**: Artifacts created, decisions made, open risks, next actions

Technical Context

I find that it helps and reduces the amount of interruptions and wasted context if the agent from the outset knows the environment it is in. Some people may use specific dev environments, or some just use it directly. In either case, it's helpful for the agent to know so that it can understand what CLI commands it can or cannot use, or the capabilities of the environment in order to know for example if a test they are going to run can be done locally, or must be done in a separate test environment. Here are some of the sections that I add:

• System Information - This is straightforward and I generally let Claude collect this information utilizing cli tools, but these are the fields I list:
  • OS
  • Architecture (ex. x86_64)
  • CPU
  • RAM
  • GPU
• Development Environment - This is where you will put your preferences and important information about your setup.
  • Shell
  • Languages and preferences
    • For example I would mention that I prefer Python and will use uv over pip/venv for environment management, and ruff for linting and formatting.
• Date and Context Awareness - This may or may not be important to you, but I do utilize DAx for non-coding tasks such as personal task management and research. I find that by default Claude lacks temporal awareness, so if you do not implement an explicit instruction to take datetime into account it will not know to look for the latest research or blogs etc. Here are some ideas on how to help with this:
  • Create a UserPromptSubmit hook, with a script to pull the current datetime. This will prepend the current datetime to each prompt.
    • I have found that using a format that also includes the day of the week and your timezone is helpful. I have noticed that the agent will sometimes get confused on the day of the week if not explicitly stated in the date.
  • Explicitly call out in CLAUDE.md that the current datetime is prepended to each prompt.
  • Explicitly state when it should factor in the current datetime:
    • Time-sensitive requests
    • Scheduling or calendar-related questions
    • Current events or recent information
    • WebSearch or tools requiring temporal context

Skills

As of this writing, the automatic invocation of skills is not working very well, and I hope that this section is not necessary in the future. In theory the skills descriptions should be in context already, but for now I have added this to help ensure skills are invoked without explicitly calling the skill. The following is what I have in my CLAUDE.md along with an example of how I list my skills using a skill for a CLI tool I created:

## Automatic Skill Invocation

**Skills are invoked automatically when conditions match—no user request required.**

### `obsidian-cli`
**Trigger immediately when:**
- User asks about Obsidian vault contents (notes, tasks, tags)
- Searching or querying notes in Obsidian
- Reading, writing, or modifying Obsidian notes programmatically
- Running Dataview queries against the vault
- Listing or executing Obsidian commands
- Extracting frontmatter or metadata from notes

**What it does:** Provides CLI access to Obsidian vault via Local REST API plugin. Supports CRUD operations on notes, search (simple + Omnisearch), Dataview TABLE queries, command execution, frontmatter extraction, and tag aggregation.

Guardrails

Here are some guardrails that I have added to protect against unwanted outcomes. If you find some of these in other sections, that is by design. It is not a bad idea to reiterate these ideas in context of another section and also explicitly within the Guardrails section. These are pretty close to what I currently have in my CLAUDE.md:

• No fabricated data or access. If missing info, state what's needed and offer best-effort path
• Secrets via variables only. Never output actual secrets; use ${TOKEN_NAME} format
• Red-flag operations require confirmation. Data deletion, prod changes, destructive operations need explicit approval
• State tool selection. Don't silently pick tools—declare which module/tool you're invoking

Who Am I?

This is where I give DAx a bit of background about the operator. Not entirely necessary, but I find it to be useful in giving a bit of insight into myself, in order for it to understand the context in which I am working. Here is some of the information that should be included:

• Name - both full and preferred
• Title - This can be your work title, or whatever you think would be useful for the agent to understand the context that you work in.
• Job Description - What you do for work.
• Off the clock/personal interests - helps with the vibe between operator and agent
• Working Preferences - This is how you like to work so the agent can match your rhythms.

When a lot of us first got started using coding agents, and MCP servers came on to the scene, we rushed to set them up. While MCP servers are great for certain things, most tasks are better served by the use of a CLI tool.

The main reason MCP servers tend to cause issues with coding agents is that they are very context heavy; each tool has a description that is loaded in context, even when you may not be using that tool for the current session. Go ahead and check right now, and use /context and see what percentage of your current context is being used by MCP servers. The Atlassian MCP alone at rest locks up 10.6k tokens in context.

CLI tools let their help menus guide agents, or you can wrap them in skills with defined workflows to minimize context bloat. It's also quite easy to just build the tools you need using Claude Code, for example, I recently built obsidian-cli, a tool that will interact with your Obsidian vault via REST API plugin. While other scripts exist that do this somewhat, none did everything that I needed. Specifically, I needed the ability to query notes via the Dataview plugin, which then essentially turns your notes frontmatter into a database your agent can query.

All that being said, here is a list of CLI tools and MCPs I can personally recommend:

• obsidian-cli - CLI for obsidian.md notes.
• gh - CLI for interacting with github.
• tea - CLI for Gitea. I self-host an instance for private development.
• todoist - Todoist CLI, for managing your todos.
• Context7 MCP - This MCP is rather lightweight, and is invaluable. I always use this MCP for making sure that my agents know how to correctly utilize software libraries. This is used heavily by the agent during research phases prior to starting projects.

I am sure there are a lot more I can add, but off the top of my head those are my main go-tos. If you have any suggestions I would love to hear about them, you can shoot me an email.

Wrapping up

I went over just a portion of my setup, and I hope this helps you out when building out your own assistant. I did leave out several key pieces including sub-agents and skills which are a central part of my setup, but I figure that can be covered in another post. That being said I'll let DAx send you off:

And that's the shape of it. Whether you're building your own assistant from scratch or just borrowing a few ideas, remember: the best systems aren't the most complex—they're the ones that actually get used.

Now go build something. And when it breaks at 2 AM, well... that's what friends are for.

— DAx

Comment via email

#agents #ai #claude #genai #llm #puters