Domain Market Briefing

intent

produce a domain-market news briefing anchored to an explicit time window, with sourced headlines, a sales table that distinguishes sale types, registration-trend figures, recent domain movements, and a clear split between confirmed causes, plausible context, and unknowns. use this skill when a user wants to know what is happening in the domain market right now. this is a briefing for reference, not investment advice.

inputs

required external connections and data sources

• DomainKits MCP (or equivalent provider): supplies structured evidence through the tools below. query fresh on every run; do not rely on model memory for current events. if a field is absent in the actual payload, mark it Not Provided or the capability Unavailable and continue.

  • keywords_trends: hot and emerging keyword registration trends
  • domain_changes: recent premium-domain transfers, expirations, nameserver changes
  • whois: registration status, registrar, expiry date, lifecycle stage
  • dns: nameserver records and DNS resolution state

• web search and web fetch: current news, official announcements, sales verification, and market events. set queries from the actual current date; never hard-code a calendar year.

• optional (user-initiated follow-ups only):

  • nrds: aggregate registration pattern inspection for emerging keywords or post-sale waves
  • aged: for-sale inventory inspection (do not use to infer causation from listing rises)
  • deleted: dropped-domain candidates requiring availability verification
  • expired: expiring and backorder inventory tracking

user inputs

• time window: requested time window for the briefing. default to last 7 days if not specified.
• current date and timezone: required to build time-scoped queries.

procedure

1. set scope and timestamp.

   • establish the briefing window (default: last 7 days).
   • record the cutoff time, timezone, and exact run time.
   • break out recent movements separately (default: last 24 hours, or state exact coverage if the tool does not support that window).
   • build all search queries from the current date, not hard-coded calendar years.

2. gather evidence fresh from multiple sources.

   • web search for notable sales, industry news, and market events within the window.
   • query keywords_trends (hot) for high-volume keywords and weekly movement.
   • query keywords_trends (emerging) for recent spikes.
   • query domain_changes for recent premium-domain transfers, expirations, and nameserver changes.
   • input: current date, requested window, search terms for sales and market events.
   • output: raw headlines, trend data, domain change records, with source URLs and publication/event dates.

3. analyze trend keywords with figures, not adjectives.

   • for each trend keyword, extract and report: current value, prior value, absolute change, percentage change, baseline window, sample size, and any significance rating provided by the tool.
   • report each field only when the source provides it; mark missing fields as Not Provided.
   • never estimate or reconstruct a missing sample size or significance rating.
   • when current or prior value is zero, write percentage change as Not Meaningful.
   • watch for low-base effects: a rise from 2 to 10 is +400% but may not reflect a meaningful trend. always show absolute numbers.
   • note: registration signals reflect speculation, promotions, bulk registration, or defensive registration; do not equate trend volume with end-user demand.
   • input: trend data from keywords_trends.
   • output: trend table with current, prior, absolute change, percentage change, baseline, sample size, rating.

4. classify and verify sales.

   • for each sale claim, assign a sale type: verified completed sale, publicly reported sale, finalized auction result, current bid, asking/listing price, or unverified claim.
   • record source tier (1-4) and verification status (completed / reported / pending / unverified) as two separate fields.
   • note: source tier measures source authority; verification status measures event state. a Tier 1 source can carry a reported or pending event.
   • distinguish event date (when the sale happened) from publication date (when reported).
   • never report a listing price or current auction bid as a completed sale; route those to the active market offers table.
   • input: sales headlines, official announcements, marketplace data.
   • output: notable sales table and active market offers table (separate tables).

5. validate domain movements by the right source.

   • for registrar transfers, expirations, and lifecycle stage: validate with whois.
   • for nameserver and DNS state: validate with dns.
   • name the lifecycle stage: registrar transfer is not a sale; nameserver change is not a site launch; passed expiry is not imminent deletion; redemption, auction, and pending-delete are distinct stages.
   • ownership change usually cannot be confirmed from whois or dns alone; if the validating source is unavailable, report only the observed technical change, not an inferred transaction.
   • input: domain change records, whois and dns queries for recent domains.
   • output: recent domain movements table with lifecycle stage and validation source.

6. separate confirmed cause from plausible context from unknown.

   • for each notable trend or spike, assign:
     • Confirmed cause: an official source explicitly links it (e.g., a registry announcement of a TLD launch, a company's press release about a major acquisition).
     • Plausible context: events or news correlated in time but causation unproven.
     • Unknown: no reliable explanation found.
   • do not read related news as the cause by default.
   • disclose disclosure bias: public sales data is heavily disclosure-biased; undisclosed sales are not in the sample, so a public leaderboard does not represent the whole market.
   • input: news, announcements, trend data, timeline correlation.
   • output: cause/context table mapping each spike or notable event.

7. rank headlines by source tier and flag verification status.

   • lead with Tier 1 sources (official announcements from registries, ICANN, companies, or verified official accounts).
   • follow with Tier 2 (verifiable sales databases and reliable industry press).
   • follow with Tier 3 (other news reporting).
   • route Tier 4 (anonymous, unofficial, unverifiable sources, unverified social posts, forum tips) to a separate Unverified section; do not feed them into main conclusions by default. note: an official verified account is Tier 1 even if it posts on social media.
   • apply independent-source discipline: the same story republished across several sites is one source, not multiple. count independent reporting.
   • input: all gathered headlines with source URLs and publication dates.
   • output: top headlines by source tier, with verification status labeled on each.

8. present using the output structure.

   • see output contract section below.

decision points

• if user specifies a time window: use it. otherwise default to last 7 days.
• if keywords_trends supports a 24-hour window for recent movements: use it. otherwise state the exact coverage returned and do not imply full-window coverage.
• if a field is absent from the actual payload: mark it Not Provided or Unavailable; do not estimate or invent it.
• if a sale claim appears in only one source: classify it as reported or unverified depending on source tier. if it appears in multiple independent sources, classify as publicly reported or verified (completed if evidence of finalized transaction exists).
• if a domain-change record shows a nameserver change: do not infer a site launch or sale. confirm current NS state with dns; if dns is unavailable, report only the observed change.
• if a domain-change record shows a registrar transfer: do not infer ownership change or sale. report as a registrar transfer with lifecycle stage from whois; if whois is unavailable, report only the observed transfer.
• if a sale price is listed but completion evidence is absent: classify as asking/listing price or current bid and route to active market offers table, not sales table.
• if a trend shows current or prior value as zero: report percentage change as Not Meaningful instead of infinity or undefined.
• if a trend shows a low-base spike (e.g., 2 to 10): flag the absolute numbers alongside the percentage and note the low baseline.
• if the validating source (whois or dns) is unavailable: report only the observed technical change; do not infer transaction, deletion, or ownership.
• if a user requests deeper analysis on an emerging keyword, notable sale, or expiration: offer optional follow-ups using nrds, aged, deleted, or expired (do not invoke automatically).

output contract

format: structured text briefing with the following sections in order.

1. scope, cutoff time, and timezone: the window (e.g., "last 7 days"), cutoff date/time, timezone, and exact run timestamp.

2. top headlines by source tier: highest-tier in-window items, each labeled with verification status (completed / reported / pending / unverified). group by tier (Tier 1, Tier 2, Tier 3). hold Tier 4 in a separate "Unverified items held for reference" section.

3. notable sales table: completed and reported sale events only.

   • columns: Domain | Sale type | Price and currency | Venue | Event date | Publication date | Source | Source tier | Verification status
   • sort by source tier (1 first), then by event date (most recent first).
   • exclude current bids and listing prices; route those to active market offers table.

4. active market offers table: current bids, asking/listing prices, open auctions.

   • columns: Domain | Offer type | Price and currency | Venue | Observation date | Source | Source tier
   • note: these are offers, not transactions; never promote to sales table without completed-sale evidence.

5. registration trend table: keyword trends with figures.

   • columns: Keyword | Current value | Prior value | Absolute change | % change | Baseline window | Sample size | Tool rating
   • report each field only when provided; mark missing fields as Not Provided.
   • when current or prior value is zero, write % change as Not Meaningful.

6. recent domain movements: transfers, expirations, nameserver changes.

   • columns: Domain | Movement type | Lifecycle stage | Validating source | Event date | Observed/confirmed details
   • do not infer ownership, sale, or imminent deletion without validation.

7. confirmed causes, plausible context, unknowns: structured per notable trend or spike.

   • format: for each, list confirmed cause (if any), plausible context (if any), unknown (if cause remains unexplained).

8. data gaps and coverage limitations: list unavailable sources, disclosure bias notice, and any unverified items held aside.

9. sources with event and publication dates: line-by-line source list with URL, source tier, publication date, and event date (if different).

10. market-intelligence disclaimer: "This is a market-intelligence briefing for reference only, not investment advice. Public sales data is disclosure-biased and does not represent the whole market; figures reflect only what was verifiable at the cutoff time."

file location: deliver as inline markdown text, suitable for direct paste into a user-facing document or dashboard. include all tables.

data quality gates: all sales must have source tier and verification status. all trends must show absolute and percentage change alongside baseline and sample size, or mark those fields Not Provided. all domain movements must be validated by the right source or flagged as unvalidated.

outcome signal

the user should be able to answer these questions after reading the briefing:

• what is the time window of this briefing and when were the queries run?
• what are the highest-authority announcements or sales in this window?
• which sales are completed, and which are still reported or pending?
• what are the most active registration keywords right now, with absolute numbers and baselines?
• which domains changed hands, registrars, or nameservers recently, and at what lifecycle stage?
• why did notable trends spike, or is the cause unknown?
• where can the user find the original source for any claim?
• what are the data gaps (unavailable sources, disclosure bias)?

if the user can answer all of these, the briefing is complete and well-sourced.

credits: original design by clawhub. enrichment and standards compliance by implexa.