agentleFS
CodeAlive-AICodeAlive-AI/ceo-ai-os/skills/discovery-debrief/SKILL.md

discovery-debrief

Skill9 starsChanged 6 months agoMITView on GitHub

Structured debrief AFTER a customer conversation — extract learnings, update hypotheses, track demand signals. Use when the founder says "talked to a customer". For preparing and planning interviews beforehand, use conducting-user-interviews.

1 other project uses a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 11 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    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 MEMORY.md — current wedge, ICP, constraint

    line 17
  2. Very specific:

    Read memory/hypotheses.json — active hypotheses

    line 18
  3. Distinctive:

    Ask: "Who did you talk to?

    line 19
  4. Distinctive:

    After the founder's free-form story — extract structured data.

    line 25
  5. Distinctive:

    Look for behavioral evidence, not words:

    line 35
  6. Distinctive:

    Look for the specific workflow:

    line 46
  7. Distinctive:

    If confirms/refutes — what specific evidence?

    line 88
  8. Distinctive:

    Divergence signal: every customer wants something different -> wedge is blurry, need to narrow.

    line 102
  9. Very specific:

    Update memory/hypotheses.json if there is hypothesis impact

    line 120
  10. Very specific:

    Update MEMORY.md if any of these change: ICP, wedge, positioning, PMF stage

    line 121
  11. Distinctive:

    If < 4 -> "Priority: more conversations, less code"

    line 129
  12. Distinctive:

    If the conversation was not with target ICP -> note: "This conversation is outside the current wedge.

    line 130
  13. Distinctive:

    Follow output preferences from USER.md (language, format, platform constraints).

    line 148
  14. Distinctive:

    Don't assess until all 5 points (1.1-1.5) are collected.

    line 154
  15. Distinctive:

    If the founder retells superficially -> push: "What exactly did they say?

    line 155

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

Structured extraction after a customer/prospect conversation. Every conversation is data. This skill turns conversations into actionable learnings.

Triggers: "talked to a customer", "customer call", "debrief", "discovery call", "had a call with...", "met with..."


Step 0: Context

  1. Read MEMORY.md — current wedge, ICP, constraint
  2. Read memory/hypotheses.json — active hypotheses
  3. Ask: "Who did you talk to? Tell me in free form."

Step 1: Structured Extraction

After the founder's free-form story — extract structured data. Ask clarifying questions ONE AT A TIME (don't batch).

1.1 Who

  • Name, role, company, team/company size
  • How the contact was established (inbound/outbound/referral)
  • Buyer or user? (often different people)

1.2 Demand Reality (is demand real?)

"Would this person be upset if [YOUR_PRODUCT] disappeared tomorrow?"

Look for behavioral evidence, not words:

  • Paying or willing to pay? How much?
  • Using the product? How often?
  • Building workflow around the product?
  • Would scramble if the product vanished?

Red flags: "interesting", "need to think about it", "show it to my colleagues" — this is politeness, not demand.

1.3 Status Quo (what are they doing now?)

"How do they solve this problem today — even poorly?"

Look for the specific workflow:

  • What tools/processes do they use?
  • How much time/money do they spend?
  • Who does it manually?
  • What breaks in the current process?

Red flag: "they don't do anything" -> the problem may not be painful enough.

1.4 Narrowest Wedge (minimum product for money)

"What is the smallest version of [YOUR_PRODUCT] they would pay for right now?"

Not "the full platform", but one workflow, one integration, one use case.

1.5 Surprise (what was unexpected?)

"What in this conversation didn't match your expectations?"

Surprise = the most valuable signal. If there are no surprises — either wasn't listening or confirming bias.

Gold: customer uses the product in an unintended way -> that might be the real product.


Step 2: Signal Assessment

Assess signal strength using Evidence Tiers (CEO Bible):

TierEvidence typeStrength
1Pays, expands, integrated, renewedStrongest
2Session replays, drop-offs, support ticketsStrong
3Win/loss, objections, stalled dealsMedium
4Market narrative, competitor moves, contentWeak
5Praise, vanity traffic, investor excitementNear zero

Classify: "This conversation yielded tier [X] evidence: [specifically what]"


Step 3: Hypothesis Check

For each active hypothesis from memory/hypotheses.json:

  • Does this conversation confirm, refute, or remain neutral?
  • If confirms/refutes — what specific evidence?

Relay Race check: is there a hypothesis with enough evidence for a decision RIGHT NOW? If yes -> flag: "H00X has sufficient data. Decide now, don't wait for the deadline."


Step 4: Pattern Detection

Compare with previous conversations (from daily logs):

  • Same pain recurring? (repeated pain -> strong signal)
  • Same trigger? Same workaround?
  • Same buyer profile? Or different people with different problems?

Convergence signal: 3+ conversations with same pain, same trigger, same workaround -> wedge is clarifying. Divergence signal: every customer wants something different -> wedge is blurry, need to narrow.


Step 5: Save

  1. Log to memory/YYYY-MM-DD.md via structured-log:
## Discovery: [Company] — [Name, Role]
- **Source:** inbound/outbound/referral
- **Demand:** [tier X] — [evidence]
- **Status quo:** [what they do now]
- **Wedge fit:** [high/medium/low] — [why]
- **Surprise:** [what was unexpected]
- **Hypothesis impact:** [H00X: confirms/weakens/neutral]
- **Next step:** [concrete action]
  1. Update memory/hypotheses.json if there is hypothesis impact
  2. Update MEMORY.md if any of these change: ICP, wedge, positioning, PMF stage

Step 6: Constraint Nudge

Close the debrief with a reminder:

  • "Qualified conversations this week: X out of target 8-12"
  • If < 4 -> "Priority: more conversations, less code"
  • If the conversation was not with target ICP -> note: "This conversation is outside the current wedge. OK for exploration, but don't count as qualified."

Telegram Format

Discovery: [Company] — [Role]

Demand: Tier [X] — [1 line evidence]
Status quo: [what they do now]
Surprise: [what was unexpected]
Hypothesis: H00X [confirms/weakens]

Conversations: X/8-12 this week
Next: [concrete action]

Follow output preferences from USER.md (language, format, platform constraints).

Rules

  • One question at a time. Don't batch.
  • Quote exact customer words when possible — customer's words > founder's interpretation.
  • Don't assess until all 5 points (1.1-1.5) are collected.
  • If the founder retells superficially -> push: "What exactly did they say? In what words?"

Related Skills

  • meeting-prep — pre-meeting intelligence briefing (the complement: before vs after)
  • pipeline-manager — update prospect stage and notes after debrief
  • outreach-sender — schedule follow-up outreach after discovery
  • hypothesis-tracker — update hypotheses with conversation evidence
  • structured-log — log debrief findings to daily memory
  • conducting-user-interviews — preparing and planning interviews (before, not after)
  • founder-sales — overall sales strategy and discovery techniques

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.