B2B Customer Development

Use this skill to help users build and operate a privacy-safe B2B customer development workflow:

Define target customers -> Build keywords -> Find public leads -> Research and score -> Prioritize -> Draft outreach -> Feed results back into the knowledge base

Safety and compliance rules

Follow these rules before doing any task:

1. Use only public, user-provided, or properly authorized information.
2. Do not expose, invent, or retain private personal data, customer lists, API keys, server IPs, credentials, quotes, contracts, or internal business records in public artifacts.
3. Do not help bypass access controls, paywalls, CAPTCHAs, rate limits, account restrictions, robots restrictions, or platform anti-abuse systems.
4. Do not present sanctions, legal, credit, fraud, or compliance conclusions as final legal determinations. Present them as research signals that require user review.
5. For outreach, draft opt-in or compliant cold outreach only. Include truthful claims, clear sender identity, relevant context, and an opt-out path when appropriate.
6. Avoid sensitive personal inferences. Do not infer protected traits or use them for targeting.
7. Keep public examples fictional or clearly generic.
8. When preparing GitHub/SkillHub artifacts, keep secrets in .env, private provider configs, or secret managers, never in SKILL.md, docs, templates, or sample data.

If a user asks for something that would violate these rules, refuse that part briefly and offer a safe alternative.

Choose the right reference

Read only the reference needed for the current task:

• For the business workflow and a complete fictional example, read docs/CUSTOMER_DEVELOPMENT_LOGIC.md.
• For first-time setup, keyword extraction, and building the initial knowledge base, read docs/FIRST_RUN_GUIDE.md.
• For data structure, routing, and JSON schema, read docs/KNOWLEDGE_SCHEMA.md.
• For Hermes server deployment, read docs/DEPLOY_HERMES.md.
• For workbudy/local assistant deployment, read docs/DEPLOY_WORKBUDY.md.
• For public-release safety checks, read docs/PRIVACY_AND_SECURITY.md and docs/SANITIZATION_REPORT.md.
• For reusable outputs, use the templates in templates/.

Do not load every document by default. Start with this SKILL.md, then load the smallest relevant reference.

Core workflow

1. Define the target customer

Help the user specify:

• Product or service category
• Target country or region
• Buyer type
• High-value buying signals
• Exclusion signals
• Required compliance or certification signals

Produce a concise target customer profile before searching or drafting outreach.

2. Build keyword groups

Separate keywords into:

• Product terms
• Use-case terms
• Buyer/channel terms
• Competitor or alternative terms
• Certification/compliance terms
• Risk or exclusion terms

Store public or generic examples in data/json/*.json. Put real private keyword assets in a private environment or data/private/.

3. Find and normalize leads

When helping with lead discovery, structure each lead as:

company_name
country_or_region
website
source
matched_keywords
initial_business_fit
notes

Do not enrich leads with private personal data unless the user explicitly provides it and has authority to use it.

4. Research and score

Evaluate leads using public evidence:

• Business fit
• Company authenticity
• Channel or purchasing capability
• Contact feasibility
• Risk signals
• Data coverage and confidence

Prefer transparent reasoning over black-box scores. Record evidence and uncertainty.

5. Prioritize

Classify leads into:

• A: strong fit, clear evidence, ready for personalized outreach
• B: plausible fit, needs light follow-up or more evidence
• C: weak or incomplete fit, monitor only
• D: unrelated, high risk, or not worth pursuing

If the user prefers T1/T2/T3:

• T1: fast screening
• T2: standard research
• T3: deep research for high-value or high-risk leads

6. Draft outreach

Every outreach draft should include:

• A public research signal about the prospect
• A relevant value proposition
• A truthful and supportable claim
• A low-friction CTA
• A professional signature or sender placeholder
• An opt-out line when appropriate

Avoid manipulative urgency, fake familiarity, unverifiable claims, or mass-spam language.

7. Feed back results

Help the user convert outcomes into reusable knowledge:

• Replies -> effective buyer signals and messages
• No replies -> subject line and CTA tests
• Bounces -> email/domain quality rules
• Rejections -> exclusion signals
• Referrals -> role and org-structure clues
• Deals -> high-value customer patterns

Update schemas, templates, or notes without exposing private records in public files.

Public-release checklist

Before marking a GitHub/SkillHub package ready, verify:

• SKILL.md has only name and description in YAML frontmatter.
• Public examples are fictional or generic.
• .env, private configs, customer data, logs, reports, backups, and generated artifacts are ignored.
• No real API keys, tokens, passwords, IPs, emails, phone numbers, customer names, or contracts appear in public files.
• Deployment docs use placeholders rather than real hosts or accounts.
• Outreach guidance emphasizes relevance, truthful claims, and compliance.

Output style

When producing artifacts, prefer:

• Clear tables for workflows, schemas, and scoring rubrics
• Short examples over long theory
• Explicit assumptions
• Safe placeholders such as [Company], [Name], [Region], [Public signal]
• Actionable next steps

Keep public artifacts reusable and sanitized.