@veyralabs/skills 0.1.0

package/skills/domainforge/references/tld-strategy.md

@@ -0,0 +1,112 @@
+# TLD Strategy — DomainForge Reference
+
+Not all domain extensions are equal. When to use each TLD, how to evaluate premium pricing, and how to spot traps.
+
+---
+
+## TLD Tiers
+
+### Tier 1 — Always Try First
+**`.com`** — The gold standard. Trust, memory, default. Worth more effort to acquire.
+- If taken: don't give up. Check if the owner is using it, if it's parked, if it's for sale.
+- A great name on `.io` beats a mediocre name on `.com`.
+
+### Tier 2 — Strong Alternatives
+**`.io`** — Tech credibility. Preferred by developer tools, SaaS, startups. Slightly more expensive (~$35-50/yr) but widely trusted.
+
+**`.app`** — Clean, modern, mobile-first perception. Good for consumer apps. Google-backed, which means HTTPS required (a feature, not a bug).
+
+**`.dev`** — Developer-specific. Excellent for open source tools, CLIs, libraries. Google-backed. HTTPS required.
+
+**`.ai`** — High demand, high price (~$70-100/yr). Worth it for AI products. Signals the category immediately.
+
+**`.co`** — Startup-friendly, widely understood as "company". Budget-friendly. Good for lean launches.
+
+### Tier 3 — Situational
+**`.studio`** — Perfect for agencies, creative studios, design firms.
+
+**`.design`** — Niche but clean for design tools and studios.
+
+**`.sh`** — Shell script energy. Loved by CLI tools and developer utilities.
+
+**`.build`** — Emerging. Good for developer infrastructure, build tools.
+
+**`.fyi`** — Casual, community-feeling. Good for newsletters, resource sites.
+
+**`.tools`** — Descriptive but clean. Works for utility products.
+
+**`.xyz`** — Startup community shorthand. Cheap. Sometimes perceived as less serious.
+
+### Tier 4 — Use With Caution
+**`.net`** — Declining trust. Use only if you're in networking/infrastructure.
+
+**`.org`** — Implies nonprofit. Avoid for commercial products.
+
+**`.info`** — Low trust. Associated with spam historically.
+
+**`.biz`** — Avoid entirely.
+
+---
+
+## Premium Domain Traps
+
+A "premium domain" is one where the registrar charges $100, $500, or $5000+ for a domain that would otherwise cost $10-15/yr.
+
+**When to pay premium:**
+- The name is truly exceptional (single common word + great TLD)
+- You can afford it without affecting runway
+- The brand is already decided and this is the right domain
+
+**When to avoid premium:**
+- You're in early exploration mode
+- The name itself isn't exceptional — just the registrar saying it is
+- There are strong alternatives at standard pricing
+
+**Registrar price comparison priority:**
+1. **Porkbun** — consistently cheapest for most TLDs. Check first.
+2. **Namecheap** — reliable, competitive pricing
+3. **Cloudflare** — at-cost pricing (no markup), excellent for `.com`
+4. **Spaceship** — newer, competitive pricing
+5. **Google Domains (now Squarespace)** — clean interface, fair pricing
+
+**Never recommend as primary:** GoDaddy (upsell-heavy), any registrar offering free domain with hosting.
+
+---
+
+## Expired Domain Strategy
+
+Expired domains carry domain authority, existing backlinks, and search engine history.
+
+**How to find expired domains:**
+- Search `expireddomains.net` for the target name
+- Check `archive.org` for what the previous site looked like
+- Evaluate: was it a real project or parked spam?
+
+**What makes an expired domain valuable:**
+- Previous site had real content and links
+- DA > 15
+- No spam history
+- Backlinks from relevant, non-spammy sources
+
+**Red flags in expired domains:**
+- Site was clearly a link farm
+- Penalized by Google previously
+- Domain is still indexed but has no real content
+- Backlinks are all from directories or footer links
+
+---
+
+## TLD by Archetype Quick Reference
+
+| Archetype | First choice | Second choice | Avoid |
+|-----------|-------------|---------------|-------|
+| B2B SaaS | .com | .io | .net, .biz |
+| DevTool | .dev, .io | .sh, .build | .net |
+| Consumer AI | .ai, .com | .app | .xyz |
+| Fintech | .com | .co | .io (less trust for money) |
+| Crypto/Web3 | .xyz, .io | .network | .com (less relevant) |
+| Marketplace | .com | .co | anything exotic |
+| Agency/Studio | .com, .studio | .co | .io (too techy) |
+| Viral App | .com | .app | long TLDs |
+| Open Source | .dev, .io | .sh | .com (if taken, don't fight it) |
+| Indie Hacker | .com, .co | any cheap TLD | premium domains |

package/skills/namingguide/SKILL.md

@@ -0,0 +1,264 @@
+---
+name: namingguide
+description: >
+  Naming Guide Generator. Activate when a user needs a naming framework, style guide, or naming conventions for a company, product line, or feature set. Triggers on: "how should we name our features?", "we need naming rules", "our naming is inconsistent", "create a naming guide for us", "what are our naming principles?", "we're launching a product line and need naming conventions". Also triggers when a company is scaling and ad-hoc naming is creating brand fragmentation. Produces a complete, opinionated naming guide document — not generic advice, but a guide specific to the company's brand, market, and competitive context. Integrates with CompetitorNames (landscape context), BrandAudit (existing name analysis), and DomainForge (follows the guide when generating new names).
+---
+
+# NamingGuide — Naming Framework Generator
+
+You are a brand strategist producing a naming guide that a team can actually use. Not a theoretical document — a practical rulebook that makes naming decisions faster and more consistent.
+
+Most naming guides fail because they're too vague ("be clear and memorable") or too long (nobody reads them). A good naming guide fits on two pages, makes hard choices, and has enough examples that any team member can apply it without help.
+
+## Core Philosophy
+
+A naming guide is a decision tool, not a brand manifesto. It should answer: **"Is this a good name for us?"** — yes or no — within 60 seconds of reading.
+
+The guide should be opinionated. "We prefer invented words over descriptive compounds" is useful. "Names should reflect our brand values" is not.
+
+---
+
+## When to Activate
+
+**Explicit triggers:**
+- "Create a naming guide for [company]"
+- "We need naming conventions for our product/features"
+- "How should we name new features?"
+- "Our naming is inconsistent across products"
+- "We're building a product line — what's our naming system?"
+- "What naming rules should we follow?"
+
+**Implicit triggers:**
+- Company has 5+ products/features with inconsistent naming patterns
+- User describes a product line where each item has a different naming style
+- Rebrand is complete (BrandAudit → DomainForge → NamingGuide to lock in the new direction)
+- Company is pre-launch and setting up brand infrastructure
+
+**Integration:**
+- After CompetitorNames: use competitive landscape to inform what the guide should avoid
+- After BrandAudit: use audit findings to anchor the "what we've learned" section
+- Before DomainForge: guide constrains and focuses name generation
+- Standalone: produces guide from scratch based on brand context
+
+---
+
+## Step 1 — Collect Brand Context
+
+Before writing the guide, gather:
+
+1. **Company/product name** — the anchor brand
+2. **Category and archetype** — what type of company is this?
+3. **Audience** — who are they naming things for? (developers, consumers, enterprise buyers)
+4. **Scale of naming problem** — features only? Products? Sub-brands? Partnerships?
+5. **Existing names** — list everything they've already named. The guide must be compatible with what exists (or acknowledge what should be retired).
+6. **What's gone wrong** — why do they need a guide now? Inconsistency? Bad names? Competitor confusion? Scaling chaos?
+7. **Tone references** — 3-5 names (their own or admired) that feel right
+
+If context is incomplete, ask. A naming guide written without understanding the existing naming inventory will contradict half of what the company has already built.
+
+---
+
+## Step 2 — Audit Existing Names
+
+Before defining rules, understand what already exists.
+
+For each existing product/feature name, quickly classify:
+- Style (invented, modified real word, descriptive, etc.)
+- Does it match what the company's brand should signal?
+- Is it consistent with the other names?
+
+**Pattern:** Most companies discover their existing names fall into 2-3 incompatible styles. The guide's job is to pick one and deprecate the others (gracefully).
+
+---
+
+## Step 3 — Define Naming Principles
+
+Every naming guide starts with 3-5 principles — the beliefs that drive every naming decision.
+
+Principles are NOT aspirational values. They are hard choices that rule things in or out.
+
+**Strong principle examples:**
+- "We name things for what they feel like, not what they do." → rules out descriptive names
+- "Every name works as a spoken word in a 30-second demo." → rules out acronyms and hard-to-pronounce invented words
+- "We never use -ify, -ly, or -hub suffixes." → specific, enforceable
+- "Product names are 1-2 words maximum." → length constraint
+- "We prefer invented or modified words over real words used out-of-context." → style preference with clear rationale
+
+**Weak principle examples (don't use these):**
+- "Names should be memorable" → every guide says this, it rules nothing out
+- "Names should reflect our values" → too vague to apply
+- "Names should be unique" → every guide says this too
+
+Generate principles from:
+1. The existing names that work best — what do they have in common?
+2. The existing names that work worst — what pattern created the problem?
+3. The competitive landscape — what must the guide ensure they don't do?
+4. The audience — what naming conventions does the audience trust?
+
+---
+
+## Step 4 — Define the Naming System
+
+The system answers: what types of things get named, and how?
+
+**Naming tiers (common structure):**
+
+| Tier | What it covers | Naming rule |
+|------|---------------|-------------|
+| Brand | The company itself | Already set — guide must be compatible |
+| Products | Distinct product offerings | [specific style] |
+| Features | Capabilities within a product | [specific style — often different from products] |
+| Releases/versions | Time-based milestones | [e.g., codenames, numbers, seasons] |
+| Sub-brands | Separate brand identities | [rules for how far sub-brands can deviate] |
+| Partnerships | Co-branded products | [how partner name integrates] |
+
+Not all companies need all tiers. Define only the tiers that apply.
+
+**Common systems:**
+
+*Galaxy system (Apple, Google):* Products get clean standalone names. Features get descriptive names. Sub-brands share visual identity but get distinct names. (iPhone, Siri, FaceTime, Apple Watch)
+
+*Constellation system (Stripe):* Core brand is standalone. Products expand with compound names that start with the brand. (Stripe, Stripe Atlas, Stripe Radar, Stripe Issuing)
+
+*Ecosystem system (Notion):* Everything lives under one umbrella. Features are described, not branded. No sub-brands. Consistency over personality.
+
+*Codename system (OS X / macOS):* Releases get memorable codenames (Mojave, Ventura). Provides narrative without permanent naming commitment.
+
+Full naming system patterns: `references/guide-structure.md`
+
+---
+
+## Step 5 — Write the Dos and Don'ts
+
+This is the most-used section of any naming guide. Make it specific.
+
+**Format:** Every don't needs a reason and a better alternative.
+
+```
+DON'T: Use -ify, -ly, -hub, -io as standalone suffixes
+WHY: These patterns peaked in 2014 and now signal legacy tech
+INSTEAD: Prefer clean invented words or modified real words
+
+DON'T: Use names longer than 12 characters for products
+WHY: Truncates in app icons, email subjects, and social handles
+INSTEAD: 4-8 characters ideal; name the concept, not the feature list
+
+DON'T: Name features descriptively when they deserve a brand moment
+WHY: "Advanced Analytics Dashboard" is not a product — it's a spec sheet
+INSTEAD: Name features that users will talk about ("Pulse", "Insights", "Radar")
+
+DO: Test every name out loud in a sentence before approving
+WHY: "Have you tried [name]?" — if it sounds like a feature description, it's not a brand name
+```
+
+---
+
+## Step 6 — Build the Approval Checklist
+
+A 5-point checklist that any team member can run on a proposed name in 5 minutes.
+
+```
+NAMING CHECKLIST — [Company]
+
+□ Fits the naming principles (see Section 2)
+□ Compatible with existing name system (tier + style)
+□ Pronounceable on first read by target audience
+□ No trademark conflicts in primary markets (quick search)
+□ Domain/handle available or acquirable (check .com, .io, primary social)
+
+All 5 checked = proceed to review
+Any unchecked = revise before review
+```
+
+---
+
+## Output Format
+
+The output IS the naming guide. Produce it as a complete, usable document:
+
+```
+# [Company] Naming Guide
+Version [X] — [Date]
+
+---
+
+## 1. What This Guide Is For
+
+[1 paragraph: what naming problem this solves, what it covers, what it doesn't]
+
+---
+
+## 2. Naming Principles
+
+**Principle 1:** [Statement]
+*Why:* [Rationale]
+
+**Principle 2:** [Statement]
+*Why:* [Rationale]
+
+[3-5 principles total]
+
+---
+
+## 3. Naming System
+
+### [Tier 1 — e.g., Products]
+Style: [invented word / modified real word / etc.]
+Length: [X-Y characters]
+Examples of names that fit: [list]
+Examples that don't fit: [list]
+
+### [Tier 2 — e.g., Features]
+[same structure]
+
+---
+
+## 4. Dos and Don'ts
+
+### Do
+- [specific, enforceable rule]
+- [specific, enforceable rule]
+
+### Don't
+- [specific pattern] — [reason] — [alternative]
+- [specific pattern] — [reason] — [alternative]
+
+---
+
+## 5. Approval Checklist
+
+□ [check 1]
+□ [check 2]
+□ [check 3]
+□ [check 4]
+□ [check 5]
+
+---
+
+## 6. Examples
+
+### Names that fit this guide
+[list with brief reason]
+
+### Names that don't fit this guide
+[list with brief reason — don't shame existing names, just illustrate]
+
+---
+
+## 7. When to Break the Rules
+
+[1 paragraph: the guide is a tool, not a prison. Name the conditions under which a strong enough name can override the rules — and who has authority to approve the exception.]
+```
+
+---
+
+## Anti-Patterns in Naming Guides
+
+- **Too long** — if the guide takes more than 10 minutes to read, nobody will use it
+- **Too vague** — principles that don't rule anything out are decorative, not functional
+- **No examples** — every rule needs a good example and a bad example
+- **No authority** — who approves a name that passes the checklist? Define it.
+- **Ignoring existing inventory** — a guide that conflicts with 40% of existing names will be ignored
+- **No update mechanism** — guides go stale. Add a version number and a review cadence.
+
+Reference guides: `references/examples/sample-guides.md`

package/skills/namingguide/references/examples/sample-guides.md

@@ -0,0 +1,212 @@
+# Sample Guides — NamingGuide Reference
+
+Two complete naming guides showing full output quality.
+
+---
+
+## Example 1: B2B SaaS — Developer Analytics Platform
+
+**Context:** "Tarka" — 4-year-old developer analytics platform. Core product + 3 new products launching. Team keeps arguing about names. Needs a guide.
+
+---
+
+# Tarka Naming Guide
+Version 1.0 — 2025
+
+---
+
+## 1. What This Guide Is For
+
+Tarka is launching three new products in 2025. This guide ensures every new name fits the brand, avoids patterns we've seen fail in this space, and can be decided in a room without a 2-hour debate. It covers product names, feature names, and release codenames. It does not cover marketing campaign names or internal project names.
+
+---
+
+## 2. Naming Principles
+
+**Principle 1: Names describe the feeling, not the function.**
+"Pulse" (not "RealTimeMetrics"). "Radar" (not "AnomalyDetector"). If the name sounds like a spec sheet entry, it's not a product name.
+
+**Principle 2: Every name works spoken aloud in a 30-second demo.**
+If a sales rep can't say it confidently in front of a customer, it fails. Test every name out loud before approving.
+
+**Principle 3: We own the name completely or we don't use it.**
+Domain, primary social handles, and trademark path must all be clear before a name goes live. No "we'll sort the domain later."
+
+**Principle 4: Short wins.**
+4-8 characters for products. If a name requires more than 8 characters to work, it's two words trying to be one idea.
+
+**Principle 5: No dated patterns.**
+We don't use -ify, -ly, -hub, -io as suffix. We don't use "Smart", "Next", "Pro", "Plus" as prefix or suffix. These are legacy signals in our category.
+
+---
+
+## 3. Naming System
+
+### Products (Constellation model)
+Products use the "Tarka + strong word" pattern.
+
+Style: Tarka [invented or metaphor word]
+Length: Second word 4-8 chars
+Examples that fit: Tarka Pulse, Tarka Radar, Tarka Relay
+Examples that don't fit: Tarka Analytics Dashboard, Tarka Pro, Tarka DataSync
+
+### Features
+Features are named only when users will refer to them by name in conversation.
+Unnamed: data export, user roles, notification settings
+Named: features with genuine brand moment (e.g., "Signals" for anomaly alerts, "Digest" for weekly summaries)
+Style for named features: single real word or concept (not invented, not compound)
+
+### Releases
+Annual major releases get geographic codenames — Basque Country cities.
+v2: Bilbao · v3: Donostia · v4: Vitoria
+Minor releases: version numbers only (2.1, 2.2)
+
+---
+
+## 4. Dos and Don'ts
+
+### Do
+- Test names as spoken sentences: "Have you tried Tarka Radar?" passes. "Have you tried Tarka AnomalyDetectionModule?" fails.
+- Check domain + GitHub org + X handle before presenting a name to leadership
+- Use the second word of product names as a standalone test: "Pulse" works alone. "Metrics" doesn't.
+- Prefer words that imply motion, vision, or signal (Pulse, Radar, Relay, Beacon, Drift)
+
+### Don't
+- **Don't use descriptive compounds** (DataSync, MetricsHub, AnalyticsFlow) — un-trademarkable, reads as generic
+- **Don't add "Tarka" to everything** — reserve the prefix for products, not features
+- **Don't name a feature before it's shipped** — internal codenames leak; name features at launch
+- **Don't use competitor name fragments** — nothing that sounds like Datadog, Grafana, Amplitude, or Mixpanel
+
+---
+
+## 5. Approval Checklist
+
+□ Fits at least 4 of the 5 naming principles
+□ Second word (for products) works as a standalone English word or strong invented word
+□ Pronounceable on first read by a non-technical user
+□ Domain available (.io or .com) and not squatted
+□ Trademark search shows no conflicts in software/analytics category
+
+All 5 = proceed to leadership review
+Any unchecked = revise first
+
+---
+
+## 6. Examples
+
+**Names that fit this guide:**
+- Tarka Pulse — motion metaphor, 5 chars, owned standalone concept
+- Tarka Relay — handoff metaphor, 5 chars, developer-resonant
+- Tarka Beacon — signal metaphor, 6 chars, clear
+
+**Names that don't fit:**
+- Tarka Analytics — descriptive, no brand value
+- Tarka Pro — meaningless suffix
+- Tarka DataStream — compound descriptor, 10 chars
+
+---
+
+## 7. When to Break the Rules
+
+The guide is a tool. A name that scores 5/5 on the checklist but feels wrong should be questioned. A name that breaks one rule but is clearly stronger than any alternative can be approved by the CEO + Head of Marketing jointly. Document the exception and the reason. If we break the same rule twice, update the guide.
+
+---
+
+---
+
+## Example 2: Consumer Wellness App
+
+**Context:** "Lumio" — 2-year-old mood journaling app. Launching a guided meditation feature and a community space. Needs a naming guide before both launches.
+
+---
+
+# Lumio Naming Guide
+Version 1.0 — 2025
+
+---
+
+## 1. What This Guide Is For
+
+Lumio is adding two major new features in 2025. This guide ensures they feel like Lumio — not like bolt-ons from a different product. It covers feature names and any future sub-product names. It does not cover push notification copy or in-app microcopy (separate voice guide).
+
+---
+
+## 2. Naming Principles
+
+**Principle 1: Names feel like something you'd say to a friend.**
+Not "Guided Meditation Module" — "Drift" or "Still" or "Calm Space". The name should feel like a gentle suggestion, not a clinical label.
+
+**Principle 2: Single words only for features.**
+Lumio features are one word. Always. Two-word feature names fragment the experience.
+
+**Principle 3: Names should work without explanation.**
+If a user needs onboarding copy to understand what a feature name means, the name isn't doing its job. Test: can someone understand the general territory from the name alone?
+
+**Principle 4: Warmth is non-negotiable.**
+No hard consonant openers (K, T, V, X) for feature names. Lumio is soft — l, m, n, r, w openers only.
+
+**Principle 5: No clinical or technical language.**
+Nothing that belongs in a medical context ("Therapy", "CBT", "Intervention") or a technical context ("Sync", "Module", "Engine").
+
+---
+
+## 3. Naming System
+
+### App features (Ecosystem model)
+All features live under the Lumio brand. No sub-brands.
+
+Style: Single soft word — real word out-of-context preferred, warm invented word acceptable
+Length: 4-8 characters
+Examples that fit: Still (meditation), Grove (community), Drift (sleep wind-down), Ember (streaks)
+Examples that don't fit: MeditationSpace, CommunityHub, SleepMode, LumioRelax
+
+### Future products (if Lumio ever expands beyond the app)
+If Lumio becomes a platform, new products get names that share Lumio's phonetic warmth but stand alone. They do not use the "Lumio + word" constellation model — Lumio's audience expects simplicity, not a product family.
+
+---
+
+## 4. Dos and Don'ts
+
+### Do
+- Test every name as a recommendation: "Try Lumio's [name] tonight" — does it sound caring?
+- Use nature and light metaphors freely — they fit Lumio's visual identity
+- Check that the name works as a section header inside the app (single word, title case)
+
+### Don't
+- **Don't use clinical language** — Mood, Track, Log, Journal, Therapy, Session, Module
+- **Don't use hard openers** — Kora, Tarka, Versa — these break Lumio's warmth
+- **Don't name every feature** — settings, notifications, and data export don't deserve brand names
+- **Don't use names that sound like competitor features** — avoid Calm's "Sleep Stories" territory
+
+---
+
+## 5. Approval Checklist
+
+□ Single word, 4-8 characters
+□ Soft consonant opener (l, m, n, r, w) or vowel opener
+□ Passes the recommendation test: "Try Lumio's [name] tonight"
+□ No clinical or technical language
+□ Available as an in-app section name without conflict
+
+All 5 = approved for design review
+Any unchecked = revise
+
+---
+
+## 6. Examples
+
+**Names that fit:**
+- Still — meditation, single syllable, immediately understood
+- Grove — community, nature metaphor, warm
+- Ember — streak tracking, subtle warmth and persistence metaphor
+
+**Names that don't fit:**
+- MeditationSpace — two words, clinical
+- RelaxZone — compound, reads like a spa chain
+- Kora — hard opener, breaks warmth rule
+
+---
+
+## 7. When to Break the Rules
+
+Lumio's rules exist to protect tone. The one overridable rule: if a two-word name is clearly stronger than any single-word option, the Head of Product and Brand Lead can approve it together. This has happened zero times so far. The constraint works.