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 sam

Preview of the first 4,000 characters. Read full instructions →

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

Preview of the first 4,000 characters. Read full instructions →

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 

Preview of the first 4,000 characters. Read full instructions →

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 c

Preview of the first 4,000 characters. Read full instructions →

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 curren

Preview of the first 4,000 characters. Read full instructions →

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, eve

Preview of the first 4,000 characters. Read full instructions →

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

Preview of the first 4,000 characters. Read full instructions →

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 t

Preview of the first 4,000 characters. Read full instructions →

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 patte

Preview of the first 4,000 characters. Read full instructions →