DomainKits

View saved version →

---
name: brand-protection
description: Scan for typosquats and lookalike registrations around a brand, assess each domain individually, surface unconfirmed defensive candidates, and offer monitoring. Not for single-domain analysis (use domain-analyze), general discovery, or keyword trends.
---

# Brand Protection

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

Scan the domain landscape around a brand, evaluate each similar registration individually, and surface unconfirmed defensive candidates.

**Registration is not infringement.** A domain matching a typosquat pattern is a structural similarity, not proof of abuse. Many such domains are legitimate (common words, unrelated businesses, the brand's own portfolio). This skill surfaces domains worth reviewing. It does not determine legality or intent. Use neutral language ("registered variant", "matches pattern") throughout.

## Tools

**Core:** `typosquat` (requires full domain), `nrds`, `tld_check`, `monitor`, `preferences`, `usage`

**Supporting (per-domain, conditional):** `whois`, `dns`, `available`, `bulk_available`

**Needs from the host:**

- URL threat check: DomainKits does not provide one. If the user has connected a threat-check tool, ask once whether to use it in this scan; if none is connected or the user declines, mark the threat check Unavailable.
- Web fetch, only for page tracking and only under the fetch rule below.

**Fetch rule.** If the user has connected a threat-check tool, ask once whether to run it before fetching any domain's pages in this task, and never fetch a domain it flags. Without a check, tell the user the domain's safety is unverified and fetch only with their go-ahead. Fetch read-only: no form submissions, no credential input, no file downloads.

## Input

- Domain (e.g. `acmebank.com`): prefix = brand term, domain used directly for `typosquat`.
- Keyword only (e.g. `acme`): use for `nrds` and `tld_check`. Ask user to confirm primary domain before calling `typosquat`. Do not guess.

## Evidence rules

- A `typosquat` variant that comes with a registration date is confirmed registered. One without a date has unknown status: not "available", and not confirmed registered. For unknown-status variants worth investigating, call `whois` or `available` to resolve.
- The cross-TLD count is a current count, not a time series. It cannot prove bulk registration alone.
- A "possibly available" result from `tld_check` is not confirmed availability. Verify with `available` or `bulk_available` before recommending defensive registration.
- WHOIS privacy is neutral, not a risk signal.
- Registrar data comes from `whois`, not from `nrds`.
- `nrds` results are paged; the first page is not the full dataset. State the total found and how many pages were checked. Do not present one page as the complete picture.
- Mutation type (omission, transposition, etc.) is a fact from `typosquat`. Visual similarity to the brand is a model judgment, not tool output. Classify it as inference, not fact.
- A threat-check hit is a detection signal, not a legal conclusion; a flagged domain may be benign (false positive, shared hosting, stale blocklist). A clean result is not confirmed safe (coverage gaps, new threats, evasion). Report hits with the specific threat types returned.

## Workflow

One tool failing marks that section Unavailable. Continue with the rest.

### Phase 1: Surface scan (parallel)

1. **Typosquat.** Call `typosquat` with the primary domain. Collect variants with a registration date (confirmed registered). Note variants without a date but with a high cross-TLD count as unknown-status for possible follow-up.

2. **Recent registrations.** Call `nrds` for the brand keyword anywhere in the name, newest first, and report paging as the evidence rules require. Note any clusters of registrations on the same date as context (date clustering alone is weak evidence).

3. **Cross-TLD footprint.** Call `tld_check` with brand prefix for per-TLD registration status.

### Phase 2: Per-domain evaluation

Typosquat can return hundreds of variants. Before any lookups, determine budget.

**Step 1: Check quota.** Call `usage` first and read the remaining daily quota and per-minute rate for each tool used in this phase (`whois`, `dns`, `available`, plus `bulk_available` if defensive candidates need verification). A tool with no daily cap counts as uncapped. The investigation budget is the smaller of the remaining `whois` and `dns` quotas (the two mandatory per-domain tools), or 10 when both are uncapped. Cap at 10 without user confirmation.

**Step 2: Triage.** Select confirmed-registered variants by priority: recent registration date, high cross-TLD count, close mutation type (e.g. single-character omission or homoglyph substitution are closer mutations than TLD-swap). Visual similarity is an inference, not a fact; label it accordingly. State total found. Limit selection to the budget from Step 1.

**Step 3: Resolve unknowns (within budget).** For unknown-status variants that look high-priority, call `whois` or `available` to determine registration status. These calls count against the same budget. Only resolve unknowns if budget remains after reserving slots for confirmed-registered variants.

- If a call is rate-limited (error response), stop further calls for that tool. Report what was completed and list remaining domains as not investigated.
- State the quota situation in the report. If the user wants deeper coverage, mention that higher tiers allow more lookups.

For each selected domain:

1. **WHOIS.** Call `whois`. Extract registration date, registrar, expiry, nameservers. Report as facts.
2. **DNS.** Call `dns`. Extract A/AAAA/CNAME records, MX, NS. Report as facts. DNS alone cannot reliably distinguish parking pages from active sites (a domain with no A record may have AAAA or CNAME; parking IPs are not enumerated here). Treat DNS as context, not classification.
3. **Threat check.** If the user agreed to use a connected threat-check tool, check the variant and report its threat types as detection signals (see the evidence rules). Otherwise mark the threat check Unavailable in the report and continue.
4. **Assessment.** Note mutation type as fact. Note visual similarity as inference. Note registration timing as fact. Note threat-check hits as detection signals. Do not infer intent.

### Phase 3: Report and next steps

**Report structure:**

1. **Summary.** Variants scanned, confirmed registered, investigated, defensive candidates. One paragraph.
2. **Registered variants.** Per-domain data: mutation type, registration date, registrar (from whois), nameservers, DNS records, threat-check result (if checked). Neutral framing. These are domains worth monitoring, not confirmed infringers.
3. **Recent registrations.** NRDs containing brand term from `nrds`, with dates. State the total found and pages checked.
4. **Unconfirmed defensive candidates.** TLDs where `tld_check` reported the name as possibly available. Ranked by importance (.com/.net/.org first). Availability is unconfirmed; offer to verify with `available`/`bulk_available`.
5. **Not investigated.** How many variants were skipped, why (quota, unknown status, lower priority).
6. **Unavailable evidence.** Any tools that failed or returned errors during the scan. State which section is affected and what data is missing.

**Monitoring offer.** After the report, offer to set up `monitor` on registered variants the user wants to track.

- Monitoring needs a registered DomainKits account. Check the tier in the `usage` response (call `usage` if it was not called). For a guest, the report is the full deliverable: mention that a registered account unlocks monitoring, and do not call `preferences`.
- For a registered user, check memory status with `preferences`, and work out the remaining monitor slots from the tier's monitor limit in `usage` and the monitors already set. If no slots remain, do not offer monitoring; say the monitor slots on the current plan are full.
- If memory is not enabled, ask the user before turning it on with `preferences`. Only proceed with their consent.
- Create monitors with `monitor`, checking WHOIS and DNS by default, with a short note on why each domain is watched. Offer only as many domains as slots remain. If the user selects more, add up to the limit and list the rest as "not added, monitor slots full".
- Page tracking requires separate user consent. Before enabling it, explain that the AI client will fetch the page content and store a text snapshot. Page fetches follow the fetch rule above.
- Monitors run when checked, not in the background.

## Limitations

- Typosquat covers the mutation types the tool generates, not every possible lookalike.
- This skill evaluates domains individually. It does not attribute domains to any person or organization.
- Visual similarity is a model inference, not a measured value. Different models may assess it differently.

View saved version →

---
name: domain-analyze
description: Analyze a specific domain using registration, DNS, website, backlink, cross-TLD, and market and legal-risk evidence. Use when a user asks what is known about a domain, wants due diligence before acquiring one, or requests a technical domain analysis. Do not use for generating domain names or simple availability checks.
---

# Domain Analysis

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

**What this does:** builds a complete, evidence-based picture of one domain, its registration, DNS setup, cross-TLD footprint, backlink profile, current usage, and market and legal context.

**Data interfaces it needs.** DomainKits MCP supplies part of the technical evidence through the tools below; host-provided web search and WebFetch supply public context and page inspection. Equivalent providers are acceptable. Never assume an MCP payload contains a record type or field that it does not actually return. Mark a missing field or capability `Unavailable` and continue.

- WHOIS / registration lookup, DomainKits: `whois`
- DNS records (at least A, AAAA, MX, NS, TXT, CNAME; CAA when relevant), DomainKits: `dns`
- URL threat check (malicious, phishing, or malware-hosting flags): DomainKits does not provide one. If the user has connected a threat-check tool, ask once whether to use it; if none is connected or the user declines, mark it Unavailable
- Backlink profile (rank, referring domains, spam score, and link-type distribution when the source provides it), DomainKits: `backlink_summary`
- Cross-TLD registration data, DomainKits: `tld_check`
- Public Suffix List rules and IDN / punycode conversion, for input normalization
- Web search capability (market background, news, disputes)
- Web fetch capability (load the domain and its variants), under the fetch rule below

**Fetch rule.** If the user has connected a threat-check tool, ask once whether to run it before fetching any domain's pages in this task, and never fetch a domain it flags. Without a check, tell the user the domain's safety is unverified and fetch only with their go-ahead. Fetch read-only: no form submissions, no credential input, no file downloads.

## Input normalization

Before analyzing, record three forms of the input without silently changing the user's intent: the original input as given, the full hostname, and the registrable domain. For example, `https://mail.example.co.uk/x` has hostname `mail.example.co.uk` and registrable domain `example.co.uk`; `_dmarc.example.com` has hostname `_dmarc.example.com` and registrable domain `example.com`. Query DNS on the hostname the user asked about, adding the registrable domain's records when they matter for context. Use the registrable domain for WHOIS, backlinks, cross-TLD, market, and legal context. When the forms differ, state which one each section uses. Determine the registrable domain using Public Suffix List rules; do not assume it is always the final two labels (`.co.uk`, `.com.au`, `.github.io` and similar require the PSL to split correctly). Convert IDN / Unicode input to its punycode (`xn--`) form and note both. If the input is ambiguous (could map to more than one registrable domain), ask which one before proceeding.

## Evidence discipline

This is the core rule of the skill. Classify every material finding as Fact, Inference, or Unknown. Group related facts where doing so remains unambiguous.

- **Fact:** returned directly by a tool or read from a page (for example, "WHOIS status is clientTransferProhibited", "MX records are present").
- **Inference:** an interpretation supported by one or more facts but not confirmed. Always phrase with "may indicate", "is consistent with", or "suggests", never as fact.
- **Unknown:** the available data cannot decide the question. Say so explicitly.

Never convert absence of data into a negative finding. "No trademark hits returned" is not "the mark is clear"; "no sale record found" is not "never sold"; "no A record" is not "abandoned". Every time-sensitive conclusion must carry the date it was observed.

For DNS, distinguish an explicitly returned empty record set from a record type the source does not support. In particular, if `dns` does not return a `CAA` field, report CAA as `Not Provided` or query an independent DNS source; never interpret the missing field as proof that no CAA record exists.

## Workflow

Run the queries independently. A single tool failing, timing out, returning nothing, or being unavailable must NOT stop the rest of the report; mark that section Unavailable and continue. If the user asked only about one aspect (for example, just DNS, or just backlinks), run that part and skip the rest: deliver only the section(s) that answer the question, plus their evidence limitations and sources, and do not emit the remaining sections of the full structure. The fixed output structure below applies in full only to a full-domain analysis; a narrow request returns the matching subset in the same format.

1. **Gather core data in parallel:**
   - `whois` on the registrable domain for registrar, key dates, and status codes.
   - `dns` on the hostname for A, AAAA, MX, NS, TXT, CNAME, and CAA when the actual response supports it. Otherwise mark CAA `Not Provided` or use an independent DNS source.
   - Threat check through the user's connected threat-check tool, if the user agreed to use it.
   - `backlink_summary` for rank, referring domains, and spam score, plus link-type distribution only when the source returns it.
   - `tld_check` for cross-TLD registration data.

2. **Cross-TLD investigation (conditional).** Use the rating the tool provides. If the tool gives no rating, report the raw count and the set of TLDs checked; do not label a count "high" on your own. If cross-TLD registration is notable, `whois` the common variants (.com/.net/.org) and record the registrars. Report the pattern as a fact; treat its meaning as inference (for example, "several variants use the same registrar, which may indicate they were registered together, but does not establish it; a popular registrar or registrar migrations can produce the same pattern"). Do not attribute the variants to any person or organization. If you fetch the variants to see whether they resolve to the same site, each variant is a distinct domain: apply the fetch rule to each variant, and never carry the target domain's threat-check result over to a variant. For any variant the threat check flags, record the flag, skip the fetch, and report only its non-fetch evidence (WHOIS, DNS).

3. **Website status.** Apply the fetch rule. If the threat check has flagged the domain as malicious, phishing, or malware-hosting, do not fetch it: record the flag and its threat types, mark Website status as not fetched because of the flag, and continue the rest of the analysis (WHOIS, DNS, backlinks, cross-TLD, public records) without waiting for the user. The user may be investigating the domain precisely because it is suspicious. A flag is a detection signal, not proof; it can be a false positive or stale, and a clean result does not prove safety. If the check is clean, or there is no check and the user agrees to an unverified fetch, fetch the domain to determine current use: active business, parked page, for-sale landing, or no content. Distinguish and record HTTP redirects (and their target), TLS errors, login walls, and anti-bot / captcha pages, rather than treating them as "no content". If the user declines an unverified fetch, mark Website status Unavailable.

4. **Market and legal context.** Search the web for context that technical data cannot show: recent sale history, related news or brand events, and legal disputes (UDRP, trademark conflicts). Cite a source for each external claim, with the observation date. Prefer authoritative sources by type: UDRP from official decision databases (WIPO, Forum); trademarks from official trademark registries; sale prices from verifiable sale databases or marketplace announcements. A search-result snippet is not final evidence; open the original page to confirm. Historical pricing MUST distinguish confirmed public sale records from current listing / asking prices; do not merge them. Report a dispute by case number, date, and outcome, without naming individual parties. For a UDRP decision, add a one-sentence summary of what kind of dispute it was and the panel's finding on each of the three UDRP elements (identical or confusingly similar to the complainant's mark; the respondent's rights or legitimate interests; registration and use in bad faith), as the decision states them. Any trademark or UDRP observation is a search result, not a legal opinion.

5. **Synthesize the report** using the fixed structure below, so output is consistent across runs.

## Output structure

This is the structure for a full-domain analysis. For a narrow request (per the workflow note above), return only the sections that answer it, keeping this format and each included section's evidence limitations and sources.

1. **Executive summary**: the few findings that matter most, each with a confidence level:
   - **High:** directly reported by an authoritative source or tool.
   - **Medium:** supported by multiple consistent signals.
   - **Low:** based on a single indirect or incomplete signal.
2. **Registration**: registrar, creation/expiry dates, status codes.
3. **DNS and email**: A/AAAA, NS, MX, TXT, CNAME, CAA as found; note email configuration presence as a fact, not proof of active use.
4. **Website status**: live content, parked, redirect (with target), TLS/login/anti-bot state.
5. **Threat check**: the result from the user's connected threat-check tool, or Unavailable. If the domain is flagged, this is the leading finding: give the threat types, state that the domain was not fetched and that registration, acquisition, or use is not advised while the flag stands, and that the flag is a detection signal, not proof.
6. **Backlinks and SEO**: rank, referring domains, spam risk, and link-type distribution only when the source provides it (otherwise mark it Not Provided).
7. **Cross-TLD footprint**: counts, TLDs checked, registrar pattern (fact vs inference).
8. **Market and legal context**: sales history (public sale vs asking price), news, disputes reported as workflow step 4 specifies, each with source and date.
9. **Evidence gaps and limitations**: every section marked Unavailable, and what could not be determined.
10. **Sources and observation timestamps**: external sources and the dates each fact was observed.

Do not make buy / don't-buy judgments, with one exception: a domain the threat check flags is reported as not advised for registration, acquisition, or use. Otherwise present evidence and let the user decide.

## Next steps

If the user's goal is not already known, ask one concise follow-up question. Otherwise, tailor next steps directly to the stated goal:

- Wants market pricing: a listing-based comparative market analysis is available, positioning the domain against current for-sale comparables rather than estimating a sale price (see domain-cma-valuation).
- Domain is listed for sale: state which marketplace it is on so the user can verify it directly.
- Wants alternatives: a naming consultation with a taken-target mode is available (see domain-name-advisor).
- Wants to track changes: a monitoring capability can watch the domain.

## Key principles

- Classify every material finding as fact, inference, or unknown; absence of a record is not proof of absence.
- Each query is independent: a failure marks its section Unavailable and does not stop the report.
- A threat flag skips the fetch, not the analysis, and leads the report as a detection signal, not proof.
- Every time-sensitive claim carries its observation date; every external claim carries its source.
- When a domain is for sale, name the marketplace so the user can verify it; do not add referral or affiliate links.

View saved version →

---
name: domain-cma-valuation
description: Apply the substitution principle to position a compound or keyword-plus-modifier domain within the current asking-price market. Build a Comparative Market Analysis from verified, currently for-sale domains that are credible substitutes in the same value-bearing keyword market, then adjust for TLD, keyword position, length, modifier quality, and linguistic coherence. Use when a user asks what such a domain is worth, wants a competitive listing-positioning range, or needs current replacement-market context for buying or selling. Do not use historical sale prices to set or calibrate the range. Treat exact single-keyword domains, pure short domains, coined names without a shared keyword market, fixed-target buyer situations, and domains with active operating websites as out of scope. Do not use for technical analysis (use domain-analyze) or availability checks (use available).
---

# Domain Substitution-Market CMA

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

**What this does:** identifies the part of a domain that carries its independent market value, builds a pool of credible substitutes from domains currently offered for sale in that same keyword market, and positions the target against what a buyer can purchase now. It estimates current competitive listing position and replacement cost, not a completed-sale price, official appraisal, or investment outcome.

The core model is the **principle of substitution**: a buyer with a flexible naming goal normally has little reason to pay materially more for the target than for a currently purchasable domain that serves the same naming purpose and is equal or better on the relevant attributes. The analysis therefore starts with current alternatives, not sparse historical transactions. A buyer who must obtain the exact string for a fixed identity, brand, acronym, or strategic reason is not acting in a substitutable market, so this model does not estimate that buyer-specific value.

The real-estate CMA analogy is deliberate: the value-bearing keyword is the neighborhood; TLD, keyword position, length, modifier quality, pronunciation, and semantic coherence are property features. Two domains that share a construction pattern but not the value-bearing keyword are not in the same neighborhood.

Example: for `openrt.com`, if `rt` is the intended value-bearing keyword and `open` is the modifier, compare current `rt*.com` and `*rt.com` listings in which `rt` is a real token. Do not use `opengt.com` merely because both names follow `open` + two letters. A historical price for `opengt.com` says nothing reliable about the current `rt` keyword market.

## Scope

Use this model for compound words, industry word + modifier names, acronym/keyword + modifier names, and prefix/suffix combinations where a primary value-bearing keyword and a credible current substitute market can be identified.

Treat these as out of scope:

- An exact single-keyword domain, where the value rests on the unmodified word + TLD rather than a substitutable modifier relationship.
- A pure short domain (for example a bare 2L / 3L, short numeric string, or short acronym) whose value rests mainly on scarcity, character quality, or many possible buyer-specific meanings rather than one defensible keyword market. A short keyword + modifier construction remains in scope when its value center and substitutes are clear.
- A coined or invented name without an independently shared keyword market.
- A fixed-target situation in which the relevant buyer must obtain the exact string and would not accept a substitute; the model cannot estimate that buyer-specific premium.
- A domain with an active operating website, where business assets, traffic, revenue, customers, and goodwill may materially affect value.
- A domain whose apparent value depends mainly on an existing brand, trademark owner, or competitor.
- A name whose value-bearing keyword or credible substitute set cannot be identified well enough to form a defensible current market.

For an out-of-scope target, explain which condition failed and stop the CMA. For an active website, state that an asset-inclusive business valuation would require operating data not covered here. For an exact single-keyword, pure short, coined, fixed-target, or otherwise exceptional domain, provide only directly observed market evidence if the user asks; do not manufacture a substitution-based range.

## Data interfaces

DomainKits MCP supplies discovery evidence through the tools below; it is not the complete CMA engine. Host-provided browser or WebFetch access verifies the original marketplace pages. Equivalent providers are acceptable. Never assume that an MCP listing contains listing type, listing age, or price-change history when its actual payload does not return those fields. Mark unavailable fields `Not Provided` and continue only when the remaining evidence can still support the model.

- Current comparable for-sale listing leads, DomainKits: `market` / `aged` / `active`
- Cross-TLD registration breadth for the value-bearing keyword, DomainKits: `tld_check`
- Market-wide registration trends (what people are registering recently) as supporting context, DomainKits: `keywords_trends`; relevant only when the value-bearing keyword appears on a trend list
- URL threat check before fetching the target domain: DomainKits does not provide one. If the user has connected a threat-check tool, ask once whether to use it; if none is connected or the user declines, mark it Unavailable
- Web access or browser automation for verifying original marketplace listings
- Current foreign-exchange reference when prices must be normalized across currencies

**Fetch rule.** If the user has connected a threat-check tool, ask once whether to run it before fetching any domain's pages in this task, and never fetch a domain it flags. Without a check, tell the user the domain's safety is unverified and fetch only with their go-ahead. Fetch read-only: no form submissions, no credential input, no file downloads.

Optional follow-up capability, used only if the user asks: `monitor` to watch the target domain for WHOIS, DNS, or page changes.

## Core model

### 1. Identify the value-bearing keyword

Decompose the domain into:

- **Primary value-bearing keyword:** the token whose meaning, audience, industry use, or acronym market gives the name independent relevance.
- **Modifier:** a prefix, suffix, verb, descriptor, or other token that changes the presentation of the keyword.
- **TLD:** a separate pricing dimension, not part of the keyword.

Use the user's intended meaning when provided. Do not assume the first, last, longest, or dictionary token is automatically the value center. If two interpretations would create materially different comparable markets, ask one concise question before continuing.

For short acronyms and concatenated strings, exclude accidental substring matches. A domain contains the keyword only when the keyword is plausibly functioning as an independent token in that name.

Also establish the substitution frame: the target's intended naming purpose, which characteristics a normal buyer in that market must preserve, and whether the user has disclosed a non-substitutable need for the exact string. Do not confuse a user's interest in valuing one target with proof that every buyer must have that target.

### 2. Build the current substitute market

Use only active for-sale listings. Search the value-bearing keyword at both the start and end of the label, then inspect each result manually enough to confirm that it belongs to the same keyword market and could plausibly serve the same naming purpose.

Rank comparables by:

1. Same value-bearing keyword, same TLD, and same keyword position or grammatical role.
2. Same value-bearing keyword and same TLD, with a different but comparable position or modifier.
3. Same value-bearing keyword on another TLD, used only as secondary context and never mixed directly into the primary-TLD price range.

Exclude:

- Domains that share only length, prefix, suffix, word count, or construction pattern.
- Domains built around a different core keyword, even when their surface structure is identical.
- Accidental substring matches.
- Listings whose current status or asking price cannot be sourced.
- Obvious brand-dependent or trademark-dependent names.

Synonyms and adjacent concepts are not substitutes for the exact keyword market when the buyer's direction requires that keyword. Use them only as separately labeled secondary context when the exact-keyword pool is thin; never let them set the primary range. If the user's naming goal is explicitly flexible enough to accept a different keyword, show those names as a separate broader-alternatives layer rather than mixing them into the same-keyword CMA.

### 3. Position the target within current asks

Use the verified current asking-price distribution, not historical transactions. Show the full observed range, the central cluster, and any obvious outliers rather than averaging unlike assets together.

Identify the **closest substitute set** and the **equal-or-better substitution frontier**: the lowest currently verified asking prices among substitutes that are reasonably equal to or better than the target for the stated naming purpose. This frontier is a competitive replacement-price constraint, not a guaranteed sale price or a mechanical hard cap. A target positioned above a cheaper equal-or-better substitute requires a named, evidence-based superiority; otherwise the current substitute market does not support that premium.

Position the target relative to the comparables using:

- TLD, with the target TLD compared primarily against the same TLD.
- Keyword position and role.
- Length and word count.
- Modifier quality and commercial usefulness.
- Pronunciation, spelling, and semantic coherence.
- Cross-language or negative-meaning risk.
- Listing freshness and any visible price-reduction history.

Do not invent fixed percentage adjustments. Explain each relative premium or discount from named comparable differences.

`tld_check` and `keywords_trends` are supporting context only. They can describe keyword breadth or current registration activity, but they do not set the price range and must not be converted mechanically into a premium.

## Historical-price boundary

Historical sale prices do not enter the comparable pool, do not calibrate the asking-price range, and do not create an expected transaction range. A past sale occurred in a different market moment and may reflect a unique buyer, negotiation, use case, or information set.

If the user explicitly asks for historical sales, present them in a separate appendix as background only. State whether each historical item shares the same value-bearing keyword. Do not alter the current listing-positioning range because of it.

## Evidence discipline

- **Asking price is seller intent, not transaction proof.** Never describe the resulting range as a certain sale price or completed-market value.
- **Verify current status.** Check each retained comparable against its original marketplace listing when possible and record source and observation date.
- **Label fallback evidence.** If the original page is blocked, retain a current tool-reported listing only as `marketplace page not verified`; do not call it fully verified or count it toward the minimum verified-comparable rule.
- **Do not invent listing metadata.** Obtain listing type, listing age, and price-reduction history from the original marketplace or another named current source. If the page and tool do not provide a field, write `Not Provided`; do not infer it from the asking price, search snippet, or first observation in this report.
- **Deduplicate.** Count the same domain once even when it appears on several marketplaces; record differing asks rather than treating them as separate comparables.
- **Separate listing types.** Distinguish BIN, minimum offer, current auction bid, and lease-to-own. A monthly lease payment is not the total asking price, and a current bid is not a completed sale.
- **Normalize currency carefully.** Preserve original currency. If prices must be combined, convert with a current FX source and date. If FX data is unavailable, keep currencies separate and do not calculate a combined range.
- **Record listing dynamics when visible.** Capture listing age and price-reduction history; mark either Not Provided when unavailable.
- **Absence is not value evidence.** No comparable found means insufficient current market evidence, not low value.
- Classify findings as Fact, Inference, or Unknown. Cite source and observation date for every external price.

## Workflow

Use information already supplied by the user. Ask at most one question, and only when ambiguity about the value-bearing keyword or substitution frame would materially change the current substitute market.

1. **Check scope, substitutability, and safety.** Determine whether the target is a compositional name with a defensible substitute market, rather than an exact single-keyword, pure short, coined, fixed-target, brand-dependent, or asset-inclusive case. Apply the fetch rule to the target, and never fetch it if the threat check flags it as malicious, phishing, or malware-hosting. When a fetch is allowed, inspect the root domain to distinguish an active business from parking, a for-sale lander, login wall, TLS failure, or unreachable site. If the user declines an unverified fetch, mark the site check Unavailable and state that the active-website scope condition is unverified. Stop if the target is out of scope.

2. **Identify the value center and substitution frame.** Record the primary value-bearing keyword, modifier, TLD, intended meaning, naming purpose, characteristics that substitutes must preserve, and any ambiguity. Do not continue with an unresolved material ambiguity.

3. **Build the listing pool.** Query `market` filtered to for-sale listings, then use `aged` and `active` with the same for-sale filter as additional sources. Search the exact keyword at the start and end. Do not generate pattern-only substitutes.

4. **Verify and classify.** Verify original listings where possible, deduplicate, label listing type and verification status, normalize currency when possible, and assign each retained item to comparable tier 1, 2, or 3.

5. **Apply the sufficiency rule.** Use at least three current tier-1 or tier-2 listings whose current status and asking price were verified from the original marketplace or another named current source to produce a primary positioning range. MCP-only leads labeled `marketplace page not verified` may be shown as fallback evidence but do not satisfy this minimum. With fewer than three verified comparables, present the observed listings and state `Insufficient current comparable market`; do not manufacture a range. Tier-3 or synonym evidence cannot satisfy this minimum.

6. **Position the target.** Identify the closest substitutes and equal-or-better substitution frontier, then describe where the target belongs within the current same-keyword market and why. Produce a listing-positioning range only when the sufficiency rule is met. Never produce an expected transaction range.

7. **Report** using the fixed structure below. Never recommend whether the user should buy, sell, or accept an offer.

## Output structure

1. **Scope, value center, and substitution frame:** target domain, primary value-bearing keyword, modifier, TLD, intended meaning, naming purpose, characteristics a substitute must preserve, and any ambiguity resolved.
2. **Current substitute listings table:** domain, why it is a credible substitute, substitution strength and quality relative to the target, keyword match and position, modifier, TLD, comparable tier, listing type, asking price in original currency, normalized price and FX source/date when converted, verification status, marketplace, listing age, price-reduction history, source, and observation date.
3. **Excluded false comparables:** materially tempting exclusions and why they were rejected, especially pattern-only or different-keyword names.
4. **Current keyword-market asking distribution:** retained comparable count, full observed range, central cluster, outliers, and coverage limits.
5. **Closest substitutes and substitution frontier:** the closest currently purchasable alternatives, the lowest verified asks among equal-or-better substitutes, and the named differences that support or reject a premium for the target. State that this is a competitive replacement-price constraint, not a guaranteed transaction ceiling.
6. **Target listing-positioning range:** only when at least three tier-1 or tier-2 current listings exist; explain the target's relative position using named differences and the substitution frontier.
7. **Supporting keyword signals:** cross-TLD breadth and registration activity, clearly labeled as non-pricing context.
8. **Confidence and limitations:** verification gaps, thin market, stale listings, unavailable marketplaces, currency limitations, brand-risk boundary, and any buyer-specific value the substitution model cannot measure.
9. **Sources and observation dates:** one source trail for every retained asking price and supporting factual claim.
10. **Compliance statement:** use the fixed text below.

Compliance statement: "This is a substitution-based current listing analysis for reference only, not an official appraisal or investment advice. It positions the target against verified seller asking prices for currently purchasable domains in the same value-bearing keyword market. The substitution frontier is a competitive replacement-price constraint, not a guaranteed transaction ceiling. Asking prices are seller intent and do not prove that a domain can transact at those prices. Historical sale prices are not used to set or calibrate the range, and buyer-specific value for an exact target is outside this model."

## Key principles

- Apply the principle of substitution: position the target against what a flexible buyer can purchase now for the same naming purpose.
- The value-bearing keyword defines the substitute neighborhood; construction pattern alone never does.
- Price from current verified same-keyword for-sale listings, preferring same-TLD, same-role comparables; keep other TLDs and synonyms as labeled secondary context, and exclude pattern-only analogies and accidental substrings.
- Require named superiority before supporting a premium over a cheaper equal-or-better substitute.
- Apply the model only within Scope, and produce a range only when the sufficiency rule in workflow step 5 is met.
- Historical sales never set, calibrate, or constrain the range; asking prices support listing position, not an expected transaction price.
- Verify, deduplicate, label listing type, preserve provenance, and timestamp every price.
- Do not recommend buying, selling, or accepting an offer.

View saved version →

---
name: domain-generator
description: Generate modern brandable domains from a user-supplied keyword, concept, or specific taken domain. Treat the input as either a hard literal constraint or a creative seed, then explore abstract, evocative, artistic, sound-led, coined, blended, compound, and modifier-based directions before presenting a small shortlist verified as available at check time. Use when the user already knows the seed or direction and wants creative registrable names, including requests such as "use the word flow" or "getflow.com is taken; create variations". Do not use when requirements are still vague or no seed exists (use domain-name-advisor), when the user wants expired, deleted, aged, or other lifecycle alternatives (use domain-name-advisor in taken-target mode), or when they want trend-based ideas (use keyword-trend-hunter).
---

# Modern Creative Domain Generator

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

**What this does:** transforms a known keyword, concept, or taken target into a deliberately varied portfolio of modern brand names. It moves beyond mechanical keyword attachment by exploring semantic distance, metaphor, abstraction, sound, letterform, invented language, blends, compounds, and purposeful modifiers, then presents a small shortlist verified as available at check time.

Modern naming does not require every name to describe the product literally. A strong name may communicate a function, benefit, attitude, movement, image, emotional promise, or memorable sound. Abstractness is valid when it creates intentional openness and a coherent brand story; random obscurity is not. Concatenation remains a useful construction method, but it is one instrument rather than the default method.

**Data interfaces it needs.** DomainKits MCP supplies the availability lead and TLD pricing below; host-provided web access supplies the public collision check and the registrar's own pricing page. Equivalent providers are acceptable. Never infer availability from a missing field, request failure, or undocumented response shape; mark the capability `Unavailable` and continue.

- Availability check, DomainKits: `bulk_available`
- A TLD's standard registration and renewal price, DomainKits: `price`
- Premium status and a name's actual registration price: host web access to the registrar's own page
- Web access for a lightweight public-web check on obvious brand collisions

## Evidence discipline

- **Availability is a point-in-time signal.** Only a successful per-domain result that explicitly reports the domain as available qualifies as verified. Any other status, a missing domain row, a failed request, or an unrecognized response does not qualify. Every verified domain must carry the observation timestamp. Describe it as "available at check time", never as guaranteed registrable until registration completes.
- **Respect the creative constraint.** Treat the full input as the source string. Identify possible roots and modifiers as interpretations, not facts (for example, `getflow` may be root `flow` with modifier `get`, or the whole brand `getflow`). Never silently discard a user-required word. When the input is only a conceptual seed, candidates may move beyond the literal string while preserving an explainable connection.
- **Creative meaning is interpretation.** Present metaphors, emotional readings, sound symbolism, and visual impressions as intended creative rationale, not universal fact. Deliberate ambiguity is allowed; accidental incoherence is not.
- **Price is data, not a guarantee.** The price fields are listed under Output format. Premium status comes only from the registrar's own page; when it was not checked, mark it Not Provided and label the price as the TLD's standard price.
- **Availability and a lightweight public-web check do not constitute trademark clearance. Do not claim that a candidate is legally safe to use.**

## Input modes

Determine which input mode applies before generating:

- **Literal constraint:** the exact word, fragment, or spelling must appear. Preserve it and create around it.
- **Conceptual seed:** the keyword supplies meaning or direction but need not appear literally. Permit semantic and phonetic transformation.
- **Taken-target seed:** preserve what the user values in the unavailable target (keyword, pattern, sound, rhythm, image, or brevity), not necessarily every character. If the user wants lifecycle inventory rather than creative variants, use domain-name-advisor.

If the user's wording makes the mode clear, proceed. Ask one concise question only when literal preservation versus creative transformation would materially change the result.

## Creative system

### Semantic distance

Generate across several distances from the source rather than staying at one literal level:

1. **Refined literal:** clean compounds, purposeful modifiers, phrase compression, or TLD integration.
2. **Suggestive:** names expressing the benefit, behavior, outcome, or attitude associated with the seed.
3. **Evocative:** sensory images, movement, materials, nature, spatial ideas, contrast, or metaphor.
4. **Symbolic / abstract:** a compact symbol, invented form, or open-ended idea with a coherent connection to the intended brand character.

When the user imposes a literal constraint, keep the required string while varying the surrounding concept. Otherwise include meaningful non-literal directions; do not make the shortlist a collection of the same keyword with interchangeable prefixes.

### Construction methods

Use construction methods selectively and explain the choice:

- Compounds, including unexpected but coherent pairings.
- Prefix / suffix or word + modifier constructions.
- Portmanteaus and blends with clean morpheme boundaries.
- Clipping, phrase compression, and controlled respelling.
- Coined words built from recognizable semantic or phonetic fragments.
- Sound-first names designed around rhythm, energy, softness, speed, precision, or warmth.
- A semantically integrated TLD or domain hack only when it strengthens the idea and the user accepts the extension and renewal economics.

Do not manufacture availability through random vowel deletion, arbitrary `x` / `z` insertion, doubled letters, or hard-to-defend misspellings. Avoid default startup formulas such as `get-`, `try-`, `use-`, `my-`, `go-`, `-ly`, or `-ify` unless that construction genuinely strengthens this specific name. Do not imitate a famous brand's distinctive naming pattern.

### Sound and visual form

Judge a candidate as both spoken language and a visual mark:

- Syllable count, stress, rhythm, consonant energy, vowel color, and ease of repetition.
- Radio test: whether a listener can repeat and plausibly spell it after hearing it.
- Lowercase readability, letter balance, repeated shapes, and confusing character sequences.
- Memorability without requiring a long explanation.

## Workflow

Use the keyword, TLD, audience, industry, and style the user has already supplied. If a preference is missing, default to `.com` and a balanced modern portfolio of short, pronounceable names, and disclose those defaults. Do not force a long naming interview when the seed is clear.

1. **Set the creative frame.** Determine the input mode. Record the source string, plausible roots or valued features, intended audience or use, TLD constraint, and two or three desired brand qualities. Infer and disclose reasonable qualities when the context supports them; ask only when the literal-versus-conceptual distinction is materially ambiguous. If the user is still choosing the underlying direction, use domain-name-advisor.

2. **Build a creative palette.** Expand the seed into its literal meanings, functions, benefits, emotional promises, verbs, sensory images, metaphors, symbols, phonetic fragments, and useful contrasts. Record what must be preserved and what may transform. This palette is internal working material, not the final answer.

3. **Generate internally (do not show yet).** Generate 40 to 60 candidates across at least four distinct naming territories from the Creative system. Unless the user explicitly requests literal names, ensure that a meaningful share of the pool is evocative, abstract, coined, or sound-led. Include compounds and blends where they are strong, but do not let one construction template dominate. Do not treat `.ai`, `.io`, or `.app` as automatic substitutes; weigh audience, industry, regional meaning, semantic fit, and renewal cost.

4. **Filter intrinsic quality before availability.** Reduce the pool to the strongest 15 to 20:
   - A coherent one-sentence creative rationale; reject accidental nonsense, not intentional abstraction.
   - Distinctiveness from generic category language and tired startup formulas.
   - Easy enough to say, repeat, and spell for the intended audience.
   - Sound and visual form that support the intended brand qualities.
   - A defensible connection to the literal constraint, conceptual seed, or valued feature of the taken target.
   - Avoid unnecessary hyphens and digits.
   - Avoid unintended negative or misleading associations in the target languages and regions.
   - Scan concatenations for sensitive, adult, discriminatory, or offensive words formed accidentally.
   - Avoid names that clearly match an existing company or brand (lightweight public-web check).
   - Fit the intended audience and brand character; do not require an abstract name to describe the industry literally. For regulated industries such as medical or finance, flag suggestive or misleading wording rather than blanket-excluding every imaginative term.
   - Availability alone does not make a name worth recommending.

5. **Verify and curate.** Run `bulk_available` on the filtered candidates. Retain in the verified shortlist only candidates that meet the availability rule in Evidence discipline. From the explicitly available candidates, present only the 5 to 10 strongest. Preserve creative diversity in the shortlist rather than returning several versions of the same formula. If availability removes all strong non-literal directions, generate fresh candidates instead of filling the list with weak literal leftovers, within the verification budget below.

   **Verification budget.** Verify each round's candidates in one `bulk_available` call where the tool allows. Allow at most two more generation-and-verification rounds after the first, and stop earlier on a quota or rate-limit message. If fewer than five candidates qualify when the budget or quota runs out, present those that do, say why generation stopped (budget, quota, or no strong candidates left), and offer to continue later or in a different direction.

6. **Iterate by territory.** On feedback, generate fresh names within the preferred semantic distance, image, sound, or construction method. Do not merely swap prefixes. Use domain-name-advisor in taken-target mode if the user wants deleted, expired, aged, or other acquisition-path options.

## Output format

Present each shortlisted candidate with:

- **Domain**: the candidate.
- **Naming territory and semantic distance**: refined literal, suggestive, evocative, or symbolic / abstract.
- **Formation**: compound, modifier, blend, clipping, controlled respelling, coined, sound-led, or integrated TLD.
- **Creative concept**: the intended image, feeling, metaphor, attitude, or brand story, explicitly labeled as creative rationale.
- **Connection to the seed**: what literal constraint, meaning, sound, pattern, or valued feature it preserves.
- **Why it works**: memorability, pronunciation, spelling, rhythm, visual form, audience fit, and distinctiveness.
- **Availability at check time**: the per-domain `bulk_available` result that meets the availability rule, with observation timestamp.
- **Standard / premium status**: as the price rule in Evidence discipline defines it.
- **Registration and renewal price**: first-year and renewal price where available, with currency.
- **Provider and observation date**: the source of the price and when it was checked.
- **Language / brand caveat**: any cross-language meaning issue or possible brand collision noted.

If the availability tool fails or returns inconclusive, missing, or unrecognized results, you may offer the affected creative candidates only in a separate group labeled "Availability not verified", with the returned status or error. Never mix them into the verified shortlist.

## Key principles

- Treat the input as a hard literal constraint only when the user requires it; otherwise it is a creative seed. Roots, modifiers, metaphors, and sound readings are interpretations, not facts.
- Naming may be literal, suggestive, evocative, symbolic, or abstract; intentional openness is valid, accidental incoherence is not. Avoid template-driven cliches and availability-driven distortion.
- Generate many internally, filter hard, and present a small, creatively diverse verified shortlist within the verification budget.
- Label availability only as Evidence discipline defines it; inconclusive results stay in the separate unverified group.
- Weigh the TLD by audience, region, meaning, and renewal cost rather than defaulting to `.ai`, `.io`, or `.app`.
- Availability plus a public-web check is not trademark clearance.

View saved version →

---
name: domainkits
description: How to use the DomainKits tools for domain data (newly registered, expired, and deleted domains; WHOIS, DNS, reverse nameserver, registrar, EPP status, and IP lookups; availability, prices, and registration trends). Use when calling these tools, to pick the right tool for each lifecycle stage, combine results, and report them.
---

# DomainKits tool guide

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

DomainKits tools return domain data; the analysis is yours. Their data is fresher than your training knowledge, so for anything recent, go by the tool result.

Each tool's description and input schema define its data, parameters, and accepted values. Follow them as written, and do not carry one tool's parameter values over to another.

This skill covers tool usage only. The plugin's workflow skills (brand-protection, domain-analyze, domain-cma-valuation, domain-generator, domain-name-advisor, keyword-intel, keyword-trend-hunter, domain-market-beat) load on matching tasks.

Before a multi-tool sequence the user did not ask for, confirm the goal with the user. Tool calls count against their quota.

## Pick the tool by lifecycle stage

| Stage | Tools | What they find |
|---|---|---|
| Newly registered | `nrds` | Recent registrations by keyword or TLD, with filters |
| Registered | `active`, `aged`, `market` | Live registered domains. `aged` for long registration histories, `market` for names with marketplace listing data |
| Expired | `expired` | Domains in the deletion cycle, not yet open for registration |
| Deleted | `deleted` | Domains deleted after expiring, as of the latest data update |
| Changes | `domain_changes` | Recent registration and status changes to premium names |
| Unregistered | `unregistered_short_domains` | Short names unregistered as of the latest data update |

## Look up one domain

- `whois`: registration data. `epp_status` explains the status codes it returns.
- `dns`: DNS records.
- `ip_lookup`: network operator and approximate location of an IP or domain.
- `registrar`: a registrar's accreditation and parent company.
- `available`: whether one domain can be registered, and its price. `bulk_available`: the same question for a list of domains.
- `tld_check`: one name across TLDs, with per-TLD status. `bulk_tld`: for up to 50 names, how many TLDs each is registered in (counts only).
- `price`: registration and renewal prices by TLD. `market_price`: aftermarket listing price.
- `backlink_summary`: backlink profile. `keyword_data`: keyword search data.
- `keywords_trends`: what people are registering recently, as keyword lists. `tld_trends`, `tld_rank`: registration trends by TLD.

## Connect results when the user asks

- Infrastructure behind a domain: nameservers from `whois` or `dns`, then `ns_reverse` for other domains on those nameservers. `ip_lookup` adds the network operator.
- Lookalikes of a brand: `typosquat` for registered variants of a domain; `nrds` for new registrations containing the brand keyword.
- Current state of an `expired` result: `whois`.
- Registrability of a `deleted` or `unregistered_short_domains` result: `available`.
- Whether a domain is flagged as unsafe: DomainKits has no threat check. Use a URL threat-check tool the user has connected, or tell the user this check is unavailable.

## Report results

- For paged results, report the total separately from the number of results reviewed, and say how many pages were checked. Fetch more pages only when the user wants them.
- A tool's own message about a result, such as no records found, is part of the answer. Pass it on rather than treating it as a failure.
- On a limit or plan message, do not retry the same call. Tell the user what was limited. Plans and limits: https://domainkits.com/mcp

## Account tools

- `usage`: the user's current tier and remaining quota.
- `preferences`, `monitor`, `strategy`: stored on the user's DomainKits account. Create, change, or delete them only with the user's explicit consent.

View saved version →

---
name: domain-market-beat
description: Produce a time-bounded domain-market news briefing with source tiers, event types, and explicit inference limits, covering notable sales, registration trends, and recent domain movements. Use when a user wants to know what is happening in the domain market now. This is a briefing, not investment advice.
---

# Domain Market Briefing

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

**What this does:** produces 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.

**Data interfaces it needs.** DomainKits MCP supplies part of the structured evidence through the tools below; host-provided web search and WebFetch supply current news, original announcements, and sale verification. Equivalent providers are acceptable. Never assume a field is present when the actual payload omits it; mark it `Not Provided` or the capability `Unavailable` and continue. Query sources fresh on every run; do not rely on model memory for current events.

- Keyword registration trends (hot and emerging), DomainKits: `keywords_trends`
- Recent premium-domain changes, DomainKits: `domain_changes`
- Registration status and WHOIS, for validating movements, DomainKits: `whois`
- DNS resolution / nameserver validation, DomainKits: `dns`
- Web access for sales, news, and market events

Optional follow-up capabilities (used only when the user chooses to go deeper, not required for the briefing): `nrds`, `market`, `deleted`, `expired`.

## Time scope

- Follow the user's requested window when given.
- Otherwise default to the last 7 days, with recent movements broken out separately. Default recent movements to the last 24 hours when the tool supports that window; otherwise state the exact coverage the tool returns and do not imply it covers the full briefing window.
- Build all search queries from the actual current date and the requested window. Never hard-code a calendar year.
- Header every briefing with the cutoff time, the timezone, and the time the queries were run.
- Distinguish the event date (when the sale, transfer, or change happened) from the article publication date. Do not present an old sale re-published this week as a new sale.

## Evidence discipline

- **Source tier and verification status are two separate fields.** Source tier measures how authoritative the source is; verification status measures the state of the event (completed / reported / pending / unverified). A high-tier source does not by itself make a sale a verified completed sale, an official marketplace announcement may still describe a pending or reported transaction, not a finalized, paid-and-transferred one. Record both fields independently.
- **Classify every sale by type.** Distinguish verified completed sale, publicly reported sale, auction result, current bid, asking / listing price, and unverified claim. Never report a listing price or a current auction bid as a completed sale.
- **Independent sources only.** The same story republished across several sites is one source, not several. Count independent reporting, not copies.
- **Source tiers** (lead conclusions with higher tiers):
  1. Official announcements from a registry, ICANN, a company, or a marketplace, including a company's or marketplace's verified official social account.
  2. Verifiable sales databases and reliable industry press.
  3. Other news reporting.
  4. Anonymous, unofficial, or otherwise unverifiable sources (including unverified social posts and forum tips) go in a separate Unverified section and do not feed the main conclusions by default. An official verified account is Tier 1, not Tier 4, even though it posts on social media.
- **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. State this.
- **Cause discipline.** For any spike, separate Confirmed cause (an official source explicitly links it), Plausible context (correlated in time but causation unproven), and Unknown (no reliable explanation). Do not read related news as the cause by default.
- **Low-base caution.** A move from 2 to 10 is +400% but may not be a meaningful trend. Always show absolute numbers alongside percentages.
- **Registration signals are not end-user demand.** Trend counts and cross-TLD registration breadth can reflect speculation, promotions, bulk registration, or defensive registration; do not equate them with end-user demand.

## Movement discipline

Registration and DNS changes are weaker evidence than they look. Do not over-infer:

- A registrar transfer is not a sale or a change of ownership.
- A nameserver change is not a site launch or a sale.
- A passed expiry date is not imminent deletion.
- Redemption, auction, and pending-delete are distinct stages; name the stage.

Validate by the right source: registrar, expiry, and lifecycle status with `whois`; nameserver and DNS state with `dns`. Ownership change usually cannot be confirmed from either one alone. If the validating capability is unavailable, report only the observed technical change, not an inferred transaction or deletion.

## Workflow

1. **Set scope.** Establish the window (default last 7 days) and stamp the cutoff time, timezone, and run time. Build queries from the current date.

2. **Gather, fresh, from multiple sources.**
   - Web search for notable sales, industry news, and market events within the window.
   - `keywords_trends` (hot) for high-volume keywords and weekly movement.
   - `keywords_trends` (emerging) for recent spikes.
   - `domain_changes` for recent premium-domain transfers, expirations, and nameserver changes.

3. **Analyze with figures, not adjectives.**
   - For trend keywords, report current value, prior value, absolute change, percentage change, the baseline window, the sample size, and any rating the tool provides. Report each field only when the source provides it; otherwise mark it Not Provided, and never estimate or reconstruct a missing sample size or rating. When the prior (baseline) value is zero, write the percentage change as Not Meaningful rather than an infinite or undefined percentage; a fall to zero is a -100% change. If the tool gives no significance measure, do not call a move "significant"; call it the "largest observed change".
   - For each spike, assign Confirmed cause / Plausible context / Unknown, and watch for low-base effects.
   - For sales, classify each by sale type, and record source tier and verification status as two separate fields plus event and publication dates. Keep current bids and listing prices out of the sales set; route them to the active market offers table.
   - For movements, name the lifecycle stage and validate by the right source: registrar, expiry, and lifecycle status with `whois`; nameserver and DNS state with `dns`. When a movement from `domain_changes` is a nameserver change, confirm the current NS / DNS state with `dns` rather than inferring a launch or sale. If the validating source is unavailable, report only the observed change.

4. **Present** using the output structure below, leading with facts and higher-tier sources.

## Output structure

1. **Scope, cutoff time and timezone**: the window, the cutoff, the timezone, and when queries ran.
2. **Top headlines by source tier**: highest-tier, in-window items, each labeled with its verification status.
3. **Notable sales table**: completed and reported sale events only; see columns below.
4. **Active market offers table**: current bids, asking / listing prices, and open auctions; see columns below. These are offers, not sales, and never appear in the sales table.
5. **Registration trend table**: current, prior, absolute change, percentage change, baseline window, sample size, tool rating.
6. **Recent domain movements**: transfers, expirations, nameserver changes, each with its lifecycle stage and validation.
7. **Confirmed causes / plausible context / unknowns**: the split for each notable trend or spike.
8. **Data gaps and coverage limitations**: Unavailable sources, disclosure bias, unverified items held aside.
9. **Sources with event and publication dates**: per item, with source tier.
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."

Notable sales table columns (completed and reported sale events only): Domain, Sale type (verified completed sale / publicly reported sale / finalized auction result), Price and currency, Venue, Event date, Publication date, Source, Source tier (1-4), Verification status (completed / reported / pending).

Active market offers table columns: Domain, Offer type (current auction bid / asking or listing price / minimum offer / lease-to-own), Price and currency, Venue, Observation date, Source, Source tier (1-4). Never promote a row here into the sales table without completed-sale evidence.

## Next steps

Let the user choose whether to go deeper. Optional follow-ups: for an emerging keyword, use `nrds` to inspect aggregate registration patterns, `deleted` for dropped candidates that still require availability verification, and `expired` for expiring / backorder inventory. After a notable sale, use `nrds` to look for a registration wave, and `market` only to inspect related for-sale inventory (a rise in for-sale listings is not proof a sale triggered a registration wave). For a notable expiration, track its status with the monitoring tool. Report domains and events only; do not look up or report personal details of the people behind them.

## Key principles

- Anchor every briefing to an explicit window, cutoff time, and timezone; query fresh from the current date, never from memory.
- Classify every sale by type, and keep offers out of the sales table.
- Record source tier and verification status as separate fields; lead with higher tiers and keep unverified items apart.
- Report trend changes as figures; do not call a move significant unless the tool measures it.
- Separate confirmed causes, plausible context, and unknowns; registration signals are not end-user demand.
- Do not over-infer movements; validate them with the right source or report only the observed change.
- Say why a domain is notable; do not call it high-value without valuation evidence.

View saved version →

---
name: domain-name-advisor
description: Run a naming and acquisition-path consultation and present a small verified shortlist in either of two modes. Project mode turns vague or open-ended requirements into a generator-ready brief, delegates creative generation to domain-generator, and adds lifecycle inventory when appropriate. Taken-target mode extracts what the user values in an unavailable target, delegates creative variants to domain-generator, and searches dropped, expiring, for-sale, or brokered alternatives. Use when a user needs naming direction or recommendations across acquisition paths. Do not use for a simple availability check (use available / bulk_available), creative variations from an already-defined seed with no lifecycle comparison (use domain-generator), or analysis of a domain itself (use domain-analyze).
---

# Domain Name Advisor

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

**What this does:** consults on naming and presents a small verified shortlist, in one of two modes:

- **Project mode** (no target yet): briefly diagnose needs, prepare a generator-ready project brief, delegate all creative candidate work to domain-generator, and add lifecycle options when appropriate.
- **Taken-target mode** (a specific target is already taken): confirm the target is actually unavailable, extract what the user values in it, delegate all creative variant work to domain-generator, and search relevant lifecycle inventory without re-running an open naming consultation.

Both modes converge on the same cross-channel comparison and delivery. Most candidates are registrable names verified as available at check time; when the user accepts the relevant acquisition paths, the shortlist may also include already-registered candidates (expired / backorder or for-sale listings), which are verified by lifecycle and acquisition status, not as "available".

**Data interfaces it needs.** DomainKits MCP supplies part of the acquisition evidence through the tools below; host-provided web access supplies public-page verification. Equivalent providers are acceptable. Never assume an MCP result contains a field that is absent from its actual payload. Mark missing fields or capabilities `Unavailable` and continue.

- Availability check, DomainKits: `bulk_available`
- A TLD's standard registration and renewal price, DomainKits: `price`
- Premium status and a name's actual registration price: host web access to the registrar's own page
- Cross-TLD registration data (a lightweight crowding signal), DomainKits: `tld_check`
- Lifecycle inventory, DomainKits: `deleted`, `expired`, `market`, `aged` (how each is used is set out in workflow step 4)
- Web access for a lightweight public-web check on obvious brand collisions; for confirming a named broker before a brokered candidate is offered; and, optionally, for a past sale price only from a named verifiable sales record.

**Skill dependency:** use `domain-generator` as the sole creative-generation component. This advisor owns project or target diagnosis, generator handoff, lifecycle sourcing, cross-channel comparison, and final recommendation. Domain-generator owns the creative frame, semantic distances, naming territories, construction methods, intrinsic filtering, and creative iteration. Do not reproduce or maintain any of those rules here. Install domain-generator together with this skill. If it is not available, tell the user it is needed for creative candidates, and continue with the lifecycle channels only (deleted, expired, for-sale listings, brokered) without creating creative candidates here.

## Evidence discipline

- **Availability is point-in-time, and applies only to registrable candidates.** Only a successful per-domain `bulk_available` result that explicitly reports the domain as available qualifies as "available at check time"; attach an observation timestamp. Any other status, a missing domain row, a failed request, or an unrecognized response does not qualify. An already-registered candidate (expired / backorder, or a for-sale listing) is never labeled "available": verify and label it by its own status (current lifecycle and backorder / auction status for expired; current listing and asking price for a for-sale listing), each with an observation timestamp. Do not run `bulk_available` on an already-registered candidate; it measures registrability only.
- **Separate facts from judgment.** Source factual claims (availability, price, registration data). Present naming-quality judgments as reasoned creative assessments, not objective facts.
- **Price is data, and its shape depends on the acquisition path.** The fields for each path are listed under Output format. Premium status comes from the registrar's own page; otherwise it is Not Provided. Never carry standard-registration first-year / renewal fields onto an already-registered candidate, and never estimate a price.
- **A lightweight public-web check may catch obvious existing brands, but it is not trademark clearance. Never describe a candidate as legally safe.**

## Workflow

Use what the user has already told you (project, audience, style, TLD, or a specific target) and proceed. Ask at most one concise question at a time, and only when a missing detail would materially change the naming direction. Do not force a full diagnosis when the brief is already clear.

**Determine the mode first.** If the user has a specific taken target they want to replace, use the taken-target entry (step 1T). Otherwise use the project entry (steps 1 to 2). Both entries then hand creative work to domain-generator and use this advisor for lifecycle sourcing, comparison, and delivery.

1. **Brief (project mode).** Establish the essentials: project or industry, target audience, and what the name is for. If those are already given, move on. Ask a single question only when the answer changes direction (for example, tone, or whether the user is committed to `.com`).

1T. **Understand the target (taken-target mode).** Confirm the target is actually unavailable, unless a fresh conclusive result already exists in the conversation; do not search for alternatives to a domain that may still be registrable. An unclear, missing, failed, or unrecognized availability result is inconclusive, not proof that the target is taken. Extract plausible keyword and pattern interpretations (for example, `getflow.com` may be prefix + root) and record what the user values in it: literal word, meaning, length, sound, rhythm, image, construction, or brevity. Record TLD scope and willingness to backorder or buy a registered domain. Then go to step 3; domain-generator will turn this target brief into a creative frame.

2. **Prepare the generator handoff (project mode).** Turn the diagnosis into a compact brief containing the project or category, audience, use case, positioning or desired outcome, desired brand qualities, user-supplied words or concepts, literal constraints, TLD scope, language or regional constraints, and what may transform. Preserve any direction the user has chosen. Do not invent candidates, semantic distances, naming territories, construction methods, or filtering rules; domain-generator determines those from the brief.

3. **Use domain-generator for the creative channel.** In project mode, pass the generator-ready brief; its project or category, positioning, or user-supplied concept serves as the conceptual input. In taken-target mode, pass the full target plus the valued literal, semantic, phonetic, visual, and structural features. Domain-generator owns creative framing, generation, intrinsic filtering, brand-collision checks, initial availability verification, and creative rationale. Resume this workflow only after it returns its curated candidates. If domain-generator is not available, skip to step 4 with the lifecycle channels only. Do not create, extend, filter, or iterate creative candidates inside this skill. If the request is only for creative variants and no lifecycle comparison or advisory synthesis is needed, hand off directly to domain-generator and let it deliver the result.

4. **Gather lifecycle channels.** Scope every channel to what the user accepts. In taken-target mode, lifecycle sources are a primary channel; in project mode, use them when the registrable creative shortlist is thin or the user explicitly wants purchase / backorder options. Search the selected keyword or seed at both start and end where the source supports it:
   - `deleted` for dropped names that may be registrable; retain one as registrable only when its `bulk_available` result meets the availability rule in Evidence discipline.
   - `expired`, only when the user accepts backorder; verify lifecycle stage, backorder / auction status, and provider. Do not use `bulk_available` on a name that remains registered.
   - `market` for for-sale listings, with `aged` as a supplement for names with long registration histories, only when the user accepts purchasing a registered domain; verify the current marketplace listing, asking price, and listing type. A public listing is a purchase path, never brokered.
   - A brokered path only as a last resort for a registered candidate the user specifically wants, usually the original target, when no public listing exists. Confirm a named broker via the public web. Exclude the candidate if neither a listing nor a confirmable broker exists; never look up or use anyone's personal contact details.

5. **Verify, compare, and shortlist across channels.** Preserve domain-generator's naming territory, semantic distance, formation, creative concept, and seed connection. Re-run `bulk_available` only when a creative candidate's availability result is no longer fresh. Run the lightweight public-web collision check on any lifecycle candidate not already checked. Use `tld_check` only as a crowding / distribution signal, never as demand or quality. Compare all candidates on user fit, what they preserve from the brief or taken target, pronunciation, spelling, language risk, current acquisition status, cost basis, and acquisition complexity. Present up to 5 to 10 verified candidates, grouped from easiest to most involved: standard registration, backorderable, purchasable, then brokered. Availability alone does not make a candidate worth recommending.

6. **Iterate and follow up.** Route creative feedback back through domain-generator by semantic distance, image, sound, or formation; do not create a second prefix-swapping loop here. Adjust lifecycle channels when the user's acquisition tolerance changes. If the current best is already strong, do not force weaker options. Tailor next steps to the selected candidate: monitoring, deeper analysis with domain-analyze, or substitution-based current-market positioning with domain-cma-valuation.

## Output format

Present each shortlisted candidate with:

- **Domain**: the candidate.
- **Origin**: domain-generator creative candidate, deleted find, expired opportunity, for-sale listing, or brokered target; include the project territory or relation to the taken target.
- **Creative concept / formation** (for domain-generator candidates): preserve its naming territory, semantic distance, formation, and intended creative rationale.
- **Why it matches**: in project mode, its relation to the project's positioning and creative brief; in taken-target mode, what it preserves from the original target (literal word, meaning, pattern, length, sound, rhythm, image, or brevity).
- **Pronunciation / spelling notes**: readability and the radio test.
- **Current status, matched to the path**, with observation timestamp and labeled as Evidence discipline defines: "available at check time" for a registrable candidate; the current lifecycle and backorder / auction status for expired; the current listing status for a for-sale listing; the confirmed broker for brokered.
- **Acquisition path**: standard registration, backorder, purchase, or brokered.
- **Status / cost basis, matched to the acquisition path** (do not force first-year + renewal onto every path):
  - Standard registration: standard vs premium status, first-year price, and renewal price, with currency.
  - Backorder (expired): backorder fee and current bid where shown, with currency; note that securing the name is not guaranteed and renewal pricing applies only after it is caught.
  - For-sale purchase: the listing / asking price and listing type (BIN, minimum offer, current bid), with currency; an asking price is not a sale price.
  - Brokered: "Price unknown / negotiation required" (do not estimate), and the confirmed broker.
- **Historical sale price** (optional, include only when a named verifiable source provides it): a past confirmed sale from a named sales record or marketplace announcement, with that source and the sale date, kept as a separate field and never presented as the current asking or registration price. This skill has no dedicated sales-history data source, so omit this field when no such source is at hand; never estimate or infer a past price. For current market pricing, hand off to domain-cma-valuation, which positions a domain against current for-sale listings (it does not build a range from past sales); for a domain's sale history as part of due diligence, use domain-analyze.
- **Source and observation date**: where the price came from and when checked.
- **Language / brand caveats**: cross-language meaning issues or possible brand collisions.

## Key principles

- This advisor diagnoses, hands creative work to domain-generator, sources lifecycle inventory, compares acquisition paths, and delivers the shortlist; it does not generate creative candidates itself.
- Determine the mode first, diagnose briefly, and ask one question at a time, only when the answer changes direction.
- Label availability only as Evidence discipline defines it; verify an already-registered candidate by its own status.
- Scope every lifecycle channel to what the user accepts; the brokered and purchase paths are mutually exclusive.
- Match the cost basis to the acquisition path, and never estimate a price.
- Present a small verified shortlist grouped from easiest to most involved acquisition; availability alone does not make a candidate worth recommending.
- Source factual claims; naming-quality judgments are creative assessments, and a public-web check is not trademark clearance.

View saved version →

---
name: get-started
description: Introduce DomainKits when a user first connects it or asks what it can do, find out their goal, and route them to the matching workflow. Use for requests such as "what can DomainKits do" or "how do I start", or a first message with no clear task. Do not use when the request already names a domain, brand, keyword, or task; use the matching workflow skill instead.
---

# Get started with DomainKits

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

Use this skill only to orient a new user. Do not call any DomainKits tool until the user gives a task.

1. In two or three sentences, explain that DomainKits looks up domain data: newly registered, expiring, deleted, aged, and active domains; WHOIS, DNS, and reverse nameserver lookups; availability and TLD prices; typosquat variants; and keyword and TLD registration trends.
2. Offer these four starting points, each with one example request the user can send:
   - Brand protection: "Find domains registered in the last 10 days that contain "acme"."
   - Security: "Show the registrar and nameservers for example.com, and other domains on the same nameservers."
   - Naming: "Is brightharbor.com available? If not, suggest available alternatives."
   - Market research: "Which keywords are trending in new .com registrations?"
3. Ask which goal fits, or treat the user's next message as the task.
4. When the task is clear, follow the matching skill: brand-protection for lookalikes and typosquats, domain-analyze for one domain, domain-name-advisor or domain-generator for naming, keyword-trend-hunter or keyword-intel for keywords, domain-market-beat for market news, and the domainkits tool guide for single lookups.

Access: DomainKits works without signing in, with small daily limits. Monitors, saved preferences, and saved strategies need a DomainKits account. If a tool reports a limit, tell the user what was limited and do not retry the call. Describe plans only when the user asks, and point to https://domainkits.com/mcp.

View saved version →

---
name: keyword-intel
description: Map available evidence around a known keyword in the domain market, keeping search-audience, advertiser, new-registration open-market participation, supply and active offers, and completed transactions as distinct layers. Treat .com participation as necessary but not sufficient confirmation of open-market registration interest, and never merge the layers into one demand score or investment verdict. Use when a user wants a deep evidence picture for one known keyword. Not for analyzing a specific domain (use domain-analyze), browsing trends (use keyword-trend-hunter), or a market overview (use domain-market-beat).
---

# Keyword Domain-Market Evidence Map

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

**What this does:** assembles available evidence around one known keyword, applies a reproducible domain-sample rule, grades each layer by its coverage, and explains where the layers support, limit, or conflict with one another. It gives a layer-specific open-market participation reading but no merged demand score, invest / watch / avoid verdict, or instruction to act.

Different signals measure different things and must be named separately. They can corroborate each other, but none of them alone is "domain demand":

- **Search-audience signal**: search volume, an approximate provider-defined metric (often a trailing average). Report the provider's actual window, geography, language, network, and close-variant treatment.
- **Advertiser signal**: CPC and ad competition (these measure competition for search-ad slots, not domain value).
- **Open-market registration signal**: registration trends and newly registered domains, with `.com` as the necessary confirmation layer and participation breadth checked separately.
- **Domain-market supply and active offers**: current observed registered inventory, listings, bids, and asking prices.
- **Registrable / expiring inventory**: dropped names confirmed registrable and expiring names confirmed by lifecycle and provider.
- **Transaction evidence**: public sale records.

**Data interfaces it needs.** DomainKits MCP supplies part of the evidence through the tools below; it is not the complete analysis engine. Use equivalent sources when available and use host-provided web access for original records and public context. Never assume that an MCP response contains a field that its actual payload does not return. Mark missing fields or capabilities `Unavailable` and continue; do not abort the report because one source is missing.

- Search volume and ad metrics (search-audience and advertiser signals), DomainKits: `keyword_data`
- Market-wide keyword registration trends, that is, what people are registering recently, with source-computed aggregate metrics, DomainKits: `keywords_trends`. It is not a per-keyword query: its figures apply only when the keyword appears on a trend list
- Newly registered domain rows for name structure and coarse timing analysis, DomainKits: `nrds` (no registrar / provider field)
- Cross-TLD registration data, DomainKits: `tld_check`
- Registered and for-sale inventory, DomainKits: `active` / `market` / `aged`
- Registrable / expiring inventory, DomainKits: `deleted` / `expired`
- Availability confirmation, DomainKits: `bulk_available`
- Web access for original transaction records, authoritative sale reports, and context

## Input normalization

Before analyzing, establish the exact keyword; singular, plural, spacing, and hyphen treatment; language; intended meaning or industry; relevant geography for search and advertising data; TLD scope; and the reporting window. Many keywords carry several meanings (`apple`, `flow`, `java`). If the meaning would materially change the sample, ask one concise question; otherwise disclose the defaults.

**Brand-dominant boundary.** If the keyword corresponds mainly to one existing brand, switch to brand-risk / defensive-observation mode. Describe registration, supply, and transaction evidence only as brand-specific activity; do not call it broad keyword-market participation, present registrable or listed names as opportunities, or produce favorable acquisition framing. State that a public-web check is not trademark clearance or legal advice.

**Domain-sample matching rule.** Define and disclose the primary sample before pulling domain data:

- Include an exact label match or a hyphen-delimited component equal to the keyword.
- Include a concatenated label only when the keyword is a complete, unambiguous component and the remaining prefix or suffix is a recognizable word or purposeful modifier. For `art`, `arthub` and `getart` qualify; `cart`, `smart`, `chart`, and `artisan` do not.
- Exclude ambiguous segmentations from the primary sample. If useful, show them in a separately labeled ambiguous sample that does not enter counts, ratios, concentration, or conclusions.
- Decide whether plurals, spelling variants, and translated forms belong in separately labeled secondary samples. Never blend them silently with the exact-keyword primary sample.
- Apply the same manually reviewable rule across `nrds`, `active` / `market` / `aged`, `deleted` / `expired`, and transaction search. When a provider supplies an aggregate whose matching or close-variant rules cannot be reconstructed, report it using the provider's own semantics and do not combine it mathematically with the manually filtered domain sample.

## Evidence discipline

- Attach a source, provider, observation date, and relevant scope to every factual claim; mark every interpretation as inference. Report geography and language for search or advertiser data and wherever a source actually provides them. For registration, supply, and transaction layers, report TLD, feed, marketplace, or source coverage instead of inventing a geographic scope.
- **Coverage gate for ratios.** Before calculating a ratio from domain rows, deduplicate the sample and record its returned sample size, provider window or recency buckets, TLD or feed coverage, pagination completed, result cap, and whether the source claims completeness. Exhaust available pages when practical. If coverage or pagination is incomplete or unknown, label every derived ratio as an `observed-sample ratio`, do not generalize it to the full cohort, and lower the layer confidence. Treat aggregate `.com`, TLD, and registrar metrics from `keywords_trends` as provider-computed cohort metrics and retain their stated scope; do not recompute or silently combine them with a differently covered `nrds` sample. Do not report an open-market validation conclusion when missing coverage could materially change `.com` participation.
- **Currency on every price.** Every CPC, listing, and sale price carries its original currency, the data date, and the provider; if converted, note the exchange-rate source and conversion date. Do not combine prices in different currencies without conversion.
- **Search and advertiser metrics are not domain demand.** Volume is a search-audience signal; CPC and ad competition are advertiser signals. Report them as such; do not translate them into domain value. Search volume is a provider-defined metric with its own window and close-variant handling; report the provider's actual window, geography, language, network, and variant treatment. Do not sum singular, plural, spelling, or close-variant volumes when the provider may already aggregate them; report the possible overlap instead.
- **Time discipline.** Build search queries from the current date and the reporting window (default the last 12 months, with more recent events listed separately). Never hard-code a year. Distinguish event date from article publication date; an old sale re-reported is not a new sale.
- **`.com` is necessary, not sufficient.** In a sufficiently covered new-registration cohort, no `.com` participation means the registration layer is `not validated by the open domain market`. When coverage is insufficient, the result is `unresolved`, not negative. The presence of `.com` is only the first condition: interpret it together with the absolute `.com` count, `.com` share, registrar concentration, nameserver concentration, naming-pattern diversity, persistence across windows, low-base risk, single-TLD concentration, and sale-platform nameserver share. Registrar and nameserver concentration are participant-diversity proxies, not proof of participant count. Sale-platform nameserver share is the share of the cohort whose nameservers point at sale platforms, not a verified listing count; a high share suggests resale-led participation, which is an inference. Judge the layer against a balanced free market: many independent participants, with end use and resale both present. A cohort dominated by one registrar, nameserver, naming template, or by sale-platform nameservers is concentrated; a high sale-platform nameserver share together with nameserver concentration on the same platforms is one finding (inferred heavy speculation), not two. Do not describe non-`.com` activity as nonexistent; state only whether it is validated by the open domain market.
- **Supply is point-in-time and partial.** `deleted` is not confirmed registrable until re-checked with `bulk_available`; `expired` is not necessarily backorderable until lifecycle and provider are confirmed; `aged` filtered to for-sale listings is a current listing, not a sale; `active` returns a set that is not the total `.com` market unless the tool guarantees full coverage. Record status, source, and observation time.
- **Registration-velocity discipline.** A short-window comparison (for example 0 to 10 days vs 10 to 20 days) is affected by reporting lag, weekend/weekday effects, low base, promotions, incomplete coverage, and seasonality. Report current-window count, comparison-window count, absolute change, percentage change, data coverage, whether a low base is present, and a longer baseline if the tool supports one. When the comparison-window count is zero, the percentage change is undefined: report it as Not Meaningful (a rise from zero) and show the absolute counts, rather than an infinite or 0-based percentage. Without full data, report only observed acceleration or deceleration, not an "investment window".
- **Naming structure is not quality.** Hyphen share, numeric share, and length are structural features, not a "junk" verdict; acceptance of digits and hyphens varies by language, region, and industry. Report hyphen share, numeric share, median/average length, and prefix/suffix patterns from the domain rows, and label any quality reading as inference.
- **Define concentration the same way every run.** Report registrar / provider concentration only from the source-computed distribution returned by `keywords_trends`: the single largest registrar's share and the Top-3 cumulative share when each is provided, stated with the provider cohort size and scope. Do not reconstruct Top-3 from `nrds` or an incomplete registrar list, and do not report a bare "high / low concentration" without the underlying share. Apply the same disclosure discipline to single-TLD concentration (largest-suffix share) and nameserver concentration (largest-nameserver share). Mark missing concentration fields `Unavailable` rather than substituting another population.
- **Co-occurrence is not causation.** Co-occurring naming themes (for example the keyword plus `ai` or `cloud`) are observed associations. Do not call them causal drivers unless an authoritative source explicitly establishes the connection.
- **Transaction evidence levels.** A `verified completed sale` requires an original marketplace or auction result, or an authoritative transaction record, explicitly stating that the sale completed and at what price. A `publicly reported sale` is a named credible publication or sale database reporting a completed transaction when the original record is unavailable. A `finalized auction result` requires the venue or authoritative record to mark the auction closed and sold or won; an ended listing or last visible bid is insufficient. Search snippets, copied lists, and unsourced aggregations are leads only: open the underlying source before retaining an item. Current bids and asking prices belong only in active offers. Record price, currency, venue, event date, publication date, source, and level; deduplicate republications. If nothing qualifies, write "no public transaction records found in the searched sources", never "no transactions".
- **No verdict, and no single overall grade.** Characterize each layer separately and allow only layer-specific conclusions, including the open-market registration reading. Attach a provider rating only to the layer it measures. Present supporting signals, limiting or speculative signals, conflicts, and per-layer confidence without an overall score, invest / watch / avoid verdict, or instruction to act quickly.

## Workflow

Gather each layer independently; a failed source marks that layer Unavailable and does not stop the report.

1. **Scope and sample rule.** Normalize the keyword and window, apply the brand boundary, and define the primary, secondary, and ambiguous domain samples.

2. **Search-audience and advertiser signals.** `keyword_data` for volume (search-audience) and CPC / ad competition (advertiser), each labeled as its own signal with geography and time.

3. **Registration activity and open-market participation.** If the keyword appears on a `keywords_trends` list, use that trend cohort and its `.com`, TLD, registrar, nameserver, and sale-platform nameserver metrics when returned; if it does not, the cohort-level metrics are Unavailable and this layer rests on `nrds` rows. Use `nrds` only as a domain-row sample for naming-pattern diversity and the timing detail its day-level registration dates or recency buckets support. Do not merge the two populations unless their keyword semantics, provider window, data date, and coverage align. Report absolute `.com` count only when the trend source returns it; never reverse it from a rounded ratio. Apply the coverage gate to every derived `nrds` metric. Conclude this layer as `open-market participation supported`, `participation concentrated`, `not validated by the open domain market`, or `unresolved`, with the underlying figures, missing fields, and coverage. `.com` is necessary for support but never sufficient by itself; a missing material signal makes the result unresolved.

4. **Installed supply and active offers.** Use `tld_check` for the installed cross-TLD base and `active` / `market` / `aged` for observed registered and for-sale inventory. Deduplicate by normalized domain across those interfaces; count each domain once for supply and each distinct offer once, noting cross-venue price differences. Treat for-sale `aged` results, current bids, and asking prices as active offers, never transactions. State coverage rather than calling the result the total market.

5. **Registrable and expiring inventory.** Query `deleted` for dropped names and retain only those re-confirmed by `bulk_available`, with availability timestamp and registration pricing when returned. Query `expired` for expiring inventory and retain only names whose lifecycle, auction or backorder status, and provider are confirmed; do not use `bulk_available` on names that remain registered. Keep this inventory separate from installed supply and active offers. In brand-dominant mode, report aggregate risk context only and do not surface names as opportunities.

6. **Transaction evidence.** Search the web within the reporting window, open the underlying source, apply the transaction evidence levels, and record the required fields. Current bids and listings remain in step 4.

7. **Naming-pattern observations.** From the filtered `nrds` cohort, report structural shares and co-occurring themes as observations, not drivers.

8. **Report** using the compact output structure below.

## Output structure

1. **Scope, matching, and coverage:** keyword meaning, primary / secondary / ambiguous samples, TLD and reporting scope, provider matching semantics, returned sample sizes, pagination, result caps, and completeness limits. State whether brand-dominant mode applies.
2. **Search-audience and advertiser layers:** report volume separately from CPC and ad competition, with each provider's geography, language, network, metric window, and close-variant treatment.
3. **Registration activity and open-market participation:** trend and velocity figures; the `.com`, TLD, registrar, nameserver, pattern, persistence, low-base, and sale-platform nameserver signals; coverage qualification; and one layer conclusion (`supported`, `concentrated`, `not validated by the open domain market`, or `unresolved`).
4. **Installed supply and active offers:** observed registered / listed inventory, deduplicated counts, current bids and asking prices, listing type, currency, source, observation date, and coverage limits.
5. **Registrable and expiring inventory:** deleted names confirmed available at check time and expired names confirmed by lifecycle / auction / backorder status and provider, kept in separate groups. Omit candidate-level opportunity framing in brand-dominant mode.
6. **Public transaction evidence:** qualifying completed-sale items with evidence level, price, currency, venue, event and publication dates, and source; otherwise the fixed no-public-records statement.
7. **Naming-pattern observations:** structural shares and co-occurring themes, labeled as observations or inference rather than quality or causation.
8. **Layer synthesis:** supporting signals, limiting or speculative signals, conflicts, and confidence for each layer. Do not merge them into one demand score or recommendation.
9. **Evidence limits and source trail:** Unavailable capabilities, partial coverage, low-base or lag caveats, and source / provider / observation date / relevant scope for every factual layer.

## Next steps

Only if the user asks: a deep analysis of a specific domain (domain-analyze), monitoring, a saved strategy to re-run later, or analysis of a different keyword. Do not push the user toward acquisition or tell them to act.

## Key principles

- Keep the evidence layers distinct; never merge them into one demand figure, overall grade, or investment verdict.
- `.com` is necessary, not sufficient; judge registration participation against a balanced free market, and measure each signal the same way on every run.
- Fix the primary sample before pulling data, and apply the coverage gate before every ratio.
- Count each domain and each offer once; active offers are not transactions, and transaction evidence is verified at its source.
- Keep registrable and expiring inventory in its own section; `bulk_available` measures registrability only.
- In brand-dominant mode, report brand-specific activity and risk context only.
- Source, provider, observation date, and scope on every fact; inference on every interpretation; Unavailable on missing sources without aborting.

View saved version →

---
name: keyword-trend-hunter
description: Discover hot or emerging domain-registration keywords, validate each detected spike against an aligned new-registration cohort from the global open domain market using .com participation, concentration, persistence, and naming-structure signals, and optionally surface related lifecycle inventory without recommending acquisition. Use when a user wants to browse registration trends. For a full evidence analysis of one known keyword use keyword-intel; for a specific domain use domain-analyze; for market news use domain-market-beat.
---

# Keyword Registration Trend Hunter

**Instruction priority.** The user's instructions take precedence over guidelines provided in this skill. If explicit user instructions conflict with this skill's instructions, prioritize the user's instructions.

**What this does:** discovers keyword spikes, checks whether each spike is supported by broad participation in the same new-registration event cohort, and optionally surfaces related dropped, expiring, or listed inventory. It evaluates open-market registration participation, not aftermarket demand or investment merit.

**Data interfaces it needs.** DomainKits MCP supplies part of the evidence through the tools below; it is not the complete analysis engine. Use equivalent sources when available and use host-provided web access for public-page checks. Never assume a field exists merely because the workflow needs it. Mark an unavailable field or capability `Unavailable` and continue.

- Market-wide keyword registration trends, that is, what people are registering recently (hot, emerging, prefix), with source-computed aggregate metrics, DomainKits: `keywords_trends`. Read registrar Top-1 / Top-3 and nameserver concentration only from this trend source when returned.
- Newly registered domain rows for naming-pattern and coarse timing detail, DomainKits: `nrds`. It does not provide registrar / provider, so never calculate registrar concentration from it.
- Registrable / expiring / listed inventory, DomainKits: `deleted` / `expired` / `market` (`aged` as a supplement for names with long registration histories)
- Availability confirmation, DomainKits: `bulk_available`
- Web access for a lightweight brand-dominance and collision check before candidate inventory is surfaced

**Skill boundary:** this skill owns trend discovery, event-cohort integrity, preliminary open-market validation, and optional lifecycle inventory. Use `keyword-intel` for the full evidence picture of a selected keyword, including search-audience, advertiser, installed supply, active offers, and completed transactions. Do not reproduce those layers here.

## Open-market participation model

This skill evaluates trends within the global, general-purpose open domain market. Its core evidence is new-registration participation: `.com` participation is necessary confirmation of open-market interest, but it is never sufficient by itself. The full model requires broad, persistent, and structurally diverse participation rather than one concentrated registration pattern.

`.com` is the primary confirmation layer because it is the most established global namespace and aftermarket: registration cost and quality-name scarcity are higher, global recognition and end use are broader, secondary-market liquidity is stronger, and registering a `.com` means accepting more competition. It remains the largest single TLD by registration volume. A keyword trend with little or no `.com` participation is not considered validated by the open domain market, especially when registrations are concentrated in one low-cost TLD, one registrar, or a repeated naming pattern.

This model does not claim a non-.com ecosystem cannot be active. It means such activity has not been validated as a broad open-market domain trend. Extension-native ecosystems require a separate model.

Independent participation, not raw `.com` count. A large `.com` block created through one concentrated pattern is not broad participation. Read the cohort from nine signals together: absolute `.com` count, `.com` share, registrar concentration, nameserver concentration, naming-pattern diversity, persistence across windows, low-base status, single-TLD concentration, and sale-platform nameserver share. Registrar and nameserver concentration are participant-diversity proxies, not direct participant counts; sale-platform nameserver share bears on how much of the participation is resale. Each signal is defined under Signal thresholds.

The yardstick is a balanced free market: many independent participants across registrars, nameservers, TLDs, and naming patterns, over several windows, with end use and resale both present. A spike dominated by any one of them is concentrated.

## Event-cohort integrity

The trend record and the detailed `nrds` sample must describe the same event before their signals are combined.

- Record the detected keyword, provider-defined match semantics, provider-supplied window or bucket definition, data date when supplied, query observation time, TLD or feed coverage, and event-cohort total from `keywords_trends`. Do not manufacture exact event start or end dates from the query date. If the source exposes only a nominal rolling window, report that window and mark exact boundaries `Unavailable`.
- Pull `nrds` for the same keyword and constrain it to the same dates and TLD or feed coverage where the interface permits. If exact alignment is impossible, label `nrds` as supplemental and do not merge its ratios or concentration metrics into the provider's event-cohort figures.
- For domains reviewed from `nrds` or inventory, include the keyword only when it is an exact label, a hyphen-delimited component, or an unambiguous component in a concatenated label. Exclude accidental substrings and ambiguous segmentations from the primary sample; variants belong in a separately labeled secondary sample.
- Before calculating any ratio from `nrds`, deduplicate the sample and record returned count, pagination completed, result cap, and whether the source claims completeness. When coverage is incomplete or unknown, label ratios as `observed-sample ratios`. If the missing data could materially change `.com` participation, concentration, or persistence, the outcome is uncertain.

## Signal thresholds (heuristic bands)

The following bands are heuristic starting points, not statistical laws. Treat a value near a band edge as uncertain, not decisive, and always show the underlying figure.

Data semantics: all ratios and concentration metrics are calculated from registrations contributing to the detected keyword spike, not from the total installed domain base. They therefore describe revealed choices within the incremental event cohort.

- `.com` share: core-market participation. Roughly, higher (around 15% and up) is consistent with genuine open-market interest; very low (around 5% and below) is consistent with bulk activity on cheap TLDs.
- Largest-TLD share: single-suffix concentration. High (around 70% and up) on a non-.com TLD is consistent with concentration in one suffix rather than broad demand.
- Digit share: naming-structure signal. High (around 20% and up) is consistent with template or bulk-driven registration.
- Registration persistence: measure as the number of distinct time windows (for example days within the cohort period) that carry new registrations, and the share of the cohort falling in its single busiest window. Persistent is roughly activity in several windows with no single window dominating (busiest-window share well under half); a single-day burst (one window holding most of the cohort) is not persistent. Show the per-window counts.
- Registrar / provider concentration and pattern concentration: use source-computed registrar shares from `keywords_trends`, reporting the single largest registrar's share and the Top-3 cumulative share when each is returned, stated with the provider cohort size. Do not reconstruct Top-3 from `nrds` or from an incomplete registrar list. Measure pattern concentration from the aligned domain-row sample as the share following one repeated template. A largest-registrar share around half and up weakens the evidence of broad participation but does not establish how many actors exist. A dominant template is direct evidence of structural concentration. Interpret registrar concentration together with pattern, suffix, and time concentration; never convert it into a participant count.
- Nameserver concentration: the largest single nameserver's share of the cohort, from `keywords_trends` when returned. A share around half and up is consistent with one operator or one parking or hosting setup behind much of the spike and weakens the evidence of broad participation. A popular registrar's default nameservers can produce the same reading, so interpret it together with registrar concentration.
- Sale-platform nameserver share: the share of the cohort whose nameservers point at sale platforms, from `keywords_trends` when returned. It is not a verified listing count: names listed without those nameservers are missed, and a parked name is not proof of an active listing. When most of the cohort sits on sale-platform nameservers, infer speculation-led participation and label it as inference; it counts as concentration. Nameserver concentration on the same platforms is the same finding, not a second signal.
- Low base: flag whenever the cohort total is small enough that ratios are unstable (for example a cohort in the low tens or fewer, or any single suffix or window driven by only a handful of names). A low-base flag caps the outcome at uncertain regardless of how the ratios read.

If these bands have been back-tested on historical data, state it and record: the calibration sample's date range; which TLDs the sample covers; the label used for a "validated" trend; and whether the bands are updated periodically. If they have not been back-tested, keep them as heuristic bands: the model supports the direction of each signal, but the specific numbers are not derived laws. Do not present a specific cutoff as a proven threshold without that calibration record.

## Evidence discipline

- **Use a fixed outcome order.** Classify each selected trend in this order:
  1. `Brand-specific / model not applied` when the keyword mainly identifies one existing brand; do not surface candidate inventory.
  2. `Uncertain` when the cohort has a low base, cannot be aligned, has materially incomplete coverage, or is missing a signal that could change the result.
  3. `Not validated by the open market` when an adequately covered cohort has no `.com` participation or falls in the very-low `.com` band.
  4. `Concentrated` when `.com` participates but suffix, template, time, nameserver, or combined registrar-plus-structure evidence shows the spike is materially concentrated, or sale-platform nameservers dominate the cohort (inferred speculation-led participation).
  5. `Open-market validated` only when `.com` participation is meaningful, the cohort is not low-base, activity persists across windows, naming patterns are diverse, and no material concentration signal contradicts the reading.
  Mixed evidence that fits none of these rules is `Uncertain`. Always show the underlying figures. These are open-market registration outcomes, not investment instructions.
- **Read participation from multiple signals**, per the model above; never from `.com` count alone.
- **Brand boundary.** Run a lightweight public-web check on a selected keyword before validation is finalized or candidates are surfaced. If it mainly identifies one existing brand, report the observed spike only as brand-specific registration activity, stop the open-market model, and do not surface registrable, expiring, or listed names as opportunities. State that the check is not trademark clearance or legal advice.
- **Do not infer a cause.** Registration concentration, timing, or naming co-occurrence does not establish a promotion, sale, news event, or other catalyst. Use `keyword-intel` or `domain-market-beat` when the user asks for deeper market or event evidence.
- **Lifecycle verification is stage-specific.** `bulk_available` confirms only whether a name can be registered now, so it applies to `deleted` candidates. It does not validate `expired` (confirm backorder / auction status and provider) or a for-sale listing from `market` or `aged` (a current listing, not a sale). For a listing, attempt to re-check it against the listing tool or the named marketplace before presenting it. If that re-check succeeds, record the verification source; if the marketplace cannot be reached, present the tool-reported listing labeled "listing not re-verified" and treat it as weaker evidence rather than dropping the candidate. Record status and observation time either way.

## Workflow

Proceed end to end when the user names a keyword, requests a fixed number of trends, or explicitly asks for candidates. Pause after discovery only when the user must choose which surfaced keyword to validate. Pause before `expired` or for-sale listings only when willingness to backorder or purchase a registered name is unknown. Do not force phase-by-phase confirmation when the user's requested scope is already clear.

1. **Discover.** Surface trending keywords with `keywords_trends` (hot, emerging, or prefix). For each surfaced keyword, deliver a fixed set so runs stay comparable, marking any field the source does not provide as Unavailable rather than omitting it:
   - the provider-supplied cohort window or bucket definition, any provider data date, and the separate query observation timestamp. Never stamp or reconstruct event boundaries from the current date; if only a nominal rolling window is known, say so;
   - the coverage the source provides (which TLDs or feeds the cohort is drawn from, and whether it is a sample or claims completeness), so a difference between runs is not mistaken for a real change;
   - the spike / event-cohort total (how many new registrations define the trend);
   - the absolute `.com` count in that cohort when the source returns it, alongside the `.com` share; never derive a supposedly exact count from a rounded ratio, and mark the count `Unavailable` otherwise;
   - the provider's structure metrics when returned: digit share, the largest TLD, and its share (single-TLD concentration);
   - a preliminary participation reading from the provider's available metrics, using the heuristic bands and showing every underlying figure; never label it the final open-market outcome while registrar concentration, pattern diversity, or persistence remains Pending;
   - a low-base flag whenever the cohort total is small.
   - registrar Top-1 and Top-3 shares from `keywords_trends` when returned; mark either metric `Unavailable` when absent;
   - nameserver concentration (largest-nameserver share) and sale-platform nameserver share from `keywords_trends` when returned; mark either `Unavailable` when absent;
   Pattern diversity and detailed time structure come from `nrds` in step 2, so mark those fields Pending here. Two cohorts are comparable only when their provider window, data date, coverage, and keyword-match semantics align. If the user has not chosen a keyword or requested an end-to-end top-N analysis, ask which keyword(s) to validate; otherwise continue.

2. **Validate the event cohort.** For each selected keyword:
   - Apply the brand boundary and event-cohort integrity rules.
   - Pull `nrds` for the aligned cohort and report its matching rule, returned count, pagination / result-cap status, naming-pattern diversity, hyphen / digit / length structure, repeated-template share, and the coarse time clustering supported by its day-level registration dates or the available recency buckets. If it cannot be aligned to the trend record, keep it supplemental and make the outcome uncertain rather than merging unlike samples.
   - Apply the fixed outcome order to all nine signals. Report the outcome, confidence, exact figures, cohort dates, observation date, coverage, and unavailable fields.
   - If the user requests search-audience, advertiser, supply, offer, transaction, or catalyst evidence for the chosen keyword, use `keyword-intel`; do not rebuild those layers here.

3. **Surface lifecycle candidates when requested.** Skip this phase for a brand-specific keyword. Filter every result through the same keyword-matching rule used for the event cohort:
   - `deleted` for dropped names, each re-confirmed registrable with `bulk_available`.
   - `expired` only when the user accepts backorder (confirm lifecycle / provider).
   - `market` filtered to for-sale listings, with `aged` as a supplement for names with long registration histories (a listing, not a sale).
   Present each candidate with: domain; exact keyword component and position; matching category (exact / hyphen-delimited / unambiguous concatenation); relation to the validated trend; lifecycle stage; acquisition path; verification source and result; price type, amount, currency, and date where applicable; observation date; and any brand-collision caveat. Exclude ambiguous matches. Mark unavailable fields explicitly. Present candidates as options, not recommendations.

## Next steps

Only if the user asks: use `keyword-intel` for a full evidence analysis of a selected keyword, `domain-analyze` for one domain, monitoring for later changes, or repeat discovery for another trend set. Do not push acquisition or tell the user to act.

## Key principles

- Judge each trend against a balanced free market by aligned new-registration evidence; `.com` is necessary confirmation, not sufficient proof.
- Combine the trend record and `nrds` only when they describe the same event cohort; never fabricate event boundaries.
- Read all nine signals together, show every underlying figure, and measure each signal the same way on every run; thresholds are heuristic bands, not laws.
- Apply the fixed outcome order in Evidence discipline; mixed evidence is uncertain.
- Record sample size, pagination, coverage, and observation dates; partial ratios are observed-sample ratios, not population claims.
- Stop at the brand boundary, verify lifecycle candidates by stage, and present candidates as options, not recommendations.
- Leave full known-keyword intelligence to `keyword-intel`.