Dev Marketing Prospector

Developer Marketing Prospector

A prospecting skill for Infrasity to identify SaaS companies in specific tech verticals that need developer marketing services. Every data point in the output is backed by a source URL. Self-reported company claims are flagged. Inferences are stated as inferences.

---

Input Parameters

Every prospecting request has three inputs. Confirm all three before starting:

If any input is missing, ask for it before proceeding.

---

The Eight-Step Workflow

Step 1 — Understand the vertical

Before searching for any company, form a precise understanding of the vertical:

• What core problem does it solve
• What type of product a company in this vertical builds
• Who the primary technical ICP is inside those companies
• What the AI disruption angle looks like in this space

The exact-fit test: Every company in the output list should feel like it belongs in the same sentence as every other company on the list. If a company would feel out of place — even slightly — it is adjacent, not exact. Adjacent companies never go in the list.

Read references/vertical-definitions.md for definitions of all known verticals. For any new vertical not covered there, research it before generating output and follow the new vertical protocol at the bottom of that file.

---

Step 2 — Apply the hard filters

Every company must pass all five simultaneously:

1. Exact vertical fit — builds a product that is exactly in the vertical, not around it 2. SaaS / product-first — not a services company, not services-heavy 3. Developer-facing product — a product that developers can discover, try, and adopt 4. Funding stage — falls within the range provided by the user 5. Headcount — falls within the limit provided by the user

If a company passes the vertical test but fails funding or headcount → exclude. If a company passes funding and headcount but is adjacent → exclude. All five filters must be satisfied simultaneously, with no exceptions.

---

Step 3 — Research companies across all credible sources

Do not rely on a fixed list of databases. Cast wide. Use whatever credible source surfaces the most accurate, current data for that specific company. The goal is accuracy, not source loyalty.

Funding and company data Crunchbase, PitchBook, Tracxn, CB Insights, Dealroom, Harmonic, Carta, Companies House (UK), SEC EDGAR (US public filings)

Discovery and prospecting Y Combinator company directory, TechCrunch, VentureBeat, TechEU, Sifted (Europe), The Information, StrictlyVC, Bloomberg, Forbes, Business Wire, PR Newswire

Headcount and people LinkedIn, RocketReach, ZoomInfo, Apollo, LeadIQ, Glassdoor, job boards (a company hiring 10 developer marketing roles is a signal in itself)

Developer and open-source signals GitHub (stars, forks, contributors, release cadence), npm, PyPI, Docker Hub, Stack Overflow trends, Hacker News Show HN posts, Product Hunt launches

Revenue and growth estimates Sacra, Contrary Research, Latka, Growjo, SimilarWeb (traffic as a proxy), SEMrush

Competitive positioning and third-party analysis G2, Capterra, StackShare, StackOne, OpenAlternative, analyst reports (Gartner, Forrester, IDC where public), technical review roundups from credible blogs

News and recent signals Google News for the company name + current year, company blog, company changelog, press releases, founder interviews, podcast appearances

The rule: Use whichever source gives the most accurate and current data for that specific data point. When two sources conflict, note both and flag which is more recent or credible. Never rely on a single source for a critical number like funding total or headcount.

Search specifically, not broadly. Use the exact vertical name, the funding stage, and headcount range in every query. Verify headcount and funding stage from at least one credible source before including any company.

---

Step 4 — Map one Signal per company

For each qualified company, identify a specific, recent, verifiable reason why this company is a warm prospect right now. Must be one of:

• A funding round (name the round, amount, lead investor, date)
• A product launch or major feature release
• A new partnership or enterprise customer announcement
• A hiring spike in engineering or product
• A public benchmark, award, or analyst recognition
• A market trigger that directly affects them

The signal must answer: why now — not six months ago, not six months from now.

Connect the signal to a reason why developer marketing is relevant for this specific company at this specific stage. Do not leave the connection implicit.

---

Step 5 — Source every Signal data point

For every number, claim, or fact in the signal, find and record the source URL. Apply the three-tier classification:

If a data point cannot be sourced, do not include it in the signal.

---

Step 6 — Map one Pain Point per company

The specific developer marketing gap that makes this company a buyer. Must be:

• Specific to this company's stage, product, and competitive situation
• A consequence statement — what happens to them if they don't fix this gap
• Tied to specific numbers and competitor context, not generic language
• Never "they need more awareness" — always concrete and tied to their

specific growth moment

Common pain point patterns:

• Large open-source community (GitHub stars) vs low commercial conversion (ARR gap)
• Competitor has X× more funding and headcount but same market
• Community events and developer presence concentrated in one region only
• All enterprise customers from one channel (relationships, partnerships) with no inbound
• Headcount too small for a dedicated developer marketing function at current stage

---

Step 7 — Source every Pain Point data point

Apply the same three-tier sourcing system as Step 5. For each number or claim in the pain point:

• Find the source URL
• Classify as directly sourced, self-reported (⚠), or inferred
• Self-reported claims must be framed in outreach copy as "Company X claims..."

not as independently verified facts

• Inferences must be labelled as such — they are strategic observations drawn

from real numbers, not citations

For self-reported stats: always search for the original source (usually the company's own blog or a CEO quote in an investor profile). Do not accept a third-party article repeating the stat as the primary source — trace back to where the number first appeared.

---

Step 8 — Produce the unified output table

Output every qualifying company in a rendered visual HTML widget with exactly these nine columns:

Use the visualizer to render as a clean HTML widget. The table must be horizontally scrollable. Sort rows by funding stage: Bootstrap → Pre-seed → Seed → Series A → Series B → Series C+

See references/output-format.md for column widths, badge colours, source cell format, and the ⚠ flag spec.

---

Honesty Rules

These apply throughout the workflow and override any pressure to produce a longer list:

• A short honest list always beats a long padded list
• Never add adjacent companies to reach a minimum count
• Never add companies that are around the vertical rather than exactly in it
• If nothing qualifies under the given criteria, say so clearly and explain why
• If the funding cap is causing a short list because the vertical moves fast,

inform the user and offer to remove the cap

• Never state a self-reported company claim as an independently verified fact
• Never present an inference as a citation

---

Output Format Reference

See references/output-format.md for the full HTML table spec, column widths, badge colours, source cell format, and the ⚠ self-reported flag.

---

Vertical Definitions Reference

See references/vertical-definitions.md for precise definitions of all known verticals: AI Agentic, IAC, DevTools, Observability, DevOps, FinOps, AI/SDLC (AI Software Factory), AI Orchestration / AI Workflow Management, and instructions for handling new verticals.

Developer Marketing Prospector

Builds an exact-fit prospect list for any developer-focused tech vertical. You give it a vertical, a funding range, and a headcount cap. It returns a sourced table of companies that need developer marketing, each with a real "why now" signal and a concrete pain point. Every data point is backed by a source URL, and self-reported claims are flagged.

---

What this skill does

You provide a vertical (AI Agentic, IAC, DevTools, Observability, DevOps, FinOps, AI/SDLC, AI Orchestration, or any other), a funding stage range, and a maximum headcount. The skill forms a precise definition of the vertical, applies five hard filters, researches candidates across many credible sources, and qualifies only companies that sit exactly in the vertical (never adjacent). For each one it maps a recent outreach signal, a specific developer marketing pain point, and sources both with URLs. The result renders as a scrollable nine-column HTML widget sorted by funding stage.

Built for:

• Developer marketing agencies building targeted outbound lists for a specific vertical
• Founders and GTM teams researching the competitive landscape in their space
• SDRs and growth leads who need warm, sourced reasons to reach out, not a raw name dump

---

Installation

Claude Code (Recommended)

Clone the repo. The skill activates automatically when you open it in Claude Code:

git clone https://github.com/Infrasity-Labs/dev-gtm-claude-skills.git
cd dev-gtm-claude-skills
claude

Then trigger it with:

/dev-gtm prospect AI Agentic, pre-seed to Series A, under 50 headcount

Or describe what you want naturally. Claude activates the skill when you name a vertical and ask for a prospect list or leads.

Claude Web (Free / Pro)

1. Go to [Settings → Capabilities](https://claude.ai/settings/capabilities) and enable Code execution and file creation 2. Go to [Customize → Skills](https://claude.ai/customize/skills) 3. Click + → Create skill → Upload a skill 4. Zip this skill folder and upload it:

cd dev-gtm-claude-skills/skills/dev-marketing-prospector
zip -r ../dev-marketing-prospector.zip *dev-marketing-prospector/

Upload dev-marketing-prospector.zip and toggle it on.

---

No API keys required

This skill runs entirely on web research. It does not need DataForSEO, Ahrefs, or any other paid integration. Accuracy comes from casting a wide net across credible public sources (Crunchbase, PitchBook, LinkedIn, GitHub, Y Combinator, TechCrunch, Sacra, and more) and cross-checking critical numbers like funding total and headcount against at least one source before a company is included.

---

How to use

Prospect AI agent companies, Series A, 50 to 200 headcount

Find companies in the Observability vertical, seed to Series A, under 80 people

Build a prospect list for FinOps startups, pre-seed to seed, max 40 headcount

/dev-gtm prospect IAC, seed to Series A, under 60 headcount

Every request needs all three inputs. If any is missing, Claude asks for it before starting. For a vertical that is not already defined, Claude states its understanding back to you in a few sentences and waits for confirmation before researching companies.

Inputs

---

Output

A rendered HTML widget showing every qualifying company in a horizontally scrollable table, sorted by funding stage (Bootstrap, Pre-seed, Seed, Series A, Series B, Series C+) and alphabetically within each stage.

Nine columns:

The header bar shows the vertical name and the active filters. A footer explains the ⚠ flag and the estimate disclaimer. When fewer than five companies qualify, a note box explains why and what you can loosen.

---

Things to know

Exact fit only, never adjacent. Every company on the list should feel like it belongs in the same sentence as the others. If a company is around the vertical rather than exactly in it, it is excluded, even if that makes the list short.

A short honest list beats a padded one. The skill never adds adjacent companies to hit a count. If nothing qualifies under your criteria, it says so and explains why. If a tight funding cap is shrinking the list in a fast-moving vertical, it tells you and offers to remove the cap.

Three tiers of sourcing. Directly sourced facts get a plain link. Self-reported company claims (from a blog, press release, or CEO quote) get a ⚠ flag and must be framed as "Company X claims" in any outreach. Inferences drawn from two or more sourced numbers are labelled as inferences, not citations.

Signals answer "why now." Each signal is a recent, verifiable event (a funding round, launch, partnership, hiring spike, or award), not a stale fact from a year ago, and it is connected explicitly to why developer marketing is relevant at this stage.

Self-reported stats are traced to the origin. When a number comes from the company itself, the skill finds where it first appeared rather than citing a third-party article that repeats it.

---

How it works

1. Understand the vertical reads references/vertical-definitions.md and forms a precise definition: the core problem, what companies build, the technical ICP, and the AI disruption angle. New verticals are confirmed with you first. 2. Apply the hard filters keeps only companies that pass all five at once: exact vertical fit, SaaS / product-first, developer-facing, in the funding range, and within the headcount cap. 3. Research across all credible sources casts wide across funding databases, discovery sources, people data, open-source signals, revenue estimates, and recent news. Critical numbers are verified against at least one source. 4. Map one signal per company identifies a single recent, verifiable "why now" trigger and ties it to a developer marketing reason. 5. Source every signal data point records a URL for each fact and classifies it as directly sourced, self-reported, or inferred. 6. Map one pain point per company names the specific developer marketing gap and its consequence, tied to real numbers and competitor context. 7. Source every pain point data point applies the same three-tier sourcing, tracing self-reported stats back to their origin. 8. Produce the unified output table renders the nine-column HTML widget, sorted by funding stage, using the spec in references/output-format.md.

---

File structure

dev-marketing-prospector/
├── SKILL.md                          # Skill instructions Claude follows
├── README.md                         # This file
└── references/
    ├── vertical-definitions.md       # Precise definitions of all known verticals + new-vertical protocol
    └── output-format.md              # HTML table spec: column widths, badge colours, source format, flags

Output Format Reference

Badge Colours by Funding Stage

---

Table Sort Order

Always sort rows by funding stage, earliest to latest:

Bootstrap → Pre-seed/Beta → Seed → Series A → Series B → Series C+

Within the same funding stage, sort alphabetically by company name.

---

Header Bar Content

The table header bar must always show:

• Left: vertical name + "— Exact Vertical" or "— Full Landscape" depending on

whether a funding cap is applied

• Right: count of companies + cap status (e.g. "8 companies · ≤50 headcount ·

Pre-seed → Series A" or "11 companies · No funding cap · No headcount cap")

---

Filter Tags

Always show filter tags below the header bar. Standard tags:

• The vertical name (exact wording the user gave)
• Headcount filter (e.g. "Headcount < 50") or "No headcount cap"
• Funding range (e.g. "Pre-seed → Series A") or "No funding cap"
• "SaaS / Product-led" (always present)
• "Exact vertical only" (always present)
• "All data sourced" (always present — signals the sourcing standard)

---

Column Widths (min-width 1320px table, horizontally scrollable)

Total: ~1073px minimum. Set min-width: 1073px on the table and wrap in a horizontally scrollable <div class="wrap">.

---

Company Cell Content

Each company cell must contain, in order:

1. Company name — font-weight: 500, font-size: 12.5px 2. Funding badge — colour per stage table above 3. Sub-line: Founded YYYY in muted 10px text 4. Optional: one-line phase descriptor of what the company specifically does in the vertical (e.g. "Durable AI workflow orchestration")

---

Signal Cell Content

2–4 sentences. Include:

• The specific trigger event (round, launch, partnership, award) with

amount, date, and lead investor where applicable

• A direct connection to why developer marketing is relevant for this

company right now — do not leave this implicit

---

Signal Sources Cell Content

A compact numbered list. Each entry is a clickable link:

<ul class="src-list">
  <li>
    <a href="https://..." target="_blank">
      <span class="ref-num">S1</span>
      Source label — what data point it proves
    </a>
  </li>
</ul>

Format for the ref-num span:

• background: var(--color-background-secondary)
• border: 0.5px solid var(--color-border-secondary)
• border-radius: 3px
• font-size: 9px
• padding: 0 3px
• color: var(--color-text-secondary)

Keep source labels to ~6 words. The label must describe what the source proves, not just the source name. Examples:

• "PitchBook — funding & headcount" ✓
• "Sacra — 32k downloads, 35x YoY" ✓
• "PitchBook" ✗ (too vague)

---

Pain Point Cell Content

2–4 sentences. Must:

• Reference specific numbers and competitor context
• State the consequence clearly — what happens if they don't fix the gap
• Never be generic ("they need more awareness")

If a claim in the pain point is self-reported by the company (not independently verified), add this warning badge directly in the cell:

<span class="warn">⚠ [Stat] is self-reported by [Company] — not independently verified</span>

Warning badge CSS:

• background: #FAEEDA
• color: #633806
• font-size: 9px
• padding: 1px 4px
• border-radius: 3px
• display: inline-block
• margin-top: 2px

---

Pain Point Sources Cell Content

Same format as Signal Sources but using P1, P2... reference numbers.

For inferred claims (logical conclusions from multiple data points, not directly cited statistics), add an inline italic note beneath the source list:

<span style="font-size:10px;color:var(--color-text-secondary);
display:block;margin-top:4px;font-style:italic;">
Note: "[claim]" is inferred from [underlying sources] — not a cited stat.
</span>

---

Three-Tier Source Classification

Apply to every data point in both the signal and pain point columns:

When tracing a self-reported stat: always find the original source (company blog or CEO quote), not a third-party article that repeats it. The source URL must point to where the claim first appeared.

---

Geography Cell Content

Country flag emoji + country name + city/region on a separate sub-line in muted text.

Examples:

• 🇺🇸 USA · San Francisco, CA
• 🇬🇧 UK · London
• 🇩🇪 Germany · Berlin
• 🇮🇳 India · Bangalore
• 🇸🇬 Singapore
• 🇧🇷 Brazil · São Paulo
• 🇪🇸 Spain · Barcelona

---

Footer Line

Always include below the table:

All source links open in a new tab. ⚠ = self-reported company claim, not
independently verified. Revenue and headcount figures marked as estimates are
third-party algorithmic estimates, not company-disclosed numbers.

Font: 10px, color: var(--color-text-secondary).

---

Note Box (when list is short)

If the list contains fewer than 5 companies due to criteria strictness, add a note box above the table explaining why. Use:

• Left border: 3px solid #E24B4A
• Background: var(--color-background-secondary)
• Font size: 12px
• Content: explain the specific reason the list is short and what the user

can do (e.g. remove the funding cap or widen the headcount limit)

Vertical Definitions Reference

All known verticals for developer marketing prospecting. For any vertical not listed here, research the definition before generating output.

---

AI Agentic

Core problem: Automating multi-step business tasks that previously required human judgment and execution — from sales outreach to customer support to internal workflows.

What companies build: AI agents that take autonomous, multi-step actions toward a goal with minimal human supervision. The product does something — it sends emails, updates CRMs, books meetings, files documents, processes claims. It does not just generate content for a human to then act on.

Primary ICP: Varies by sub-vertical — but always has a technical buyer (engineer, CTO, or VP of Engineering) involved in the adoption decision because the agents integrate into existing systems via APIs.

AI disruption angle: The product itself IS the agentic AI. The company is not adding AI to an existing workflow — it is replacing the workflow with AI.

Exact-fit test: Does the product execute tasks autonomously, or does it generate suggestions a human acts on? Autonomous execution → exact fit. Suggestions a human then acts on → adjacent (copilot, not agent).

---

IAC — Infrastructure as Code

Core problem: Managing and provisioning cloud infrastructure — servers, networks, databases, load balancers — through machine-readable configuration files or scripts, rather than through manual processes or interactive consoles.

What companies build: Tools for writing, testing, validating, deploying, and managing infrastructure configurations. The new wave adds AI: generating Terraform/Pulumi configs from natural language, detecting infrastructure drift, catching misconfigurations before deployment, auto-remediating policy violations, and optimising cloud resource allocation automatically.

Primary ICP: Platform engineers and DevOps engineers who manage cloud infrastructure at scale.

AI disruption angle: AI generates infrastructure configs from intent, detects and remediates drift autonomously, enforces policy without human review, and optimises resource utilisation continuously.

Exact-fit test: Is the product specifically about defining, managing, or automating infrastructure through code? If yes → exact fit. General cloud management or CI/CD tools without an infrastructure-as-code layer → adjacent.

---

DevTools — Developer Tools

Core problem: Improving developer productivity at a specific stage of the development workflow — whether that is writing code, reviewing it, testing it, documenting it, or deploying it.

What companies build: Any SaaS product whose primary user is a software developer and whose value is delivered inside the development workflow. This includes code editors, testing frameworks, code review platforms, API development tools, debugging tools, documentation tools, and package management.

Primary ICP: Software developers, engineering managers, and CTOs at software companies.

AI disruption angle: AI augments individual developer tasks — code completion, test generation, documentation writing, PR review, bug detection. The developer stays in the loop; AI accelerates specific steps.

Exact-fit test: Is the primary user a software developer? Does the product plug into the development workflow? If yes → exact fit. Note: DevTools is deliberately broad. Distinguish from AI/SDLC (which replaces the workflow entirely) — DevTools assists the developer, not replaces them.

---

Observability

Core problem: Understanding what is happening inside a software system by examining its external outputs — logs, metrics, and traces. Goal: answer "why is this broken" without predicting in advance what might break.

What companies build: Log management platforms, APM (Application Performance Monitoring) tools, distributed tracing platforms, infrastructure monitoring, uptime monitoring, alerting systems, and AI-native platforms that do anomaly detection, root cause analysis, and incident correlation automatically.

Primary ICP: Site Reliability Engineers (SREs), platform engineers, and DevOps engineers responsible for system uptime and performance.

AI disruption angle: AI correlates signals across logs, metrics, and traces to diagnose root causes autonomously — instead of engineers manually searching through data. AIOps platforms surface the cause of incidents without human querying.

Exact-fit test: Does the product specifically help teams understand what is happening inside running systems? If yes → exact fit. General DevOps workflow tools without a monitoring/observability layer → adjacent.

---

DevOps

Core problem: Bridging software development and IT operations to deliver software faster and more reliably. In practice: CI/CD pipelines, container orchestration, release management, infrastructure automation, and deployment workflows.

What companies build: CI/CD platforms, container and Kubernetes tooling, deployment automation, feature flagging, release orchestration, and AI-native DevOps tools that handle pipeline optimisation, test selection, deployment risk scoring, and incident response.

Primary ICP: DevOps engineers, platform engineers, and SREs responsible for the software delivery pipeline.

AI disruption angle: AI optimises CI/CD pipelines (selecting which tests to run, predicting deployment risk, auto-rolling back failures), reduces deployment friction, and automates routine operational tasks.

Exact-fit test: Is the product about the process of getting software from code commit to production? If yes → exact fit. Distinguish from IAC (which focuses on the infrastructure layer) and Observability (which focuses on monitoring running systems). DevOps is the pipeline between them.

---

FinOps — Cloud Financial Operations

Core problem: Bringing financial accountability to the variable-spend model of cloud computing. Cloud bills are unpredictable and large — FinOps is the discipline of understanding, optimising, and governing that spend at the intersection of engineering, finance, and business.

What companies build: Cloud cost visibility platforms, rightsizing recommendation tools, reserved instance management, Kubernetes cost allocation, anomaly detection for unexpected cloud spend, and AI-native FinOps platforms that automatically identify waste, recommend optimisations, and forecast future spend.

Primary ICP: Platform engineers and DevOps engineers who make the architectural decisions that drive cloud costs, plus the finance/engineering leadership who sign off on the bill.

AI disruption angle: AI automatically identifies waste, recommends instance rightsizing, forecasts spend, and in some cases auto-optimises resource allocation without human intervention.

Exact-fit test: Is the product specifically about managing, optimising, or governing cloud infrastructure spend? If yes → exact fit. General cloud management tools without a cost/financial layer → adjacent.

---

AI/SDLC — AI Software Factory / Agentic SDLC

Core problem: The software development lifecycle is too slow and too human-intensive. The AI software factory treats software delivery as a production line where AI agents handle the heavy lifting — from requirements to deployed code.

What companies build: Autonomous AI systems that take over software engineering as a function. Input: a requirement, ticket, user story, or plain-language description. Output: working, deployed code. The AI handles planning, coding, testing, and deployment — not just one phase but the full pipeline. Humans provide strategic oversight.

Primary ICP: CTOs, VPs of Engineering, and enterprise engineering leaders at companies with large software development operations.

AI disruption angle: AI replaces or substantially reduces the need for human software engineers on specific tasks or the entire workflow — not just assisting individual developers but taking ownership of engineering outcomes.

Exact-fit test: Does the product take requirements/inputs and produce working deployed code with AI handling the execution? If yes → exact fit. Products that assist individual developers to code faster (GitHub Copilot, Cursor, code review tools, test generation tools) → NOT exact fit. Those are DevTools. The distinction: DevTools helps developers do their job faster. AI/SDLC reduces the number of developers needed to get the job done.

---

AI Orchestration / AI Workflow Management

Core problem: As companies build AI applications with multiple models, agents, and tools, they need a layer to coordinate the flow of data, decisions, and actions across these components reliably, at scale, and with observability. A single LLM call is easy. Chaining ten LLM calls, routing between different models, managing state across long-running agent workflows, handling failures and retries, and maintaining end-to-end observability of the whole pipeline — that is the problem this vertical solves.

What companies build: Frameworks and platforms for building, deploying, and managing multi-step AI workflows. This includes workflow engines purpose-built for LLM workloads, visual pipeline builders for AI agents, multi-agent orchestration frameworks, and production-grade runtime infrastructure for coordinating AI models, tools, and data sources. The defining characteristic is that the product coordinates and manages the execution flow between AI components — it is the plumbing, not the AI itself.

Primary ICP: ML engineers, AI engineers, platform engineers, and software developers building production AI applications that go beyond a single LLM API call.

AI disruption angle: As companies move from single-model AI to multi-agent, multi-model production systems, the coordination layer becomes critical. General-purpose workflow tools (Airflow, Prefect, Temporal) are not built for the specifics of LLM workloads — streaming, token management, prompt versioning, model routing, human-in-the-loop. AI-native orchestration platforms are built for this.

Exact-fit test: Is the product specifically built to orchestrate AI/LLM workloads — managing the flow, routing, sequencing, and state between multiple models, agents, or tools? If yes → exact fit.

Adjacent and excluded:

• General-purpose workflow automation (Zapier, Make, n8n) → adjacent,

not AI-native at the orchestration layer

• Pure LLM observability tools (LangSmith, Helicone, Langfuse) → adjacent,

that is the Observability vertical applied to AI

• Agent builders that build the agents themselves → adjacent, that is the

AI Agentic vertical

• AI agent toolbox / integration connectors (Composio) → adjacent, that is

the connectivity layer for agents, not the orchestration engine itself

Exact-fit examples: CrewAI, Dify.ai, Vellum, deepset (Haystack), Orkes (Conductor)

---

Handling New Verticals

If the user provides a vertical not listed above:

1. Research the vertical: what problem it solves, what products companies build inside it, who the technical ICP is, what the AI disruption angle is 2. State your understanding back to the user in 3–4 sentences before searching for companies 3. Ask the user to confirm or correct the understanding 4. Only begin Step 3 (researching companies) after confirmation 5. Add the new vertical definition to this file for future use