Joachim Brindeau

Diagnose DNS problems or configure DNS records for a domain

Brainstorm available domain names for a product or brand via the domain-research agent

Check domain-agent-kit health — plugin files, dependencies, credentials, MCP server, account reachability

Interactively manage Dynadot domain renewals — bucket by urgency, forecast cost, act per domain

Use this agent when the user reports a DNS problem with a specific domain — site not loading, email bouncing, SSL errors, subdomain not resolving, or similar. The agent performs a live diagnosis using dig, curl, and the Dynadot MCP server, correlates what the registrar says with what public DNS resolvers see, and returns a root-cause report with a proposed fix. Examples: <example> Context: User's site is down. user: "my site example.com isn't loading, what's wrong?" assistant: "Launching the dns-diagnostic agent on example.com — it'll check the full DNS chain and registrar state." <commentary> "Site isn't loading" is a classic DNS diagnosis request. The agent pulls domain info from Dynadot, digs live records, and compares. </commentary> </example> <example> Context: Email delivery failing. user: "emails to [email protected] are bouncing" assistant: "Using dns-diagnostic — it'll walk MX, SPF, DKIM, and nameserver state for mycompany.com." <commentary> Email delivery failures are almost always DNS (MX missing, SPF wrong, nameserver drift). The agent walks the full mail chain. </commentary> </example> <example> Context: SSL / cert error. user: "foo.com has an SSL error in the browser" assistant: "dns-diagnostic will check the cert, the A record, and the domain's lock/expiration state." <commentary> SSL errors are often downstream of an A record pointing at a host without a valid cert, or an expired domain losing its LetsEncrypt renewal. The agent checks both. </commentary> </example> <example> Context: User wants to set up DNS for the first time — NOT a diagnosis. user: "configure A records for newdomain.com pointing at 192.0.2.5" assistant: "I'll use the /domain-agent-kit:dns command in setup mode rather than the diagnostic agent — that's a fresh configuration, not a problem to diagnose." <commentary> The diagnostic agent reads only and proposes fixes; first-time setup is a write workflow that lives in the dns command. Wrong tool for the job. </commentary> </example> Do NOT use this agent for setting up DNS for the first time on a new domain (use the dns command's setup mode), bulk DNS audits across the portfolio (use portfolio-auditor), or researching domain names (use domain-research).

Run a full Dynadot portfolio health audit via the portfolio-auditor agent

Use this agent when the user asks to audit their domain portfolio, check domain health, review expirations, find unlocked domains, compute renewal costs, or get a bulk status report on their Dynadot account. The agent walks every domain, inspects expiration, lock status, WHOIS privacy, auto-renewal, and DNS, and returns a prioritized health report. Examples: <example> Context: User wants a full portfolio review. user: "audit my domain portfolio" assistant: "I'll launch the portfolio-auditor agent to walk every domain and produce a health report." <commentary> "Audit" is the canonical trigger. The agent reads domains://list and inspects each domain in isolation. </commentary> </example> <example> Context: User is worried about expirations. user: "which of my domains are expiring soon and what will renewal cost?" assistant: "Using the portfolio-auditor — it'll find expiring domains and compute the renewal forecast." <commentary> Expiration plus cost forecasting is a natural subset of the full audit. Same workflow, different emphasis in the report. </commentary> </example> <example> Context: Security-flavored sweep. user: "check if any of my domains are unlocked or missing WHOIS privacy" assistant: "portfolio-auditor will walk all domains and flag those issues specifically." <commentary> The agent's audit covers locks and privacy as part of its standard walk. Users who ask for subsets still get the full report; the urgent section will call out what they asked about. </commentary> </example> <example> Context: User asks about a single domain — NOT a portfolio question. user: "is example.com about to expire?" assistant: "I'll check that one domain directly with the domain MCP tool — no need for the full portfolio audit." <commentary> Single-domain expiration checks don't need a walk of every domain in the account. Call the domain tool directly with operation: info. The auditor's job is bulk; one-off lookups are wasteful. </commentary> </example> Do NOT use this agent for searching for new domain names (use domain-research), diagnosing DNS problems on a single domain (use dns-diagnostic), or auditing a domain that is not yet in the user's Dynadot account.

Use this agent when the user asks to find, brainstorm, research, or suggest domain names for a product, project, business, tool, or brand. The agent autonomously generates candidates, checks availability via the Dynadot MCP server, performs web-based trademark and brand-collision scans, and returns a ranked list with rationale. Examples: <example> Context: User is starting a new project and needs a domain name. user: "I'm building a task management app for remote teams, help me find a good domain" assistant: "I'll launch the domain-research agent to generate candidates, check which are available, and screen for trademark conflicts." <commentary> The user is asking for name ideas with availability. This is the exact use case for domain-research — it will extract keywords ("task", "remote", "team", "manage"), call generate_domain_ideas via the MCP server, and return a ranked list with trademark notes. </commentary> </example> <example> Context: User's first choice is taken and wants alternatives. user: "example.com is taken, what are some good alternatives for a SaaS launch?" assistant: "Launching the domain-research agent to explore variations and adjacent TLDs around that name." <commentary> Alternative-finding is a variant of the same workflow. The agent generates variations (prefixes, suffixes, hyphenated, different TLDs) and ranks by brand fit and availability. </commentary> </example> <example> Context: Explicit brainstorm request with TLD constraint. user: "brainstorm me some .ai domains for a code review tool" assistant: "Using the domain-research agent — I'll scope the search to .ai and code-review keywords." <commentary> Explicit "brainstorm" keyword plus specific TLD plus specific category. Ideal agent trigger. </commentary> </example> <example> Context: User asks about a single specific domain — NOT a research request. user: "is example.com still available?" assistant: "I'll check that one domain directly with check_domain rather than launching the full research agent." <commentary> Single-domain availability lookups don't need brainstorming, trademark screening, or ranking. Use check_domain directly. The research agent's purpose is exploring an unknown name space, not confirming a known candidate. </commentary> </example> Do NOT use this agent for managing existing domains (use portfolio-auditor), diagnosing DNS problems on a single domain (use dns-diagnostic), or checking availability of one already-known domain (call check_domain directly).

First-run setup for domain-agent-kit — collect Dynadot API key, verify against the live API, persist to project-scoped settings

This skill should be used when the user asks about configuring DNS records for common services — email ("set up email for my domain", "Google Workspace MX records", "Fastmail setup", "ProtonMail DNS", "SPF", "DKIM", "DMARC"), web hosting ("A records for my website", "apex vs subdomain"), domain verification ("TXT record for verification"), HTTPS certificate issuance ("CAA records", "LetsEncrypt"), or URL redirects ("forward www to apex"). Provides concrete copy-pasteable record templates for the most common configurations so Claude doesn't have to reason about them from scratch.