agentleFS
corebits-iocorebits-io/deal-origination-system/skills/thesis-fit-scoring/SKILL.md

thesis-fit-scoring

Skill1 starsChanged 3 months agoMITView on GitHub

Qualify a target list against the acquisition thesis. Applies a Strong Fit / Fit / Near Miss / Not a Fit rubric, screens out PE-backed and conflicted companies, and audits its own output before reporting. Triggers on: score targets, fit scoring, thesis fit, qualify targets, rank targets, filter target list, classify targets, is this company a fit, clean target list, which targets are worth pursuing.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 4 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    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 21
  2. Very specific:

    Read targets.csv from the workspace.

    line 23
  3. Distinctive:

    Ask whether to score only unscored rows (default) or rescore everything.

    line 26
  4. Very specific:

    Hard exclusions first: If any fires, mark Not a Fit, name the rule in fit_reason, and stop.

    line 91
  5. Distinctive:

    Never treat an estimate as a fact, and never silently tighten the box.

    line 96
  6. Distinctive:

    Look for a quoted signal: Must be quotable, with a source URL.

    line 97
  7. Very specific:

    Pull 20 random Not a Fit rows: Read them. If any are obviously good, the filter is too tight.

    line 140
  8. Very specific:

    Competitor and PE-backed sweep: Search every bucket for the named competing platforms and for PE-backed ownership types.

    line 143
  9. Distinctive:

    If any audit fails, fix the rubric and rescore.

    line 150
  10. Very specific:

    Never delete Not a Fit rows: Keep them with their reason.

    line 190

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

Thesis Fit Scoring

Turns a raw target list into a qualified one. Removes the companies that can never trade, and separates the ones worth an owner's letter this month from the ones worth a revisit next year.

Read first, in full: references/scoring-rules.md. This skill is an application of that file. Do not improvise around it.

Also read: references/target-taxonomy.md.


Step 0 — Load

  1. Read thesis-profile.md. If missing, stop and set it up from templates/thesis-profile.md before doing anything else.
  2. Read targets.csv from the workspace.
  3. Count rows and report how many already have a fit_score.

Ask whether to score only unscored rows (default) or rescore everything. Rescoring everything is right after a rubric change and wasteful otherwise.


Step 1 — Build the rubric, in writing, before touching a row

Derive from the thesis profile and show it to the user as an explicit document.

RUBRIC — draft for approval

Size box:      revenue [range], EBITDA [range], EV [range]
               (rows with only labeled estimates are judged on the estimate,
               and the estimate basis stays visible in fit_reason)

Strong Fit requires: sector and subsector inside section 4
                     AND inside the size box (or labeled estimate inside it)
                     AND an actionable ownership type per target-taxonomy.md
                     AND a quoted signal from this list:
                     [signal keywords from the thesis profile]

Fit:                 sector, size box, and actionable ownership type,
                     no specific signal

Near Miss:           matches the thesis except one bounded miss — just
                     outside the size box, adjacent subsector, or geography
                     when the profile states a real constraint. Kept with
                     the miss named, for revisit.

Not a Fit — hard exclusions:
  1. Owned by a competing sponsor: [platforms named in market-map.md or by
     the user]
  2. Conflict with existing portfolio: competes with [portfolio companies
     from section 7]
  3. PE-backed (platform) or PE-backed (add-on), unless the thesis
     explicitly buys from sponsors
  4. Non-actionable ownership type: corporate-owned, public, VC-backed —
     per target-taxonomy.md, unless the thesis says carve-out
  5. Explicit exclusions from section 7
  6. Dead / parked domain

Signals that do NOT count:
  "family values", "trusted since 1985", awards badges, "industry-leading",
  website design quality, company name aesthetics

Not used as filters:
  headcount (never a proxy for revenue), website quality,
  geography (profile says No constraint)

🚧 HARD GATE

Show the rubric. The competitor definition and the size-box edges are the two that get it wrong most often. Ask specifically about those. Wait for approval.


Step 2 — Score

Apply the rubric identically to every row. Same order, every time.

For each row:

  1. Hard exclusions first. If any fires, mark Not a Fit, name the rule in fit_reason, and stop. Do not keep evaluating.
  2. Confirm ownership actionability per target-taxonomy.md. Founder-owned and family-owned are the core; a franchisee may not control a sale at all.
  3. Check the size box against published figures or labeled estimates. Never treat an estimate as a fact, and never silently tighten the box.
  4. Look for a quoted signal. Must be quotable, with a source URL. Generic longevity language does not count.
  5. Assign the bucket and write a one-sentence fit_reason that names the rule or the signal applied.

Consistency

Score in batches, applying the same written rubric to each batch. If you find yourself reasoning your way to an exception, that is a signal the rubric needs a line added, not that this row is special. Stop and propose the rubric change. Every rubric change re-runs the whole list.

When genuinely torn between Fit and Not a Fit

Choose Fit. Per references/scoring-rules.md, the expensive error is excluding a real target on thin information — a thin website is the normal face of a good private company. Choose Not a Fit only when a hard exclusion actually fired. Near Miss is for a named, bounded miss, not a dumping ground for uncertainty.


Step 3 — Fill these fields for every row

FieldRule
fit_scoreStrong Fit / Fit / Near Miss / Not a Fit. Never blank.
fit_reasonOne sentence naming the specific rule or signal. Never blank.
signalThe quoted phrase, or Not found.
signal_sourceURL, or Not found.
evidence_dateDate of the evidence, or Not found.

A row without a fit_reason is not scored. It is a guess wearing a label.


Step 4 — Audit before reporting

Mandatory. Run all four, report the results, do not skip because the numbers look fine.

  1. Verify 10 Strong Fit signals. Fetch the signal_source URL and confirm the quoted phrase is actually there. Report any that are not.
  2. Pull 20 random Not a Fit rows. Read them. If any are obviously good, the filter is too tight. This is the expensive failure and it is invisible unless you look for it.
  3. Competitor and PE-backed sweep. Search every bucket for the named competing platforms and for PE-backed ownership types. They belong in Not a Fit with the rule recorded — anywhere else is a rubric violation.
  4. Distribution sanity check. Expect roughly 15 to 30% Not a Fit on a well-built list. Much higher and the filter or the source list is bad; much lower and the competitor screen probably did not run.

If any audit fails, fix the rubric and rescore. Do not report a list you know is wrong.


Step 5 — Report

Scoring complete — 164 rows

  Strong Fit     27   (16%)
  Fit            84   (51%)
  Near Miss      21   (13%)
  Not a Fit      32   (20%)
  Actionable    111

Not a Fit breakdown:
  Owned by competing sponsor     9
  PE-backed (platform/add-on)    8
  Portfolio conflict             4
  Corporate-owned / public       6
  Explicit exclusion             3
  Dead domain                    2

Audit results:
  10 Strong Fit signals checked → 10 verified at source
  20 random Not a Fit reviewed  → 1 looked good (franchisee misread — fixed,
                                  rubric line 4 clarified, list re-run)
  Competitor / PE sweep         → clean after re-run
  Distribution                  → 20% Not a Fit, within expected range

Near Miss cluster: 14 of 21 sit just above the EBITDA ceiling

Next: founder-research on the 111 actionable rows.

Notes

  • Never delete Not a Fit rows. Keep them with their reason. It stops you re-researching the same company in three weeks, and it is how you audit the rubric.
  • Near Miss rows are an asset. A company just above the size box today may fit next year, or fit a larger fund. Revisit them; do not rescore them into Fit to pad the pipeline.
  • If the user disputes a score, they are usually right about their own market. Update the rubric, rescore, and note what changed. Do not defend the output.

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.