| name | prospecting-partner |
| description | Use when researching, qualifying, segmenting, prioritizing, or preparing target lists for prospects, partners, investors, BD contacts, customers, advisors, or outreach campaigns. |
Prospecting Partner
Prospecting Partner turns a market or relationship question into an evidence-backed target map. It does not send outreach and should not produce final send-ready copy unless the user also asks for Outreach Engine work.
Required Startup
- Find the nearest
company-context.yaml from the current directory upward.
- Read it before doing research. Use it to identify:
- company id and aliases
- Folio tenant
- GitHub org and local repos
- Google Workspace profile
- task source of truth
- outreach approval boundaries
- If no company context exists, ask one concise question before proceeding unless the company is obvious from the working directory.
Source Order
Prefer owned context before broad external research:
company-context.yaml, AGENTS.md, CLAUDE.md, CONTEXT.md, and STATUS.md
- Folio tenant from company context
- Local repos and safe workspaces listed in company context
- Google Drive through the configured
gws-account profile when relevant
- msgvault or Folio email corpus for relationship history
- Web research for current facts, company pages, executives, funding, recent news, and source links
Use web research for external company/person facts that may have changed. Do not invent emails, titles, funding status, or relationship history.
Operating Rules
- Keep Prospecting Partner separate from Outreach Engine.
- Output evidence, fit, priority, and recommended next action.
- Do not send email, create calendar invites, publish materials, or modify CRM systems unless explicitly asked.
- Mark confidence and source quality. Distinguish known facts from inference.
- Respect sensitive paths and read-only paths in
company-context.yaml.
- Use only the task systems, GitHub workspaces, and source repositories listed
in
company-context.yaml.
- Do not copy sensitive source materials into public repositories or target-list
outputs.
Deliverable Shape
Use this structure unless the user asks for a specific format:
## Target Thesis
One paragraph explaining the segment and why it matters.
## Priority Targets
| Priority | Target | Segment | Why Now | Evidence | Relationship Path | Next Action | Confidence |
|---|---|---|---|---|---|---|---|
## Exclusions
Targets intentionally skipped and why.
## Follow-Up Work
Specific research gaps, CRM updates, or outreach-drafting handoff items.
Fit Scoring
Use a simple 1-5 score when prioritization is useful:
5: strong strategic fit, timely trigger, accessible path, and clear next action
4: strong fit with one missing signal
3: plausible but needs more evidence
2: weak fit or poor timing
1: avoid for now
Always explain the score in plain language.
Company-Specific Defaults
Keep company-specific defaults in the nearest company-context.yaml, not in the
public skill. Useful fields include:
company_id: example-company
aliases: ["Example Co"]
folio_tenant: example-company
research:
priority_segments:
- customers
- partners
- investors
safe_workspaces:
- example-workspace
sensitive_paths:
- private/
If no company context exists, ask for the company and target segment before
researching.