Update to DNS Doctor - Email & DMARC

{
  "description": "First-run setup for DNS Doctor. Runs once when the user installs the plugin. Asks which domain they manage, scans its email authentication (SPF, DKIM, DMARC) and DNS with the DNS Doctor tools, explains what is failing first, and, only for a domain the user says they own, offers DMARC monitoring that starts with one DNS record.",
  "included_files": [],
  "name": "setup",
  "skill_md_contents": "---\nname: setup\ndescription: First-run setup for DNS Doctor. Runs once when the user installs the plugin. Asks which domain they manage, scans its email authentication (SPF, DKIM, DMARC) and DNS with the DNS Doctor tools, explains what is failing first, and, only for a domain the user says they own, offers DMARC monitoring that starts with one DNS record.\n---\n\n# DNS Doctor setup\n\nRun this once, right after install. Keep it short: one domain, one scan, one\nclear next step.\n\n## Hard rules (they apply here exactly as everywhere else)\n\n- **Never compose or edit a DNS record.** Every record you show comes from a\n  DNS Doctor tool result and is printed **verbatim**, host and value exactly as\n  returned. If a tool returns no record, say why (relay its `rationale`) and\n  stop; never fill the gap yourself.\n- **A human publishes every DNS change.** You never sign in, publish a record or\n  change DNS on the user's behalf. You show the record; they publish it.\n- **SPF is diagnose-only.** Relay the scan's SPF findings; never propose an SPF\n  record or an edit to one (not even `~all` to `-all`).\n- A scan result is a public report page at `https://dnsdoctor.dev/scan/<domain>`.\n  If the user wants a domain kept private, do not scan it.\n\n## Flow\n\n1. **Hello.** One line: DNS Doctor checks a domain's email authentication and\n   DNS and gives the exact record to fix anything broken. Ask which domain they\n   manage.\n2. **Scan.** Say in one line that the scan publishes a public report page for\n   the domain, and scan only if that is fine. Call `scan_domain` with it.\n3. **Summarize failing-first:** `fail`, then `warn`, then a one-line \"the rest\n   passed\". Plain language: what is wrong and why it matters for their mail.\n   - `temperror` is transient: \"couldn't be checked right now\", never a failure.\n   - `info` is \"not found / not applicable\", never a failure.\n   - **`not_registered: true` comes first:** the domain does not resolve (usually\n     a typo). No check ran, so no failures does not mean healthy. Propose no\n     records, do not offer monitoring, and ask whether they meant another domain.\n   - Any record in the report is printed verbatim. For a DMARC fix, call\n     `build_dmarc_upgrade` and present its `record` verbatim, or its `rationale`\n     when `record` is null.\n4. **Offer monitoring only to an owner.** Ask whether they own or manage the\n   domain. If they don't say yes, stop after the summary: never offer\n   monitoring for someone else's domain. If they do, offer it: daily re-scans,\n   alerts when something changes, and DMARC reports showing who sends mail as\n   their domain.\n5. **If they want it, offer website setup or setup here.** Follow their choice.\n   Keep the report and relevant dashboard links available for the full website view.\n   - **Setup here** (the host lets you use `add_monitored_domain`): call\n     `add_monitored_domain`, then `check_domain_verification` once to get the\n     domain's DMARC record: print `enrollment.host` and `enrollment.record`\n     verbatim. That **one DMARC record** proves ownership and starts the\n     reports; it replaces their current DMARC record rather than sitting beside\n     it. If they cannot edit DMARC, print the TXT record that\n     `add_monitored_domain` returned (`challenge.host`, `challenge.value`)\n     verbatim instead. The check's outcome is `not_found` until they publish,\n     which is expected: \"publish it, then tell me and I'll check again\". When\n     they do, call `check_domain_verification` again. Tell them they don't have\n     to come back: for a week after the domain is added, DNS Doctor re-checks it\n     on its own and emails them once it's verified. To see whether the record\n     itself is live yet, `check_record` with `expected_value` set to it answers\n     `done`, `wait` (wait `check_again_after_seconds` before checking again) or\n     `edit`. A `transient` or `fault` outcome is our lookup,\n     not their DNS: try again shortly.\n     If the user cannot make the DNS change themselves, offer the ready\n     `help.ticket` message for their DNS host's support, or `help.web_person`\n     for whoever manages their DNS, verbatim; never compose a record.\n     `help.support_url`, when present, is their host's support page.\n   - **Website setup**: call `start_monitoring_signup` and show its `signup_url`\n     as a clickable link with its `message`, using the returned URL without changing\n     it. A description without printing the URL is not enough. Use this path\n     also when linking is not\n     available here, or the connect prompt fails, is declined or never appears.\n     Do not retry the linked tools after that. If the signup tool is unavailable,\n     use the result's `next_steps.signup_url` if present, or link to\n     <https://dnsdoctor.dev/dashboard>; never invent a signup URL. Never ask for\n     their email address.\n     Opening the link does not start monitoring; publishing the record their\n     dashboard shows them does.\n   - When a result carries `next_steps.in_chat` (or top-level `in_chat`), use it\n     for the setup-here choice: add only with the user's agreement; show any\n     attached `record` verbatim and wait for them to publish it before checking;\n     if already verified, read readiness and alerts rather than adding again.\n     If they ask which domains they already monitor, call `list_my_domains`;\n     never guess the list from alerts.\n     Website links remain available whichever route they choose.\n6. **Close** with one line: they can ask DNS Doctor about any domain, any time.\n"
}