agentleFS
corebits-iocorebits-io/deal-origination-system/skills/founder-research/SKILL.md

founder-research

Skill1 starsChanged 3 months agoMITView on GitHub

Research the owners and management of scored targets from public professional sources only: role history, tenure, succession signals, recent activity, and possible warm paths. Quotes every claim with a source, never touches personal-life data, and never guesses contact details. Triggers on: research founders, founder research, research owners, owner research, who owns this company, management research, succession signals, research the management team, background on the owner, warm paths to owners.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

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

    Read thesis-profile.md. If missing, stop and set it up from templates/thesis-profile.md before doing anything else.

    line 22
  2. Very specific:

    Read targets.csv. Default scope is every Strong Fit and Fit row without an owner_name.

    line 25
  3. Very specific:

    If the list has not been through thesis-fit-scoring, say so and recommend running it first.

    line 28
  4. Distinctive:

    No pretexting: Never pose as a customer, supplier, or researcher to extract information.

    line 44
  5. Very specific:

    Every claim is quoted with a source URL and date: If you cannot quote it, you do not have it.

    line 52
  6. Distinctive:

    No successor visible in the management team

    line 70
  7. Distinctive:

    Nothing in this skill is outreach: No connection requests, no calls, no "just checking the phone line works." Contact starts only after the …

    line 163

≈ “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

Founder and Owner Research

Finds out who actually owns each target, how long they have run it, and whether anything public suggests they might sell. This is where the list stops being companies and starts being people — which is exactly why the rules below are strict.

Read first:

  • references/compliance-and-ethics.md — the ethical line, in full
  • references/target-taxonomy.md — who the decision-maker is per ownership type
  • references/scoring-rules.md — the anti-fabrication rules

Step 0 — Load

  1. Read thesis-profile.md. If missing, stop and set it up from templates/thesis-profile.md before doing anything else. Section 8 (why an owner should talk to you) shapes what "what they care about" is for.
  2. Read targets.csv. Default scope is every Strong Fit and Fit row without an owner_name. Confirm the scope with the user before starting.

If the list has not been through thesis-fit-scoring, say so and recommend running it first. Researching owners of unscored rows wastes the most expensive step on companies that may not survive the rubric.


Step 1 — The ethical line

This skill works from the professional footprint only. These rules are absolute and are restated here because this is the step where they get broken.

  1. Public professional sources only: company sites, LinkedIn, registry filings, trade press, conference bios, podcast appearances. Never personal social accounts, never home addresses, never family information beyond family members who publicly work in the business.
  2. No pretexting. Never pose as a customer, supplier, or researcher to extract information. Never suggest the user do so.
  3. Age bands come only from public professional markers — graduation year, stated career start, "35 years in the trade" — and are always recorded with the marker as the basis. Never estimate age from a photo.
  4. Never guess email addresses from patterns. Contact routes are contact-verification's job. Leave owner_email and email_status untouched.
  5. Every claim is quoted with a source URL and date. If you cannot quote it, you do not have it. Not found is the correct answer, constantly.

Step 2 — Research, one company at a time

For each target, work through:

  1. Who owns it. Registry filings, about pages, LinkedIn, local press. Record owner_name and owner_title only when confirmed — an operations manager quoted in an article is not the owner. Cross-check against the ownership_type per target-taxonomy.md; if they disagree, flag it.
  2. Role history and tenure. How long they have owned or run it, what they did before, whether they founded or bought it.
  3. Succession signals, each one quoted:
    • Years in business (25+ years under one owner is itself a signal)
    • Second generation visibly in the business — or visibly absent
    • No successor visible in the management team
    • Retirement-adjacent language in interviews, bios, or posts Record the strongest one in succession_signal, quoted with its source. Absence of a signal is Not found, not a fabricated hunch.
  4. Recent activity. Expansion, new lines, hiring, awards, press in the last 24 months. Recency matters; date everything.
  5. What they care about. Their own words on the business, employees, community, craft. This feeds outreach-writer later — a quote it can reference honestly is worth more than any inferred psychology.
  6. Warm paths. Shared associations, alumni networks, or named mutual contacts the user has already listed. Record only verifiable paths in warm_path and warm_path_via. Never invent a mutual connection.

Depth control

Cap research at roughly 10 minutes per company equivalent. If an owner is genuinely invisible online — common and not suspicious for private companies — record Not found across the board and move on. The registry filing that names them is still a result.


Step 3 — Write back to targets.csv

Fields this skill fills: owner_name, owner_title, owner_linkedin, succession_signal, warm_path, warm_path_via, and any correction to ownership_type discovered along the way (with the evidence noted in notes).

Fields this skill never touches: owner_email, email_status (that is contact-verification's job), and fit_score / fit_reason (rescoring happens through thesis-fit-scoring only — but flag any finding that should trigger it, such as a target that turns out to be PE-backed).

Everything unknown is the literal string Not found. Never blank, never a guess.

🚧 HARD GATE — before writing

Show the user:

  • How many rows you are about to update
  • How many owners were confirmed vs. Not found
  • Five sample rows in full, including the quoted succession signals
  • Any row where research contradicted the existing ownership_type

Get approval. Then write.


Step 4 — Report honestly

Founder research complete — 111 rows in scope

Owners confirmed:        84   (76%)
Owner Not found:         27   (mostly registry-only entities, no site bio)

Succession signals:
  Quoted signal found     41
  25+ year tenure         26
  Retirement language      6
  Second gen absent        9
  Not found               70

Warm paths recorded:      12  (9 via trade association, 3 via user's list)
Ownership corrections:     3  (2 rows are add-ons of a sponsor — flagged
                               for thesis-fit-scoring re-run)

Weakest area:  Owner LinkedIn coverage — 31 of 84 confirmed owners have no
               findable profile. Normal for this sector, not a data failure.
Not yet done:  Contact verification, outreach

Next: contact-verification on the 84 confirmed owners.

Report what did not work. An invisible owner reported as invisible is a finding. An invisible owner reported with a plausible-sounding biography is a fabrication, and it will surface at the worst possible moment — in the first conversation.


Notes

  • The owner is the product of this step. In founder- and family-owned companies there is exactly one person who can say yes. Everything here exists to let outreach address that person honestly and specifically.
  • Succession signals are probabilistic, not conclusions. A 30-year owner with no successor may still never sell. Record the signal; never write "is looking to retire" unless they said it, quoted.
  • If research surfaces bad news — litigation, license issues — record it in notes with the source and no editorializing. It is diligence input, not gossip.
  • Nothing in this skill is outreach. No connection requests, no calls, no "just checking the phone line works." Contact starts only after the user approves a sequence, and nothing sends automatically, ever.

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.