agentleFS
PitchdrivePitchdrive/investor-update-skill/SKILL.md

investor-update

Skill4 starsChanged 4 months agoMITView on GitHub

Draft a monthly or quarterly investor update for your startup — structured like the updates VCs actually enjoy reading. Use when the founder asks to write, prepare, or send an investor update. Pulls KPIs from connected tools when available, asks for numbers when not, tracks commitments between updates, and renders a polished markdown (and optional single-page HTML) update.

7 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

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

    Look for previous updates in investor-updates/ (or ask where they live).

    line 15
  2. Very specific:

    Read investor-updates/commitments.md (the primary source), cross-checked against the previous update's text for anything the log missed.

    line 27
  3. Distinctive:

    Check which of these are reachable before asking the founder to type anything (MCP servers, CLIs, or APIs already configured in this …

    line 35
  4. Distinctive:

    Never invent a number. A missing metric is stated as missing or omitted — a fabricated one destroys the update's entire value.

    line 54
  5. Distinctive:

    No filler sections. "Nothing significant this month" is a legitimate, respected line.

    line 97
  6. Distinctive:

    No website or no clear brand?

    line 116
  7. Distinctive:

    Never block the update on branding — markdown ships regardless.

    line 117
  8. Distinctive:

    Before anything is sent anywhere: show the founder the full draft and wait for approval.

    line 127
  9. Distinctive:

    here.now — minimal setup: If no hosting is connected, publish the single HTML file to here.now (docs: here.now/docs).

    line 137
  10. Very specific:

    After approval, append to investor-updates/commitments.md: every commitment, target, and ask made in this update, with the date.

    line 164

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “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

Investor Update

You are helping a founder write an investor update that investors will actually read. The best updates share three traits: real numbers (not adjectives), honest follow-through (last update's promises, revisited), and clear asks. Your job is to collect the data with as little founder effort as possible, then write in THEIR voice.

Step 0 — First update, or continuity?

Look for previous updates in investor-updates/ (or ask where they live).

Most founders arrive here for their FIRST update — that's the happy path, not an error. In that case: create investor-updates/, then gather (or infer from the repo/docs/website) the basics in one short exchange: company one-liner, stage, last round, and roughly how many investors receive the update. Save these to investor-updates/company.md so no future update ever re-asks. Tell the founder that from next month onwards the skill will automatically hold them to whatever they promise today — that loop starts now, and it's the feature investors end up valuing most.

From the second update onwards, continuity is mandatory:

  1. Read investor-updates/commitments.md (the primary source), cross-checked against the previous update's text for anything the log missed.
  2. Extract the previous asks and whether they were answered.
  3. The new update MUST revisit each commitment explicitly: done / partial / missed. Investors trust founders who track their own promises — never silently drop one.

Step 1 — Discover data sources, then ask for the gaps

Check which of these are reachable before asking the founder to type anything (MCP servers, CLIs, or APIs already configured in this project — check whatever connector/tool list your platform exposes before asking):

DataTypical sourcesFallback
Revenue, MRR/ARR, billingStripe, Chargebee, Paddle, Polar, Molliefounder pastes monthly numbers
Pipeline, new logos, win rateHubSpot, Salesforce, Attio, Pipedrivefounder pastes deal counts
P&L, opex, marginsQuickBooks, Xero, Exact Online, Yuki, Silverfin, Odoo, NetSuite, or a finance sheet (CSV/Sheets)founder pastes P&L lines
Cash & runwayMercury, Brex, Qonto, Ramp, Agicap, bank export (CSV)founder pastes cash + burn
Product/engineering velocityLinear, GitHub/GitLab, Jira (issues, merged PRs, releases)founder summarizes shipped work
Usage/ops KPIsanalytics (PostHog, Amplitude, GA), Metabase/internal dashboardsfounder pastes 2–4 north-star numbers
TeamHRIS (Personio, HiBob) or just the founderheadcount now / next month

For each source that is NOT connected, offer the founder a choice:

  • Connect it (point them to their platform's MCP/connector setup for that tool), or
  • Paste the numbers — then ask for exactly what's missing, in one compact list, not twenty questions. Respect their time: one message, all gaps.

Never invent a number. A missing metric is stated as missing or omitted — a fabricated one destroys the update's entire value. If a number looks off by 10x from last update, query it once before using it.

Step 2 — The structure

Eight numbered sections. Skip any that genuinely don't apply, keep the order:

  1. CEO update — 3–6 paragraphs, first person, the month's story. Open with the single most important fact (a number, a launch, a miss). Include a short "what I said last month → what happened" block (from Step 0). End with the one thing you're focused on next.
  2. Financial update — monthly revenue table (last 6 months), gross margin, EBITDA or burn, opex by department if available, cash position + runway in months. Numbers first, one paragraph of interpretation after. Bad months get stated plainly, with the why.
  3. Product — what shipped, why it matters, early results with real measurements. A small "what changed / why" table reads better than prose for structural changes.
  4. Engineering / velocity — shipped issues, releases, notable epics; team size; what this unlocks next quarter. Keep it honest: velocity numbers without context are vanity; tie them to what customers got.
  5. Team — headcount now → next month, key hires or departures, hiring plan or freeze (with the reasoning — investors read a freeze as discipline when explained, as trouble when discovered).
  6. Culture / how we operate (optional, occasional) — only when something structurally changed. A values rewrite or a reorg belongs here; a team offsite does not.
  7. Strategy — where the company is heading beyond this month; the bet you're making and the 2–3 north-star metrics that will prove it right or wrong.
  8. Forecast & asks — revenue forecast for the coming months (actuals vs projections, clearly separated), fundraise timing/sizing when relevant, and standing asks: specific, answerable requests (intros to named funds or profiles, candidate referrals, customer intros). Vague asks get zero replies; specific asks get answered.

Close with a confidentiality line, e.g. "Confidential — please do not distribute."

Step 3 — Voice and craft rules

  • First person, founder's voice. Read 2–3 paragraphs of their previous updates or writing and match it. When in doubt: plain, direct, warm.
  • Numbers over adjectives: "€204K, our best month" beats "an amazing month".
  • Bad news in the first sentence of its section, never buried. Investors fund people who surface problems early; the update is where that reputation is built.
  • Data attribution in small footnotes (which system each number came from, and the date).
  • Length: 400–1,500 words for a normal month. Heavy months (launch, reorg, fundraise) earn more; quiet months should be short and say so. Never pad to seem thorough.
  • No filler sections. "Nothing significant this month" is a legitimate, respected line.

Step 4 — Brand discovery (for the HTML version)

The shareable page should look like THEIR company, not like a template. Before rendering HTML:

  1. Founder-provided brand assets (logo file, hex codes, font name) are the PRIMARY path — ask first, it's one message. Otherwise fetch the company website's raw HTML/CSS source (not a rendered/markdown view — colors live in the source) and extract logo, primary + accent colors, and font family. If the source isn't readable, ASK — never guess brand colors; a wrong brand color is a fabrication like any other.
  2. Show the founder a one-line brand summary — "logo ✓, primary #1A2B3C, accent #FF5A36, font Inter — correct?" — and let them adjust or hand over real brand assets instead.
  3. Apply it to the HTML: logo in the header, accent color for metric callouts and the revenue chart, their font with safe fallbacks. Keep body text high-contrast and readable — brand accents decorate, they never carry the reading experience.
  4. No website or no clear brand? Fall back to a clean neutral theme and say so. Never block the update on branding — markdown ships regardless.

Step 5 — Render and save

  1. Save the update as investor-updates/YYYY-MM.md, where YYYY-MM is the month the update REPORTS ON (an update about March, written in April, is 2026-03.md).
  2. Offer a single-file HTML version for sharing as a link: clean typography, anchor navigation for the 8 sections, metric callouts in large type, a simple revenue bar chart (inline SVG or styled divs — no external JS dependencies), confidentiality footer. Keep it self-contained so it can be dropped on any static host.
  3. Before anything is sent anywhere: show the founder the full draft and wait for approval. You draft; the founder sends.

Step 6 — Publish (after approval)

Offer to put the HTML version online, in this order of preference:

  1. The founder's own hosting, when a deploy path is already configured in the project (Vercel, Netlify, GitHub Pages, their own server) — use it; the update lives under their domain.
  2. here.now — minimal setup. If no hosting is connected, publish the single HTML file to here.now (docs: here.now/docs). Per their docs, a free API key makes pages permanent with password protection or invite-only access — use one of those two modes for an investor update, always. NEVER use the anonymous no-account tier for the update itself: those links expire after 24 hours, and an investor opening a dead link two days later is the worst possible impression. Verify the published page loads before handing the founder the link. (A helper skill exists — heredotnow/skill — but don't install packages mid-session while handling confidential financials; suggest it for next time instead.)

Confidentiality rules for publishing, always said out loud to the founder:

  • An unlisted link is NOT private — anyone who receives it (or a forward of it) can read the numbers. For anything sensitive, prefer password or invite-only access, or skip hosting and attach the markdown (or a PDF printed from the HTML) instead.
  • Repeat the access choice back before publishing ("public link / password / invite-only — which one?") and never publish without the founder's explicit go.

Step 7 — Draft the cover email

Founders don't send a bare link — they send a short email around it. Draft it: 3–5 sentences, founder's voice, the single headline number or event, one line on what's inside, the link (or attachment), and the one ask that matters most this month. Subject line: "{Company} — {Month} investor update". Show it next to the update for approval; the founder sends it from their own mailbox.

Step 8 — Log the promises

After approval, append to investor-updates/commitments.md: every commitment, target, and ask made in this update, with the date. That file is Step 0's input next month — the loop that makes updates trustworthy.

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.