agentleFS
corebits-iocorebits-io/deal-origination-system/skills/contact-verification/SKILL.md

contact-verification

Skill1 starsChanged 3 months agoMITView on GitHub

Find and verify the actual owner or decision maker at each target company, with role, LinkedIn, and email where available. Marks confidence honestly and never guesses an address. Triggers on: find contacts, verify emails, find the owner, who do I contact, enrich contacts, get owner emails, find the decision maker, contact verification, verify owner contacts.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read thesis-profile.md for sender identity (section 9) and geography.

    line 22
  2. Very specific:

    If warm_path is populated, stop here.

    line 67
  3. Distinctive:

    Only if you have a real one.

    line 72
  4. Very specific:

    Add to notes where relevant:

    line 123
  5. Very specific:

    Never invent an email: Not once, not for a Strong Fit, not because the pattern is obvious.

    line 172
  6. Very specific:

    Professional footprint only: No personal-life data, no home addresses, no pretexting calls to reception.

    line 176

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Contact Verification

Finds the person who can actually sell the company, and gets a route to them that works.

A perfect target list pointed at a plant manager is a wasted campaign. So is a technically plausible address that bounces and damages your sending domain.

Read first: references/target-taxonomy.md (who can sell, by ownership type), references/compliance-and-ethics.md (personal data handling, no pretexting).


Step 0 — Load and scope

  1. Read thesis-profile.md for sender identity (section 9) and geography. If it does not exist, stop and walk the user through creating it from templates/thesis-profile.md before doing anything else.
  2. Read targets.csv.
  3. Filter to Strong Fit and Fit only. Never enrich Not a Fit or Near Miss rows. It costs time to build contact data you will not use.

Report how many rows are in scope and ask whether to do all of them or start with Strong Fit.


Step 1 — Identify the right person, before looking for any address

Order matters. Find the correct human first. An email for the wrong person is worth less than nothing. Use ownership_type and references/target-taxonomy.md to know who can actually say yes:

  1. Owner / Founder / President (founder-owned, family-owned)
  2. Majority shareholder or managing partner (partner-owned)
  3. CEO, only where the CEO is also an owner
  4. For PE-backed rows: the sponsor's deal team, not the company. Flag these — they are a different conversation entirely.
  5. For franchisees, ESOPs, corporate-owned: per the taxonomy. Most are not sellable by the person running the location. Flag for reclassification.

A hired CEO cannot sell a family business. Writing to one wastes the first touch and often gets your name to the owner with a gatekeeper's framing.

Where to look: the company's own site first (about, team, history pages), then state registry or Companies House filings (officers and registered agents are public and reliable), then LinkedIn, then licensing boards, trade association member listings, and local press. Second-generation names in a "our story" page are a succession signal — note them in succession_signal.

One contact per company by default. Small companies talk. Messaging the owner and the owner's son in the same week reads as a mail merge to both.


Step 2 — Get a route to them

In order of what actually works:

Warm path

If warm_path is populated, stop here. Do not look for an email. An intro through a shared advisor, banker, or peer converts many times better than the best cold message you will ever write. Route it as an introduction.

Email

Only if you have a real one.

Acceptable sources:

  • Published on the company's own site
  • In a registry or licensing filing
  • In a trade directory or association listing the owner controls
  • Returned by a verification service with a confidence score

Never acceptable:

  • Guessed from a pattern (first@domain.com) without verification
  • Inferred because info@ exists so the owner "probably" does too
  • Copied from a purchased list without independent verification

Pattern-guessing is the fastest way to destroy a sending domain. A high bounce rate on a young domain can end your ability to send email at all. One guessed address is not worth that risk. This system never writes inferred addresses; inferred-DO-NOT-USE exists only so imported lists can be flagged.

LinkedIn

Real but weaker for this audience. Many owners of good private companies have a bare profile or none. Record the URL when it exists; do not treat absence as a negative signal.

Contact form or published phone

A real fallback for offline owners. Record phone only if published by the company itself. Never look up personal numbers. Note that forms and phone need a manual, human touch — often a posted letter works better here (see outreach-sequencer).


Step 3 — Record confidence honestly

email_statusMeaning
verifiedConfirmed deliverable by a verification service
publishedFound on the company's own site or an official filing
inferred-DO-NOT-USEPattern-derived, from an imported list. Never send.
Not foundNo email located. The honest and common outcome

Anything not verified or published does not go into a sequence. outreach-sequencer enforces this.


Step 4 — Write back to targets.csv

Fill: owner_name, owner_title, owner_linkedin, owner_email, email_status, and succession_signal where found.

Add to notes where relevant:

  • Contact form or published phone only
  • Ownership unclear — could not confirm who can sell
  • PE-backed discovered during research (flag for thesis-fit-scoring)
  • Owner appears to have exited or died (check the registry date)

🚧 HARD GATE — before writing

Show:

  • Rows about to be updated
  • Breakdown by email_status
  • Ten sample rows in full
  • Any company where you could not identify an owner at all
  • Any row where ownership turned out to be different from what was scored

Get approval. Then write.


Step 5 — Report

Contact verification complete — 118 rows in scope

Owner identified:       97 (82%)
No owner found:         21  ← mostly registry-only entities, listed in notes

Route available:
  Warm path exists        6  → route as introductions
  Email published        41
  Email verified         18
  LinkedIn URL           52
  Phone published        23  (manual only)
  inferred-DO-NOT-USE     0  ← by design, we do not guess
  Not found              33

Sendable by email now:     59  (verified + published)
Manual route only:         24  (form, phone, or letter)

Flags:
  Actually PE-backed        4  → back to thesis-fit-scoring
  Hired CEO, owner absent   7  (owner found via registry instead)
  Ownership unclear         3  → needs your read

Notes

  • Never invent an email. Not once, not for a Strong Fit, not because the pattern is obvious. Not found is the correct output.
  • Verify before any bulk send. Even published addresses go stale. Run a deliverability check on the batch before the first send.
  • Professional footprint only. No personal-life data, no home addresses, no pretexting calls to reception. See references/compliance-and-ethics.md.
  • Treat this data as personal data. It is regulated in many jurisdictions. Keep it in the gitignored workspace.
  • Re-check before a second campaign. Owners retire, sell, and hand over to the next generation. A list is stale faster than you think.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.