Source profileQuality 91/100

rampstackco/claude-skills/skills/domain-strategy/SKILL.md

domain-strategy

Plan, manage, and optimize a domain portfolio. Use this skill for DNS architecture decisions, redirect strategies, registrar choice, parking unused domains, multi-site setups, and domain consolidation or split planning. Triggers on DNS, domain, registrar, redirect, parking, subdomain, apex, www vs non-www, multi-site, portfolio, hreflang setup, domain migration. Also triggers when planning a new site that needs domain decisions made before launch.

Source repository stars
779
Declared platforms
0
Static risk flags
0
Last source update
2026-08-28
Source checked
2026-08-28

Decision brief

What it does: where it fits

Decide how domains, subdomains, and DNS work across a portfolio. Stack-agnostic. Works for one site or one hundred.

Best for

  • Setting up DNS for a new site (apex vs www, primary vs aliases)
  • Choosing or switching registrars
  • Planning redirects across multiple domains (parked, retired, consolidated)

Not for

  • Migrating content between platforms with URL changes (use content-migration)
  • Email authentication setup specifically (use email-deliverability)

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/rampstackco/claude-skills --skill "skills/domain-strategy"
Safe inspection promptEditorial

Inspect the Agent Skill "domain-strategy" from https://github.com/rampstackco/claude-skills/blob/a67dd34c609f034c0cfd736a348659bbdf1605bf/skills/domain-strategy/SKILL.md at commit a67dd34c609f034c0cfd736a348659bbdf1605bf. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Workflow

    Pull every domain you own from every registrar. Build a single sheet:

    Primary (the main site for a brand)Alias (redirects to a primary)Defensive (registered to prevent others from getting it; usually parked)
  2. 02

    Step 1: Inventory

    Pull every domain you own from every registrar. Build a single sheet:

    Pull every domain you own from every registrar. Build a single sheet:If you can't account for every domain, the strategy can't be accurate.
  3. 03

    Step 2: Classify by role

    Each domain gets one role: - Primary (the main site for a brand) - Alias (redirects to a primary) - Defensive (registered to prevent others from getting it; usually parked) - Campaign (short-term, specific use) - Retired (no longer active; either drop at expiry or redirect perma…

    Primary (the main site for a brand)Alias (redirects to a primary)Defensive (registered to prevent others from getting it; usually parked)
  4. 04

    Step 3: Audit current configuration

    For each domain check: - Is the canonical (apex vs www) consistent with the strategy? - Are redirects 301 (permanent) where intended? - Is HTTPS enforced on every variant? - Are DNS records minimal and intentional? - Is the registrar locked? - Is auto-renew on? - Is 2FA on the r…

    Is the canonical (apex vs www) consistent with the strategy?Are redirects 301 (permanent) where intended?Is HTTPS enforced on every variant?
  5. 05

    Step 4: Set the canonical pattern

    For new domains and any that need fixing:

    Pick apex or www as canonicalConfigure 301 redirect for the non-canonicalForce HTTPS for both

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score91/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars779SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
rampstackco/claude-skills
Skill path
skills/domain-strategy/SKILL.md
Commit
a67dd34c609f034c0cfd736a348659bbdf1605bf
License
MIT
Collected
2026-08-28
Default branch
main
View the original SKILL.md

Domain Strategy

Decide how domains, subdomains, and DNS work across a portfolio. Stack-agnostic. Works for one site or one hundred.


When to use

  • Setting up DNS for a new site (apex vs www, primary vs aliases)
  • Choosing or switching registrars
  • Planning redirects across multiple domains (parked, retired, consolidated)
  • Deciding subdomain vs subfolder vs separate domain for a new product line
  • Consolidating multiple sites into one
  • Splitting one site into multiple
  • Setting up DNS for email, security records, third-party services

When NOT to use

  • Migrating content between platforms with URL changes (use content-migration)
  • Email authentication setup specifically (use email-deliverability)
  • Security headers or HTTPS config (use security-baseline)
  • Internationalization domain choices (use internationalization)

Required inputs

  • Current domain inventory (every domain you own or operate)
  • Status of each (live, parked, redirected, retired)
  • Strategic role of each (primary brand, sub-brand, defensive registration, campaign)
  • Current DNS provider and registrar for each
  • Email and third-party service dependencies

The framework: 5 decisions

Every domain decision falls into one of these buckets. Address them in order.

Decision 1: Apex vs www as canonical

Pick one. Redirect the other to it. Pick before launch. Changing later is painful.

  • Apex (example.com): cleaner, more memorable, the modern default.
  • www (www.example.com): historically standard, easier to add CDN-level CNAME records (apex CNAME is technically forbidden but most providers offer ALIAS or ANAME).

Whichever you pick, the other must 301 to it. Both serving content is duplicate content and a soft signal of poor setup.

Decision 2: Subdomain vs subfolder vs separate domain

For a new product, blog, or content section:

PatternUse when
Subfolder (example.com/blog)Same brand, want SEO equity to flow, default choice
Subdomain (blog.example.com)Different stack or platform, organizationally separate but related
Separate domain (exampleblog.com)Different brand, different audience, intentional separation

Default to subfolder. The case for subdomain or separate domain has to be made.

Decision 3: Registrar strategy

The registrar is where the domain is registered. The DNS provider is where DNS records live. They can be the same or different.

Decisions:

  • Single registrar vs multiple: single is simpler. Multiple makes sense for redundancy at scale.
  • Lock and 2FA: non-negotiable. Domain hijacking is real and costly.
  • Auto-renew: on for everything you care about. Off only for intentional drops.
  • WHOIS privacy: on by default. Free at most modern registrars.
  • Transfer lock: on except during planned transfers.

Decision 4: DNS provider

The DNS provider controls how domains resolve. Critical for performance, reliability, and security.

Pick a provider that gives you:

  • Fast global resolution (anycast network)
  • DNSSEC support
  • API access for automation
  • Reasonable record limits
  • Good audit logs

Default DNS records every domain needs:

  • A or AAAA records (or CNAME) for the apex and www
  • MX records (even just nullified if no email)
  • TXT for domain verification, SPF
  • CAA records (locks down which certificate authorities can issue certs for the domain)

Decision 5: Parked domain strategy

Domains you own but aren't actively using. Three valid strategies:

  1. Redirect to a primary site. Best for defensively registered domains close to your main brand. 301 every path to the primary's homepage or matching path.
  2. Hold blank. A simple page or DNS NXDOMAIN. Acceptable for domains you may use later.
  3. Park with a landing page. Generic "coming soon" page. Lowest value. Avoid registrar default parking pages (often serve ads against your brand).

Anti-pattern: letting parked domains serve duplicate or near-duplicate content from your main site. This is an SEO liability.


Workflow

Step 1: Inventory

Pull every domain you own from every registrar. Build a single sheet:

DomainRegistrarDNS providerStatusRoleRenewal dateNotes

If you can't account for every domain, the strategy can't be accurate.

Step 2: Classify by role

Each domain gets one role:

  • Primary (the main site for a brand)
  • Alias (redirects to a primary)
  • Defensive (registered to prevent others from getting it; usually parked)
  • Campaign (short-term, specific use)
  • Retired (no longer active; either drop at expiry or redirect permanently)

The classification drives the configuration.

Step 3: Audit current configuration

For each domain check:

  • Is the canonical (apex vs www) consistent with the strategy?
  • Are redirects 301 (permanent) where intended?
  • Is HTTPS enforced on every variant?
  • Are DNS records minimal and intentional?
  • Is the registrar locked?
  • Is auto-renew on?
  • Is 2FA on the registrar account?

Document gaps. Each gap is a ticket.

Step 4: Set the canonical pattern

For new domains and any that need fixing:

  • Pick apex or www as canonical
  • Configure 301 redirect for the non-canonical
  • Force HTTPS for both
  • Verify with curl: curl -I http://example.com, curl -I http://www.example.com, curl -I https://www.example.com. All should chain to a single 200 on the canonical.

Step 5: Document the redirect map

Across the portfolio, document every redirect:

SourceDestinationTypeReasonDate set

This is invaluable when something breaks or when planning consolidations.

Step 6: Set up monitoring

Monitor:

  • DNS resolution (alert on NXDOMAIN or wrong IP)
  • HTTPS certificate expiration (alert at 30, 14, 7 days out)
  • Redirect chains (alert if a 301 starts returning 200 or 404)
  • Renewal dates (alert at 90, 30, 7 days out)

This is the bridge between domain strategy and monitoring-and-alerting.

Step 7: Document and revisit

Domain strategy is a quarterly review topic. Renewals, consolidations, and new launches change the picture. Without scheduled review, the portfolio drifts.


Failure patterns

Both apex and www serve content. Duplicate content. Pick one, redirect the other.

302 redirects where 301 was intended. 302 is temporary. 301 is permanent. SEO equity passes through 301, not (reliably) through 302.

HTTPS not enforced. HTTP variant serving content alongside HTTPS. Force HTTPS at the edge or the load balancer.

Registrar default parking pages. Parked domains serving registrar ads. Free for the registrar, bad for you. Replace with a redirect or your own page.

Domains in multiple registrars by accident. Migrations that didn't fully complete. Consolidate.

No CAA records. Anyone with a misconfigured ACME client can issue a cert for your domain. CAA limits which CAs can issue. Add it.

Auto-renew off "to save money." Domain accidentally drops, gets snapped up, costs ten times more (or is unrecoverable). Auto-renew is cheap insurance.

Subdomains used where subfolders would have been better. SEO equity gets fragmented across hostnames. The case for a subdomain has to be made; the default is subfolder.

Parked domains with thin content "for SEO." Search engines don't reward this. They penalize doorway pages. Either redirect or leave blank.


Output format

A domain strategy document includes:

  • Inventory: the spreadsheet of every domain
  • Classification: the role of each
  • Canonical decisions: apex vs www, locked
  • Redirect map: every redirect in the portfolio
  • DNS standards: the default record set
  • Registrar standards: locked, 2FA, auto-renew
  • Monitoring: what's watched, where alerts go
  • Renewal calendar: the next 12 months
  • Review cadence: when this gets revisited

Reference files

  • references/dns-record-reference.md: Common DNS records explained, with the syntax for the most useful ones (A, AAAA, CNAME, MX, TXT, CAA, SRV, etc.) and when each is needed.

Frequently asked questions

What to verify before installation and use

What does the domain-strategy source document cover?

Decide how domains, subdomains, and DNS work across a portfolio. Stack-agnostic. Works for one site or one hundred.

How do I install domain-strategy?

The source record exposes this install command: npx skills add https://github.com/rampstackco/claude-skills --skill "skills/domain-strategy". Inspect the command and pinned source before running it.

Alternatives

Compare before choosing

Computed 10029,236

garrytan/gbrain

bulk-ingestion

End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.

Computed 10025,136

alirezarezvani/claude-skills

app-store-optimization

App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

Computed 10015,385

wanshuiyin/Auto-claude-code-research-in-sleep

citation-audit

Use it for operations and research tasks; the detail page covers purpose, installation, and practical steps.

Computed 10014,706

prowler-cloud/prowler

postgresql-indexing

PostgreSQL indexing best practices for Prowler: index design, partial indexes, partitioned table indexing, EXPLAIN ANALYZE validation, concurrent operations, monitoring, and maintenance. Trigger: When creating or modifying PostgreSQL indexes, analyzing query performance with EXPLAIN, debugging slow queries, reviewing index usage statistics, reindexing, dropping indexes, or working with partitioned table indexes. Also trigger when discussing index strategies, partial indexes, or index maintenance