agentleFS
NachoLafuenteNachoLafuente/5050-gtm/skills/disco-prep/SKILL.md

disco-prep

Skill3 starsChanged 5 months agoMITView on GitHub

Generate a tight pre-discovery-call prep brief from an intro email, referral, or company name. Outputs a 3-section scan doc (who they are, ranked questions, proof to drop) you can read in the two minutes before a sales or consulting call. Use when the user says "/disco-prep", pastes an intro email, or asks to "prep for the disco call", "what should I ask", or "disco agenda". Output goes to the chat, not a file. One-shot, no warehouse, no cron.

The file

Show its rules and text

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If you don't have a company domain, ask before researching.

    line 18
  2. Distinctive:

    Specific, not generic: Every question references THIS prospect's context.

    line 27
  3. Distinctive:

    Short sentences. No fluff: Don't restate what the email already said.

    line 30
  4. Distinctive:

    Only state facts that appear in the source material (email, notes, research).

    line 34
  5. Distinctive:

    Do not infer timelines, deal volume, or team size unless explicitly stated.

    line 35
  6. Distinctive:

    If the source is silent on something, it becomes a must-ask question, not a claim.

    line 37
  7. Distinctive:

    When tempted to extrapolate ("this means they probably want X by Y"), stop and turn it into a question instead.

    line 38
  8. Very specific:

    Exactly 3 sections: Use ## N. Section Name headers.

    line 42
  9. Distinctive:

    Keep a simple match map by vertical (e.g.

    line 76
  10. Distinctive:

    Output to chat only: Never write to a file.

    line 80
  11. Distinctive:

    No invented facts: If it's not in the source, it's a question, not a claim.

    line 82
  12. Distinctive:

    No generic questions: Every Q references something specific from the intro.

    line 83
  13. Distinctive:

    Tag the stakeholder: when multiple are on the call.

    line 84
  14. Distinctive:

    Cap total output ~350 words: If over, cut.

    line 85

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

Discovery Call Prep

Generate a pre-discovery-call prep brief from an intro email, referral, or company name. The deliverable is markdown in the chat, not a file. The goal: walk into the call already knowing who they are, what to ask, and which past win to drop as proof.

This is a scan doc, not a report. Target output: under 350 words. If you're padding, cut.

Input

The user provides some combination of: an intro email, a company name + domain, prior notes, a LinkedIn profile, or a vague "call with X tomorrow."

Extract: contact name, company, stakeholders on the call, referrer, stated needs, tools mentioned, numbers (size, volume).

If you don't have a company domain, ask before researching. Do not hallucinate.

Pre-Flight (before writing anything)

  1. Research. Web-search the domain + recent news (last 6 months). Fetch the homepage. Look up named stakeholders.
  2. Match to past work. Skim your own notes/CRM for analogous clients to anchor the proof in Section 3. Keep a short list of past wins by vertical wherever you keep it.

Voice & Quality Bar

  • Specific, not generic. Every question references THIS prospect's context. No "what's your tech stack?"
  • Diagnostic, not polite. Each question shapes scope.
  • Cut ruthlessly. A disco call is 30 to 45 min. Pick the questions that matter most.
  • Short sentences. No fluff. Don't restate what the email already said.

Do not invent

  • Only state facts that appear in the source material (email, notes, research).
  • Do not infer timelines, deal volume, or team size unless explicitly stated.
  • "Eventually" / "down the line" / "future" = NOT a commitment. Treat as parking-lot.
  • If the source is silent on something, it becomes a must-ask question, not a claim.
  • When tempted to extrapolate ("this means they probably want X by Y"), stop and turn it into a question instead.

Output Format

Exactly 3 sections. Use ## N. Section Name headers. Be terse.

Header block (above section 1)

> Disco Prep: {Company}
> Call with: {stakeholders + roles}
> Referrer: {referrer or "direct inbound"}
> Prepared: {today's date}

1. Who They Are (30-sec read)

2 sentences max. Company type, size, geography, what they do. One bonus line ONLY if there's a non-obvious signal that shapes the call (recent funding, new hire, founder background, returning client). Otherwise stop at 2.

2. Questions to Ask, Ranked

Cap at 8 total. 5 must / 3 should. Each = one line, with a short why in italics. Tag the stakeholder if several are on the call.

Must-ask (5, scope-defining). Cover the gaps that block writing a proposal: who consumes the output, what's in scope, which tools/systems are involved, hard timeline, decision maker. Anything you were tempted to assume goes here as a question instead.

Should-ask (3, shapes design). Pipeline stages, notification routing, reporting cadence, integration triggers, ops handoff specifics.

Format: **Q:** "actual question phrasing" (*why it matters*)

3. Proof to Drop

1 past win only. Pick the strongest match.

- {Past client or anonymized}, {one-line situation match} -> {one specific metric or outcome}
  When to drop: {minute X / on objection Y}

Keep a simple match map by vertical (e.g. VC/PE -> your fund client, gym/SaaS -> your churn client) so you reach for the right proof fast.

Rules

  1. Output to chat only. Never write to a file.
  2. Pre-flight first. Research before writing.
  3. No invented facts. If it's not in the source, it's a question, not a claim.
  4. No generic questions. Every Q references something specific from the intro.
  5. Tag the stakeholder when multiple are on the call.
  6. Cap total output ~350 words. If over, cut.
  7. Three sections only. Who -> Questions -> Proof. No agenda, no hypothesis, no red-flags section.

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.