beam-ai-team/prospect-brief

Prospect Brief Skill

Build a fully rendered, client-branded 6-slide PDF commercial brief + cover email for a new Beam AI prospect. Same format as Julius Baer (101) and kaykroo (102) — see those project outputs as the quality bar.

Safety Contract

Before researching a prospect, creating configs, rendering PDFs, or drafting cover emails, show the company, contact, research sources, output paths, and any private outreach context included. Require explicit user approval in the current turn before writing files or preparing external-send drafts. Do not send emails, update CRM, or contact prospects from this skill.

Render stack

• render.py — generic engine, takes a config dict
• base.css.template — CSS template, colors injected from config
• configs/{prospect}_config.py — all content + theme per prospect
• Output: Beam AI x {Company} - Commercial Brief.pdf
• Python to use: /opt/homebrew/bin/python3.14 (has weasyprint)
• Run: /opt/homebrew/bin/python3.14 render.py configs/{prospect}_config.py [output_dir]

Workflow

Step 1: Gather inputs

Ask the user for (or extract from their message):

• Company name
• Target contact: name + role
• Company website or LinkedIn URL (optional but useful)
• Any context already known (sector, pain point, size)

If the user has already described the account, skip asking and proceed.

Step 2: Deep research (spawn 2 agents in parallel)

Run both agents at the same time. Do not wait for one before starting the other.

Agent A — Company intelligence:

You are a B2B sales researcher building a pre-call intelligence file on a prospect.
Research [COMPANY] + [CONTACT NAME] ([ROLE]) as deeply as public sources allow.

COMPANY — find and return all of the following:
  1. Sector, sub-sector, business model, revenue model (SaaS / product / services / marketplace)
  2. Geography: HQ, operating markets, recent or announced expansion
  3. Scale: employee count, customer count, revenue band or confirmed ARR (cite source)
  4. Funding / ownership: stage, latest round, investors, or if bootstrapped/PE-backed
  5. Tech stack: any named ERP, HRMS, finance system, CRM, BI tool, cloud provider — search
     their job listings, G2/Capterra reviews, LinkedIn jobs section, Crunchbase, BuiltWith
  6. Recent news (last 6 months): acquisitions, new markets, leadership changes, expansion announcements,
     layoffs, funding, regulatory actions — anything that changes the buying context
  7. Known pain points: from press releases, job listings, Glassdoor, LinkedIn posts by leadership,
     conference talks, interviews — what operational problem are they publicly trying to solve?
  8. Competitors: who do they compete with, what is their differentiation
  9. Buying signals: is there any evidence of AI/automation investment? ("We're hiring a Head of AI",
     "We're deploying Copilot", etc.)

CONTACT — find and return:
  10. Career history (current + prior 2 roles, tenure at each)
  11. Education
  12. LinkedIn URL if findable
  13. Any public writing, interviews, conference talks — what themes do they care about?
  14. What is their likely day-to-day focus given their role at [COMPANY]?

VALUE QUANTIFICATION — find numbers that can go directly onto the brief:
  15. Operational volume proxies: how many invoices/month, hires/year, reports/quarter,
      transactions/day — anything that sizes the manual work. Look in job listings
      ("process 500+ invoices weekly"), annual reports, investor presentations, press interviews.
  16. Headcount proxy for the bottleneck: how many people currently do this manually?
      (Job listings often name the team. "AP team of 3", "compliance team of 8")
  17. Financial/operational metrics that frame the gap: cost ratios, efficiency targets,
      benchmark numbers they've disclosed. E.g. a bank's cost/income ratio and public target.
      For a fast-growing startup: burn rate or headcount growth vs revenue.
  18. Sector benchmarks if company-specific data is unavailable: industry average for
      how long this process takes manually, typical error rates, compliance costs as % of OpEx.
      Cite the source (McKinsey, Deloitte, KPMG, trade association, analyst report).
  19. Growth multiplier: what makes the problem worse as they scale?
      (More kitchens = more supplier invoices non-linearly. More AUM = more KYC cycles.
      More countries = more compliance overhead.) This is the urgency logic for slide 2.
  20. Derived value estimate: given the above, estimate the rough annual cost of the bottleneck
      in hours or headcount equivalent, and the potential upside (capacity freed, cycle time
      reduced, error cost avoided). This does NOT need to be a precise ROI — it's the order
      of magnitude that informs the stat card choices.

BEAM FIT — synthesize:
  21. The top 3 back-office processes at [COMPANY] where Beam agents would have the highest ROI,
      ranked by a combination of: volume of work, current manual headcount, and urgency
  22. The sharpest single pain angle for [CONTACT]'s role specifically — what keeps them up at night
  23. Why now: what about their situation (funding, expansion, headcount pressure, regulatory change)
      creates urgency that did not exist 6 months ago

Search LinkedIn, the company website, Crunchbase, PitchBook free tier, G2, BuiltWith,
tech stack job listings, news archives, annual reports, investor presentations, and trade press.
Return a structured report with source citations. Do not fabricate numbers — if you cannot
find a specific number, say so and offer the best available proxy with its source.

Agent B — Brand color research:

Find [COMPANY]'s primary brand color.
Check in order: company website (inspect CSS or meta tags), press kit / media kit page,
brand guidelines page, LinkedIn company header, app store screenshots, Crunchbase logo.
Return:
  - Primary hex color (e.g. "#D4491A")
  - Darker variant (20-30% darker, for gradients)
  - RGB values as "R, G, B" string
  - Whether a logo SVG or PNG is available for download, and if so the URL
If no strong brand color found, return a suggestion appropriate for their sector
(finance → navy/slate; food → warm orange/red; tech → blue/indigo; health → green/teal).

Wait for both agents. Synthesize into a single intelligence summary before proceeding.

Research quality bar: The brief's stat cards need real numbers. Before writing the config, you must have at least:

• One specific operational metric (volume, headcount, ratio, or cycle time) for the pain area
• A quantified "why it gets worse as they scale" argument
• An order-of-magnitude value estimate (hours saved, capacity freed, cost avoided)

If Agent A cannot find these, do NOT guess or use round-number placeholders. Run additional targeted searches (annual reports, investor decks, job listings, trade press) or ask the user directly. A brief with fabricated stats is worse than no brief.

Step 3: Create project folder

# Find next project number
ls 03-projects/ | sort -V | tail -5

# Create
mkdir -p 03-projects/{ID}-{prospect}/04-outputs

Step 4: Determine theme + source logo

Colors (from Agent B + your judgment):

• accent: primary brand color hex (e.g. "#D4491A")
• accent_dark: 20-30% darker variant for gradients
• accent_rgb: the rgb values as "R, G, B" string (e.g. "212, 73, 26")
• accent_tint_1: rgba(R,G,B,0.07) for slide background
• accent_tint_2: a complementary warm tint at 0.06 opacity

IMPORTANT — light brand colors (yellow, lime, cyan, pale orange): The slides sit on a cream background (#F8F5EE), and accent does double duty: it colors small text (eyebrows, bullets, headline em-highlights) AND fills the solid dark box on slide 4 that carries white text. A light brand color breaks both — light text on cream is unreadable, and white text on a light box is unreadable. So when the true brand color is too light to read as small text:

• Set accent to a DARK brand-appropriate color (near-black, or the brand's dark secondary) so all structural elements stay legible. Most brands with a light primary also have a dark logo color — use it (e.g. kaykroo's letterforms are near-black #0C0F16).
• Put the light brand color in the BACKGROUND via accent_tint_1/accent_tint_2 (e.g. rgba(255,209,75,0.15)) so the slides still carry a branded wash, and let the real logo carry the brand identity in the header.
• Set brand_pop to a DEEPER, READABLE version of the brand color (e.g. kaykroo yellow #FFD14B → gold #D4A017). This colors ONLY the large cover word {mark}, where the 144px size makes the deeper brand color legible and gives the cover real brand punch.
• brand_pop is optional and defaults to accent. Only set it for light-brand prospects; for dark/mid brand colors (navy, red, teal) leave it out and the cover mark uses accent.
• kaykroo is the canonical example of this whole pattern — copy its theme block.

Logo sourcing — ALWAYS AUTO-FETCH the prospect's logo (mandatory):

The header shows the prospect's real logo in the upper-left, next to the Beam mark. This is not optional and it is not a wordmark by default — every brief must try to fetch the real logo.

Run the bundled fetcher (it tries Clearbit CDN → Wikimedia SVG → the company's own site, and saves the first usable hit with the correct extension):

python3 fetch_logo.py "{Company}" \
  03-projects/{ID}-{prospect}/04-outputs/assets/{slug}-logo \
  --domain {their-domain.com}

• Pass the prospect's real domain from Agent A's research as --domain (this is what makes Clearbit and the site-scrape work). Omit only if unknown.
• On success it prints the saved path (e.g. .../{slug}-logo.svg). Set in the config: logo_type: "image" and logo_image: "<that absolute path>".
• Only if it prints WORDMARK_FALLBACK (nothing usable found after all sources) do you set logo_type: "wordmark" with logo_wordmark: "{Company}".
• If an official logo already exists in assets/logos/{slug}.svg|png, you may use that directly instead of fetching.
• Open the fetched file to sanity-check it isn't a 1x1 tracking pixel or a generic favicon before committing to it. Header logo renders at 32px tall, auto width — any aspect ratio is fine.

WeasyPrint logo gotchas (learned the hard way — do not skip):

• Path-based SVG or PNG only. WeasyPrint does NOT reliably render SVG <text> elements (they silently disappear or misplace). Real brand SVGs from Wikimedia/company sites are path-based and work great. If you must hand-build a logo, use <path>/<rect> shapes, or just download the PNG — PNG renders perfectly (BID-Coburg uses a .png and looks clean). NEVER hand-write an SVG wordmark using <text> and expect it to render.
• Check the viewBox/transform. A logo that shows as a tiny fragment usually has a viewBox that crops it (Zurich had this). Download the full official file rather than trimming.
• Match logo_class to the logo's aspect ratio (see proof cards below): tall for square/circular marks (VW roundel), wide for horizontal wordmarks (Zurich, Porsche, BID). A wide logo forced into a square box renders tiny, and vice versa.
• curl works from the shell for downloads. Wikimedia's API resolves the real file URL: curl -sL "https://commons.wikimedia.org/w/api.php?action=query&titles=File:NAME.svg&prop=imageinfo&iiprop=url&format=json"

Step 5: Write the config

Create skills/general/prospect-brief/configs/{prospect}_config.py. Follow the CONFIG schema exactly (see kaykroo_config.py as the reference).

Key content decisions:

• Opportunity slide: use 3 stat cards with specific numbers from research
• Pillars: always 3, always ordered from highest value first. Mark the top one with "highlight": True
• Proof cards: select from proof-bank.md — use the sector → best proof card mapping table. All logos are SVG wordmarks in assets/logos/. Do NOT cite Oakberry, KFH Bahrain, or Americana Restaurants (ARPC) — they are not live customers. Do NOT use the "5.5 FTE replaced" (too small) or "$3.8M/20x ROI for BID-Coburg" (wrong) stats.
• Takeaways: 1-2 punchy sentences. Bold the main point, italicize the Beam angle.
• Close: name the specific first pilot process in ask_right.body

Step 6: Render the PDF

cd /Users/mohamadbekdache/Cursor/nexus-mo/skills/general/prospect-brief
/opt/homebrew/bin/python3.14 render.py configs/{prospect}_config.py \
  /Users/mohamadbekdache/Cursor/nexus-mo/03-projects/{ID}-{prospect}/04-outputs

Verify file size is >200KB (means images loaded correctly).

Step 7: Write cover email

Write a markdown file at 03-projects/{ID}-{prospect}/04-outputs/email-{contact-slug}.md.

Keep it SHORT and lead with THEIR problem, not with Beam. The brief does the selling; the email earns the open of the attachment and the call. Target 3 short paragraphs plus sign-off. If it reads like a template or runs long, cut it.

Email rules:

• Subject: their specific situation, not "introducing Beam AI" (e.g. "kaykroo back-office as you scale to 45 kitchens")
• Para 1: open ON THEIR PROBLEM, in their words. Name the pressure they're under and why it becomes the constraint. Do NOT open with "I'm from Beam" or "we build agents" — that's about us, not them. No invented job title for Mo, ever.
• Para 2: one line that this is the problem Beam solves, then the VALUE IN GENERAL terms (less manual work, faster cycles, no added headcount). Keep proof general here; the brief carries the specific customer stats. Point at the attached brief.
• Para 3: push for a CALL, framed as a question ("Worth a short call to walk through it?"). Offer to work around their schedule.
• Sign-off: "Mo Bekdache / Beam AI / [email protected]"
• No em dashes. No "honored/privileged/humbled". No "we build agents / I'm building out agents". Peer-to-peer. No geography-gap disclosure.
• Below a ---, add notes for Mo (NOT part of the email): how to get the contact's email, alternate entry point, second-touch angle.

Canonical example (kaykroo, COO Mohamad El Sabeh) — match this length and register:

Subject: kaykroo back-office as you scale to 45 kitchens

Mohamad,

Scaling from 30 to 45 kitchens across the UAE and KSA puts a load on the back office that headcount can't keep pace with. Every opening adds supplier invoices, compliance paperwork, and cost lines onto a team sized for a much smaller footprint, and at some point that becomes the real constraint on how fast you can open, ahead of capital or sites.

This is the problem Beam solves. We take those processes off the team and run them end to end, with your people keeping oversight and sign-off. For finance and operations groups at your scale it has meant materially less manual work and faster cycles without adding headcount. I've put together a short brief on where that value sits for kaykroo specifically, attached.

Worth a short call to walk through it? I can work around your schedule.

Mo Bekdache Beam AI [email protected]

Step 8: Save project memory

Write to ~/.claude/projects/.../memory/project_{prospect}.md and add one line to MEMORY.md.

---

CONFIG schema

See configs/kaykroo_config.py for the full annotated example. Top-level keys:

| Key | Type | Description | |-----|------|-------------| | company | str | Display name | | company_mark | str | Name as it appears in the h1 cover headline | | contact | str | Target contact full name | | date | str | "Month YYYY" | | header_right | str | Header right label | | footer_left | str | Footer left label | | output_name | str | PDF filename | | accent | str | Hex color e.g. "#D4491A" | | accent_dark | str | Darker variant hex | | accent_rgb | str | RGB as "R, G, B" | | accent_tint_1 | str | Full rgba() for slide bg top gradient | | accent_tint_2 | str | Full rgba() for slide bg bottom gradient | | brand_pop | str (optional) | Readable color for the large cover mark only. Defaults to accent. Set for light brand colors (yellow/lime/cyan) — see Step 4. | | logo_type | str | "wordmark" or "image" | | logo_wordmark | str | Text for wordmark mode | | logo_image | str or None | File path for image mode | | cover_headline | str | May contain {mark} placeholder and <br> | | cover_subtitle | str | 2-3 sentences | | opportunity | dict | See schema | | pillars_config | dict | Slide 3 header content | | pillars | list | 3 pillar dicts | | diff | dict | Slide 4 content | | proof | dict | Slide 5 content | | close | dict | Slide 6 content |

---

Quality bar

Reference: 03-projects/101-julius-baer/04-outputs/ and 03-projects/102-kaykroo/04-outputs/

• Every number in the brief must come from research or be clearly indicative
• Use case names must be specific to the prospect's industry (not generic)
• The "where we'd start" pillar must match the sharpest, most immediate pain
• Proof cards: always use the client closest to the prospect's sector as first card
• Close: always name the specific pilot process, not "a process"
• Email: read it aloud — if it sounds like a template, rewrite it

---

Anti-hallucination guardrails (non-negotiable)

This skill produces client-facing material where one fabricated number destroys credibility. Apply the evidence-first discipline from the reduce-hallucination skill (interrogation science for Beam agents), adapted here for document generation:

1. Every number traces to a source. Each stat on a slide comes from cited research, from proof-bank.md (verified customer stats), or is explicitly labeled indicative. If you can't say where a number came from, it does not go on the slide. A cited-looking number with no real source is a fabricated anchor. (reduce-hallucination R3)
2. Abstention is a correct answer. If research can't find a metric, say "not found" and use a sourced proxy or a sector benchmark with its citation. NEVER invent a round number to fill a stat card. Missing data is a gap, not a failure. (R1/R2 — don't force a value into an empty slot)
3. No directional guessing. Do not "assume / infer / estimate conservatively / default to" a figure to make the story work. Directional guesses become systematic bias. Any derived value estimate is labeled as derived and shows its assumption. (R4)
4. Don't claim what didn't happen. Never write that Beam "deployed at / piloted with / integrated" anyone unless it is true and in the data room. Don't attribute a capability or process we can't back. (R7)
5. Prospect-supplied 'facts' are claims, not truth. A figure from their website, a rumor, or an unverified number gets sourced ("per their FY25 report") or flagged, never laundered into an unmarked fact. (R8)
6. Proof must match the data room. Cross-check every proof stat against proof-bank.md. Honor the do-not-cite list. Never upgrade a projected number into a hard one.
7. Verification pass before rendering. Before running render.py, re-read every number in the config and confirm each traces to (a) cited research, (b) proof-bank, or (c) an explicit indicative label. Pull or fix anything that fails. This gate is mandatory.

When in doubt, under-claim. A brief with three defensible numbers beats one with ten impressive fabrications. For a full hallucination audit of a Beam agent (prompts/schemas/nodes), invoke the reduce-hallucination skill.