Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Lead desk: let a Grok Bot hunt leads while the office sleeps, and only pay Claude for the ones worth talking to

Open
#252 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
ai, backend

Research direction

Start with src/main/webhook.ts, which the issue identifies as the existing path for secret checks, schema validation, trigger mode, and status tokens. The proposed decision screen is new and spans provider configuration, routing, trigger history, and setup, so first trace how webhooks hand work to Michael. Done means the four screening paths in the issue are covered: above threshold routes, below threshold logs filtered scores, and low confidence or provider errors route normally.

Written by the indexing model from the issue text.

Description

enhancement
Problem / motivation

Hi Vivek and team,

I run an AI implementation agency, and my own lead gen runs on a pipeline I built: agents find and enrich prospects, a cheap scoring step throws out the bad ones, and only the good ones get a human sounding first touch. Reading through the packs with my own business in mind, the Sales Director is the teammate I'd lean on most, and it's also where the office is weakest today.

Dwight can only work with what lands in his mailbox, and only while my laptop is open. The leads I actually want come from LinkedIn, X, directories and company sites, and most of them have no API. Then every lead that does arrive costs a full Claude turn to read and judge, junk included. Rough math: a lead plus my ideal customer description is around 600 tokens, but an agent turn carries the role, the work style and memory with it, so judging one lead easily costs 15,000 tokens or more of plan. 500 leads a week is millions of tokens spent saying "no". That is the same plan budget #66 and #124 are fighting over.

The tools around this changed a lot in the last two months, and I think the app can use that instead of competing with it:

  • Grok Bot (xAI, beta since 11 August) gives you always on bots on their own cloud computer. They work through any website, no API needed, run routines on a schedule or a webhook, and Claude Code installs in their terminal on your own subscription. Great at hunting. But every bot on an account shares one computer and every login, and xAI's FAQ says outright not to treat separate bots as a security boundary. I would never give it my mailboxes.
  • Jev (TypeSafe, early access since September) answers typed questions about a record: a choice, a score or a yes/no, each with a probability. 70 to 500 ms, about $0.042 per million input tokens, and output is free because it never writes text. Those 500 leads cost about one cent to screen.

So the split I want is: let the cloud do the hunting, let a tiny model do the judging, and keep the trusted work inside Don't Be Michael, where each teammate only touches what the owner gave it. Grok Bot and Dots can't offer that last part, and I think it's the strongest selling point the app has.

Proposed solution

Three pieces. Only the middle one is new code.

  1. Leads come in through the webhook you already built. I create a "Leads" endpoint whose schema is a lead (name, company, role, email, source link, why they fit). src/main/webhook.ts already checks the secret, validates the schema, applies the TriggerMode and hands back a status token. A Grok Bot routine posts each lead it finds with one curl from its terminal. A Clay export, a web form or a business card scanner can post the same shape.

  2. A screen before Michael (new). Each webhook endpoint gets an optional "check before routing" step. It sends the payload plus the owner's ideal customer text to a decision model with three questions:

    • Choice: fits / doesn't fit / unsure
    • Score: 1 to 5, how ready this lead looks
    • Yes/no: does the email domain belong to the company
      Above the owner's threshold, it becomes a card and Michael routes it to the Sales Director as he does now. Below it, it is logged in the trigger history as filtered, with its scores, and Claude never sees it. Unsure or low confidence goes the normal way. A provider error also goes the normal way, so the screen can never lose a lead. Off by default, key in the existing secret store, and it lives behind one small interface (DecisionProvider) so the app isn't tied to TypeSafe.
  3. Follow up through what's already there. The Sales Director writes the first touch and follow ups from his own mailbox under Send on approval, and a schedule brings back anyone who hasn't replied.

One guardrail I care about: the screen can only remove work. It never sends, edits or grants anything. Jev can be pushed around by text injected into a payload, so the worst a poisoned lead can do is get itself filtered or reach Dwight like any other lead. It can't raise anyone's permissions.

How I'd test it

Piece 2 fits in one small PR. The tests would cover each path: routed above the threshold, filtered and logged below it, low confidence goes the normal way, and a provider error goes the normal way. The setup guide for pieces 1 and 3 can be its own PR.

Screenshot, mockup or recording
flowchart LR
  A[Grok Bot routine<br/>cloud, always on] -->|POST lead| B[Leads webhook<br/>secret + schema + TriggerMode]
  C[Clay export / form / card scanner] -->|POST lead| B
  B --> D{Decision screen<br/>Jev or Kev}
  D -->|fits, score >= threshold| E[Card for Michael]
  D -->|doesn't fit| F[History: filtered, with scores]
  D -->|unsure or error| E
  E --> G[Sales Director<br/>Send on approval]
Alternatives considered

Route B, fully open source and self hosted. Same shape, nothing proprietary:

  • Hunting: OpenClaw (MIT, any model including Claude, 24+ chat channels) or Hermes Agent (MIT, named bots that message each other) instead of Grok Bot.
  • Screening: Kev, which serves TypeSafe's /v1/systemone contract on Qwen3.5. Because it speaks the same API, switching from Jev to Kev is a base URL change in the DecisionProvider config and nothing else. Laya is the CPU friendly option (421M parameters) if an owner has no GPU, though it needs fine tuning to be good.
  • That's the version for owners who can't send customer data to a hosted model.

Let Claude judge every lead. Works today, but it burns the plan on leads that should never have reached the office.

Run the whole office on Grok Bot. Always on, but every bot shares every login, and the per teammate access control this app enforces is gone.

Keyword and domain rules. They catch spam. They can't judge fit.

Area

The hive (memory, routing, GOD agent)

Pre-flight
  • I attached a screenshot, mockup or recording above.
  • I searched existing issues and discussions, and this isn't a duplicate.
Dominant language
TypeScript
Stars
273
Forks
211
Avg merge
9h 17m
Merged PRs (30d)
162

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentvivekkumar/dontbemichael

All issues in agentvivekkumar/dontbemichael

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.