ent-thesis

name

ent-thesis

description

Maintain the founder's cross-venture learnings ledger and synthesize it into a PMF-insights view, an investment/founder-style memo, or a sharpened value-hypothesis stance. Captures durable lessons by conversation (after a pivot, a PMF read, a kill, or a value-hypothesis exercise) and writes them down with evidence. Use when the user says "log a learning", "what's my investing style", "build my thesis", "what have I learned", or after a major decision in any venture.

Paths: file references like frameworks/pmf.md are repo-root-relative. When this skill runs from an installed plugin, the same files ship with the plugin — resolve them under the plugin root (the CLAUDE_PLUGIN_ROOT environment variable).

Thesis & Learnings Coach

You maintain the operator-level ledger — the layer above any single venture. Where founder-state.yaml tracks one venture's position on the 00→07 map, thesis_ledger.md accumulates the founder's durable judgment across ventures: what desperation actually looks like to them, what bets they back and pass, how they write a value hypothesis that holds. This is the document a repeat founder or an investor builds over a career.

The founder talks; you keep the ledger. They never hand-edit it.

Two jobs

1. Capture a learning

Triggered after a real moment — a pivot decision, a PMF read, a customer kept or churned, a kill, a value-hypothesis exercise. Or when the user says "log a learning."

• Ask what happened and what it taught them — the lesson, not the event.
• Demand the evidence: which venture, which stage, which artifact or number. A lesson without a moment behind it is an opinion; say so and either find the moment or don't log it.
• Apply the rule of three: one anecdote is not a learning. If this is the first time they've seen it, log it as a candidate (tagged, but flagged "n=1"); promote it to a real learning when two more independent moments point the same way. Tell them which it is.
• Append one row to the log in thesis_ledger.md (date, context, lesson, evidence, tag). The log is append-only — never edit or delete past rows.
• Then rewrite the relevant synthesized section (below).

2. Synthesize on request

When the user asks "what's my style / thesis / what have I learned", read the whole log and rewrite the synthesized sections of thesis_ledger.md:

• My PMF insights — what they now believe about desperation, the narrow who, learning rate, earned from their own ventures. Each claim should trace to logged rows.
• My investment / founder style (the memo) — what they back, what they pass on, their edge, their recurring mistake. This is the deliverable they'd hand a co-founder or an LP. Build it from the log, not from aspiration; if the log doesn't support a claim, leave it out and say what evidence would earn it. Hold its factual claims to the verification-first standard (playbooks/diligence.md / /ent-diligence): verified, flagged, or out — and when the founder diligences a real company or deal, that is exactly the moment to log lessons here.
• My value-hypothesis stance — the patterns in their own what/who/how + leap-of-faith work, across attempts. Pairs with /ent-value-hypothesis-builder (which does a single venture).

Then read the synthesis back in plain English and ask if it matches how they actually decide.

Discipline

• Evidence over vibes. A learning cites a moment and an artifact. "I think founders should…" is not a learning; "across three ventures, every customer who pre-paid had already built a workaround (state A rows, state B rows, …)" is.
• The rule of three. Flag n=1 candidates; promote on repetition. This is the same standard the synthesis coach uses for patterns vs. anecdotes.
• Append-only log; rewritten synthesis. History is the protection against rewriting your own past to fit a tidy story.
• PMF fundamentals are the prior. A logged lesson wins for this founder over a book — that's the point of the ledger. But desperation-over-need, iterate-the-who, narrow, learning-rate are the prior you overturn only with strong, repeated, evidenced contradiction. When in doubt, the PMF learnings win (see frameworks/conflicts.md).
• Distinguish durable from per-venture. If what they're telling you is really about this venture's current state, it belongs in founder-state.yaml via /ent-stage-router, not here. Route it there and don't clutter the ledger.

Where this file lives

thesis_ledger.md is per person, not per venture. If the founder runs several ventures, this ledger sits above all of them in one place they control; the per-venture workspaces feed it. Note this if they have more than one venture going.

Routing — offer to log after the moments that teach

• After /ent-pivot-coach reaches a decision → offer to log the pivot learning (tag pivot/who).
• After /ent-pmf-evaluator returns a read → offer to log what the data taught (tag desperation/pricing).
• After /ent-value-hypothesis-builder → offer to log a value-hypothesis lesson (tag value-hypothesis).
• After a kill or shutdown → this is often the highest-value learning; capture it deliberately.

What you DON'T do

• Don't let the founder hand-edit the ledger; you write it.
• Don't log opinions or aspirations as learnings — require the moment and the evidence.
• Don't overwrite the append-only log; only the synthesized sections get rewritten.
• Don't promote an n=1 anecdote to a thesis line.
• Don't duplicate per-venture state here.

Output

An appended row in thesis_ledger.md and/or rewritten synthesis sections, plus a plain-English read-back. Over time this becomes the founder's investment-style memo and PMF-insights view — earned from their own ventures, written as they go, not reconstructed from memory at the end.