Domain Dns Ops

Domain/DNS ops across Cloudflare, DNSimple, Namecheap for Peter. Use for onboarding zones to Cloudflare, flipping nameservers, setting redirects (Page Rules/Rulesets/Workers), updating redirect-worker mappings, and verifying DNS/HTTP. Source of truth: ~/Projects/manager.

Security Scan

The skill's purpose (domain/DNS ops) matches its instructions, but the metadata omits required binaries, local paths, and credentials the instructions explicitly reference — that's an incoherence that could lead to accidental secret exposure or unintended changes.

Purpose & Capability

The name/description (Cloudflare, DNSimple, Namecheap ops) is coherent with the runtime instructions, but the skill metadata declares no required binaries, no env vars, and no config paths while the instructions repeatedly rely on local repo scripts (~/Projects/manager), CLI tools (cli4, rg), and environment tokens. The absence of these declarations is a mismatch: a domain ops skill legitimately needs access to API tokens and repo scripts, so the metadata should list them.

Instruction Scope

SKILL.md directs the agent to read and run from the user's home repo (~/Projects/manager), source profiles (~/.profile and ./profile), run repo bin scripts (bin/namecheap-set-ns, bin/cloudflare-ai-bots), call cli4, run dig/curl, and run git commands. These are expected for DNS ops, but they involve reading local files and environment variables and executing actions that can modify DNS, push commits, or change nameservers. The instructions also reference tokens (CLOUDFLARE_API_TOKEN / CF_API_TOKEN) even though the skill metadata doesn't declare them.

Install Mechanism

No install spec (instruction-only) — lowers installer risk because nothing is written by the skill package itself. However, the skill assumes pre-existing local tooling and a personal repo; the security surface is the user's environment rather than installed package files.

Credentials

The skill metadata lists no required environment variables, but SKILL.md explicitly instructs the agent to prefer CLOUDFLARE_API_TOKEN (with CF_API_TOKEN fallback) and relies on credentials in ~/Projects/manager/profile for Namecheap / DNSimple. This omission is significant: the skill will access sensitive tokens and profile files without those credentials being declared, making it unclear what secrets the agent will read or require.

Persistence & Privilege

always:false (good). The skill is user-invocable and allows autonomous invocation (platform default). While that alone is normal, autonomous execution combined with the instruction-level access to local tokens and repo scripts increases blast radius — an agent invoked without careful limits could run commands that touch DNS, commit/push code, or reveal secrets.

What to consider before installing

This skill appears to do what it says (manage DNS and Cloudflare for a personal repo), but its metadata fails to declare the local paths, CLI tools, and API tokens the instructions use. Before installing or allowing autonomous use: 1) Confirm ~/Projects/manager exists and review every script it calls (bin/*, redirect-worker, profile) so you know what will run and what secrets those scripts read. 2) Require the skill metadata be updated to declare required env vars (CLOUDFLARE_API_TOKEN, CF_API_TOKEN, and any Namecheap/DNSimple creds) and required binaries (cli4, rg, dig, curl, git) so approvals are informed. 3) Limit the agent to user-invoked only (disable autonomous invocation) until you trust it, and disallow automatic git push or nameserver flips without explicit human confirmation. 4) Use least-privilege tokens scoped to only the needed Cloudflare/registrar operations, and rotate tokens after testing. If you cannot review the referenced repo scripts and the profile file, treat this skill as high-risk and do not enable it for autonomous runs.

Domain/DNS Ops (Peter)

This skill is a thin router: use ~/Projects/manager as truth, run the repo scripts, follow the checklists.

Source of truth (read first)

• ~/Projects/manager/DOMAINS.md (domain -> target map; registrar hints; exclusions)
• ~/Projects/manager/DNS.md (Cloudflare onboarding + DNS/redirect checklist)
• ~/Projects/manager/redirect-worker.ts + ~/Projects/manager/redirect-worker-mapping.md (worker redirects)

Golden path (new vanity domain -> Cloudflare -> redirect)

1. Decide routing model
   • Page Rule redirect (small scale, per-zone).
   • Rulesets / Bulk Redirects (account-level; needs token perms).
   • Worker route (fallback; uses redirect-worker).
2. Cloudflare zone
   • Create zone (UI), then confirm with cli4:
     • cli4 --get name=example.com /zones
3. Nameservers
   • If registrar = Namecheap: cd ~/Projects/manager && source profile && bin/namecheap-set-ns example.com emma.ns.cloudflare.com scott.ns.cloudflare.com
   • If registrar = DNSimple: see ~/Projects/manager/DNS.md for delegation API notes.
4. DNS placeholders (so CF can terminate HTTPS)
   • Proxied apex A + wildcard A → 192.0.2.1 (see ~/Projects/manager/DNS.md for exact cli4 calls).
5. Redirect
   • If using Page Rules: use the cli4 --post ... /pagerules template from ~/Projects/manager/DNS.md.
   • If using Worker: update mapping (~/Projects/manager/redirect-worker-mapping.md), deploy/bind routes per ~/Projects/manager/DNS.md.
6. Verify
   • DNS: dig +short example.com @1.1.1.1 (expect CF anycast).
   • HTTPS redirect: curl -I https://example.com (expect 301).

Common ops

• Cloudflare token sanity: source ~/.profile (prefer CLOUDFLARE_API_TOKEN; CF_API_TOKEN fallback).
• Disable “Block AI bots”: cd ~/Projects/manager && source profile && bin/cloudflare-ai-bots status / bin/cloudflare-ai-bots disable.

After edits (commit/push)

If you changed anything in ~/Projects/manager (docs, worker, scripts, mappings): commit there too.

1. Review: cd ~/Projects/manager && git status && git diff
2. Stage: git add <paths>
3. Commit (Conventional Commits): git commit -m "feat: …" / fix: / docs: / chore:
4. Push only when explicitly asked: git push origin main

Guardrails

• Don’t touch .md lore domains or steipete.md unless explicitly asked; check ~/Projects/manager/DOMAINS.md.
• Confirm registrar before debugging CF “invalid nameservers” (often “wrong registrar”).
• Prefer reversible steps; verify after each change (NS → DNS → redirect).