find-companies-having-simple-signals

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Find Companies Having Simple Signals (Daily)

基于简单信号查找企业（每日更新）

Find companies based on what they're doing — hiring, posting, or using specific technologies. This skill checks if a signal is already tracking what the user wants, returns results if so, or deploys a new signal if not.

If the user is looking for people (not companies), use the

find-people-having-simple-signals

skill instead. If the user is asking about a specific company, use account intelligence or enterprise research instead.

根据企业的动态——招聘、发布内容或使用的特定技术——查找目标企业。该技能会先检查是否已有信号追踪用户需求，若有则返回结果，若无则部署新的信号。

如果用户要查找的是个人（而非企业），请使用

find-people-having-simple-signals

技能。如果用户询问的是特定企业，请使用客户情报或企业调研技能。

API Calls

API调用

All API calls in this skill use the bundled

api.sh

wrapper located in the same directory as this SKILL.md file. Never read or reference API credentials directly.

First, resolve the path to

api.sh

relative to this file's location:

bash

API="$(dirname "$(find ~/.agents/skills -name SKILL.md -path "*/find-companies-having-simple-signals/*" 2>/dev/null | head -1)")/api.sh"

Then use

$API

for all calls:

bash

undefined

本技能中所有API调用均使用与本SKILL.md文件同目录下的

api.sh

封装脚本。请勿直接读取或引用API凭证。

首先，解析

api.sh

相对于本文件的路径：

bash

API="$(dirname "$(find ~/.agents/skills -name SKILL.md -path "*/find-companies-having-simple-signals/*" 2>/dev/null | head -1)")/api.sh"

随后使用

$API

执行所有调用：

bash

undefined

POST with body

带请求体的POST请求

bash "$API" POST /api/v1/endpoint '{"key": "value"}'

GET without body

无请求体的GET请求

bash "$API" GET /api/v1/endpoint


All `bash api.sh` references below assume `$API` has been set.

bash "$API" GET /api/v1/endpoint


以下所有`bash api.sh`调用均假设已设置好`$API`变量。

When to Use This Skill

技能适用场景

"Find companies that are looking to adopt Kubernetes"
"Find companies posting about SOC2 compliance"
"Companies using Snowflake"
"Companies hiring AI engineers"
"Find companies posting about their Series A"

"查找计划采用Kubernetes的企业"
"查找发布SOC2合规相关内容的企业"
"使用Snowflake的企业"
"招聘AI工程师的企业"
"查找发布A轮融资相关内容的企业"

Agent Rules

Agent规则

Don't deploy signals without confirming. Signals cost credits. Always confirm before deploying.
Don't guess the signal type. If ambiguous (could be hiring or social), ask.
Close match ≠ loose match. "Building voice AI agents" ≈ "building voice agents" but ≠ "building in-house voice agents." If you have to think about it, it's not a match.
Present what the API returns. No fabrication, no inference.
Never output or log API credentials. All authenticated calls go through
```
api.sh
```
.

未经确认请勿部署信号。信号会消耗积分，部署前必须先征得用户确认。
请勿猜测信号类型。若需求模糊（既可能属于招聘类也可能属于社交类），请询问用户。
近似匹配≠宽松匹配。“构建语音AI Agent”≈“构建语音Agent”，但≠“构建内部语音Agent”。若需要思考判断，则不属于匹配范畴。
如实展示API返回结果。不得编造内容或进行推断。
绝不要输出或记录API凭证。所有认证调用均需通过
```
api.sh
```
执行。

Workflow

工作流程

0. Agent Auth Check

0. Agent身份验证检查

Before anything, check that

.env

contains

OPENFUNNEL_API_KEY

and

OPENFUNNEL_USER_ID

If both exist: skip to Step 1.

If either is missing:

undefined

在执行任何操作前，检查

.env

文件是否包含

OPENFUNNEL_API_KEY

和

OPENFUNNEL_USER_ID

。

若两者均存在： 跳至步骤1。

若任一缺失：

undefined

Welcome to OpenFunnel

欢迎使用OpenFunnel

OpenFunnel finds companies based on what they're doing — hiring, posting, or using specific technologies.

To get started, I'll authenticate you via the API.

What's your work email?


Wait for user input. Then:

1. Run `bash api.sh POST /api/v1/agent/sign-up '{"email": "<user_email>"}'`
2. Tell the user a 6-digit code was sent:

I sent a 6-digit verification code to {email}. Reply with the code.

3. Wait for input. Run `bash api.sh POST /api/v1/agent/verify '{"email": "<user_email>", "otp_code": "<code>"}'`
4. On success, write to `.env`:
- `OPENFUNNEL_API_KEY={api_key}`
- `OPENFUNNEL_USER_ID={email}`
5. Add `.env` to `.gitignore` if not already there
6. Verify with `bash api.sh POST /api/v1/signal/get-signal-list '{"pagination": {"limit": 1, "offset": 0}}'`
7. If verification succeeds → continue to Step 1
8. If sign-up fails → ask user to retry
9. If verify fails → tell user the code was invalid or expired (up to 10 attempts in 24 hours), offer to retry or resend

---

OpenFunnel可根据企业的动态——招聘、发布内容或使用的特定技术——查找目标企业。

开始前，我将通过API为您完成身份验证。

请提供您的工作邮箱：


等待用户输入。随后：

1. 执行`bash api.sh POST /api/v1/agent/sign-up '{"email": "<user_email>"}'`
2. 告知用户已发送6位验证码：

我已向**{email}**发送了6位验证码，请回复该验证码。

3. 等待用户输入，执行`bash api.sh POST /api/v1/agent/verify '{"email": "<user_email>", "otp_code": "<code>"}'`
4. 验证成功后，写入`.env`文件：
- `OPENFUNNEL_API_KEY={api_key}`
- `OPENFUNNEL_USER_ID={email}`
5. 若`.gitignore`中未包含`.env`，则添加进去
6. 执行`bash api.sh POST /api/v1/signal/get-signal-list '{"pagination": {"limit": 1, "offset": 0}}'`进行验证
7. 若验证成功 → 继续步骤1
8. 若注册失败 → 请用户重试
9. 若验证失败 → 告知用户验证码无效或已过期（24小时内最多尝试10次），提供重试或重新发送的选项

---

1. Understand the request

1. 理解用户需求

What activity or behavior is the user looking for? If unclear, ask.

明确用户要查找的企业动态或行为。若需求不清晰，请询问用户。

2. Check existing signals

2. 检查已有信号

Run

bash api.sh POST /api/v1/signal/get-signal-list '{"pagination": {"limit": 100, "offset": 0}}'

to get all currently deployed signals.

A signal is unique by query + ICP pair. The same query with a different ICP is a different signal and needs separate deployment. When checking for matches, compare BOTH:

Query match — close match on signal name. Same meaning, different wording is fine:
- "Find companies building voice AI agents" ≈ "Find companies building voice agents" → match
- "Find companies building voice AI agents" ≠ "Find companies building in-house voice agents" → not a match
- "Companies hiring for Kubernetes" ≈ "Companies looking to adopt Kubernetes" → match
- "Companies hiring for Kubernetes" ≠ "Companies migrating to container orchestration" → not a match, too much inference
ICP match — the signal's
```
icp.id
```
must match the user's intended ICP. If the user hasn't specified an ICP yet, note which ICP the existing signal uses.

If potential match found (query + ICP both match):

I found an existing signal that covers this:

**{signal_name}** (ID: {signal_id})
**ICP:** {icp.name}

Want to use this one, or deploy a new signal?

If query matches but ICP is different:

I found a signal with a similar query but a different ICP:

**{signal_name}** (ID: {signal_id})
**ICP:** {icp.name}

This uses a different ICP than what you need. Want to:
1. Use this one anyway
2. Deploy a new signal with the right ICP

Wait for user input.

执行

bash api.sh POST /api/v1/signal/get-signal-list '{"pagination": {"limit": 100, "offset": 0}}'

获取所有已部署的信号。

信号由查询语句+ICP组合唯一标识。相同查询语句搭配不同ICP属于不同信号，需单独部署。检查匹配时，需同时对比以下两点：

查询语句匹配 — 信号名称需近似匹配，含义相同、表述不同属于匹配范畴：
- “查找构建语音AI Agent的企业”≈“查找构建语音Agent的企业” → 匹配
- “查找构建语音AI Agent的企业”≠“查找构建内部语音Agent的企业” → 不匹配
- “招聘Kubernetes相关人才的企业”≈“计划采用Kubernetes的企业” → 匹配
- “招聘Kubernetes相关人才的企业”≠“迁移至容器编排的企业” → 不匹配，推断过度
ICP匹配 — 信号的
```
icp.id
```
必须与用户需求的ICP一致。若用户尚未指定ICP，请记录已有信号使用的ICP信息。

若找到完全匹配的信号（查询语句+ICP均匹配）：

我找到了一个覆盖该需求的已有信号：

**{signal_name}**（ID: {signal_id}）
**ICP:** {icp.name}

是否使用该信号，还是部署新的信号？

若查询语句匹配但ICP不同：

我找到了一个查询语句相似但ICP不同的信号：

**{signal_name}**（ID: {signal_id}）
**ICP:** {icp.name}

该信号使用的ICP与您的需求不符，请问您想：
1. 仍使用该信号
2. 部署符合目标ICP的新信号

等待用户输入。

3. Get results from existing signal

3. 从已有信号获取结果

Run

bash api.sh POST /api/v1/signal/ '{"signal_id": <id>}'

to get accounts and people matched by this signal.

undefined

执行

bash api.sh POST /api/v1/signal/ '{"signal_id": <id>}'

获取该信号匹配的企业和联系人信息。

undefined

Results from: {signal_name}

信号结果：{signal_name}

{total_accounts} accounts found | {total_people} people found


If the user wants full details, run `bash api.sh POST /api/v2/account/batch '{"account_ids": [<ids>]}'`.

After presenting:

Would you like to:

See full details on specific accounts
Narrow results with filters (size, funding, location)
Deploy an additional signal for broader coverage ⚡ uses credits

undefined

找到{total_accounts}家企业 | {total_people}位联系人


若用户需要详细信息，执行`bash api.sh POST /api/v2/account/batch '{"account_ids": [<ids>]}'`。

展示结果后：

请问您想：

查看特定企业的完整详情
通过筛选条件缩小结果范围（企业规模、融资情况、地域）
部署额外信号以扩大覆盖范围 ⚡ 会消耗积分

undefined

4. Classify and deploy a new signal

4. 分类并部署新信号

Three company signal types:

企业信号分为三类：

Deep Hiring Signal

深度招聘信号

When: Companies hiring for something, looking to build something, facing a pain point.

Core principle: Job posts are modern RFPs — budget is committed, leadership is aligned, they're ready to act. What a company hires for tells you what they're building, scaling, or fixing.

Prompt format:

"Find companies that are looking to [activity] or facing [pain point]"

Examples:

"Find Companies with Hiring post mentioning Implementing Guardrails for AI agents"
"Find Companies with Hiring post mentioning Setting up Agent Evals and Testing"
"Find Companies with Hiring post mentioning Migrating from Heroku to AWS"
"Find Companies with Hiring post mentioning Scaling their PLG motion"
"Find Companies with Hiring post mentioning Building out their first data engineering team"
"Find Companies with Hiring post mentioning Adopting Kubernetes"

Timeframe: Last day to last year. Default: last 3 months.

Deploy:

bash api.sh POST /api/v1/signal/deploy/deep-hiring-agent '{"name": "<name>", "search_query": "<query>", "timeframe": <days>, "icp_id": <id>, "repeat": <true|false>}'

适用场景： 企业正在招聘特定人才、计划构建某项能力或面临特定痛点。

核心原则： 招聘启事是现代版的需求建议书——预算已获批、领导层达成共识，企业已准备好采取行动。企业的招聘需求可体现其正在构建、扩展或解决的问题。

提示格式：

"Find companies that are looking to [activity] or facing [pain point]"

示例：

"Find Companies with Hiring post mentioning Implementing Guardrails for AI agents"
"Find Companies with Hiring post mentioning Setting up Agent Evals and Testing"
"Find Companies with Hiring post mentioning Migrating from Heroku to AWS"
"Find Companies with Hiring post mentioning Scaling their PLG motion"
"Find Companies with Hiring post mentioning Building out their first data engineering team"
"Find Companies with Hiring post mentioning Adopting Kubernetes"

时间范围： 最近1天至最近1年。默认值：最近3个月。

部署命令：

bash api.sh POST /api/v1/signal/deploy/deep-hiring-agent '{"name": "<name>", "search_query": "<query>", "timeframe": <days>, "icp_id": <id>, "repeat": <true|false>}'

Social Listening Signal (Company)

社交监听信号（企业端）

When: Companies posting about a topic, milestone, or announcement.

What it captures:

Decision-maker pain posts (VP/C-level posting about challenges — stronger than press releases)
Budget signals (headcount growth, new initiatives, strategic pivots)
Vendor evaluation (comparing tools, asking for recommendations, discussing migrations)
Conference/event attendance

Prompt format:

"Find companies posting about [topic or milestone or announcement]"

Examples:

"Find companies posting about their Series A round"
"Find companies posting about growing their GTM team"
"Find companies posting about attending RSAC conference"
"Find companies posting about adding AI to their existing stack"

Timeframe: Last day to last year.

Deploy:

bash api.sh POST /api/v1/signal/deploy/social-listening-agent '{"name": "<name>", "search_query": "<query>", "signal_target": "account", "timeframe": <days>, "icp_id": <id>, "repeat": <true|false>}'

适用场景： 企业发布特定主题、里程碑或公告内容。

覆盖内容：

决策者的痛点发布（副总裁/高管级别的挑战分享——比新闻稿更有价值）
预算信号（人员扩张、新举措、战略转型）
供应商评估（工具对比、寻求推荐、讨论迁移）
会议/活动参与

提示格式：

"Find companies posting about [topic or milestone or announcement]"

示例：

"Find companies posting about their Series A round"
"Find companies posting about growing their GTM team"
"Find companies posting about attending RSAC conference"
"Find companies posting about adding AI to their existing stack"

时间范围： 最近1天至最近1年。

部署命令：

bash api.sh POST /api/v1/signal/deploy/social-listening-agent '{"name": "<name>", "search_query": "<query>", "signal_target": "account", "timeframe": <days>, "icp_id": <id>, "repeat": <true|false>}'

Technography Signal

技术栈信号

When: Companies using a specific tool, platform, or technology. Inferred from job postings.

Important: Input must be a specific tool name — not general descriptions.

Good inputs:

Kubernetes

Snowflake

React

Terraform

dbt

Kafka

Bad inputs: "cloud infrastructure" (too general), "data tools" (not specific), "modern stack" (meaningless)

Note on timing: Technographic data alone is a trait (static). It becomes a signal when combined with timing — "just adopted Snowflake" vs "has used Snowflake for 5 years" are very different. The timeframe parameter controls this.

Timeframe: Last day to last year. Default: last 3 months.

Deploy:

bash api.sh POST /api/v1/signal/deploy/technography-search-agent '{"name": "<name>", "technographic_list": ["<tech>"], "technographic_variations": ["<variations>"], "technography_context": "<context>", "timeframe": <days>, "icp_id": <id>, "repeat": <true|false>}'

If ambiguous — e.g., "companies investing in AI" could be hiring or social — ask:

This could be tracked through hiring signals or social signals. Which would be more useful?

1. **Hiring signals** — reveals budget commitment, team building, specific roles
2. **Social signals** — reveals announcements, thought leadership, public positioning
3. **Both** — deploy two signals for broader coverage ⚡ *uses more credits*

适用场景： 企业使用特定工具、平台或技术。数据来源于招聘启事推断。

注意： 输入必须为具体工具名称——不得使用通用描述。

有效输入：

Kubernetes

Snowflake

React

Terraform

dbt

Kafka

无效输入： "云基础设施"（过于宽泛）、"数据工具"（不具体）、"现代技术栈"（无明确含义）

时间说明： 技术栈数据本身是静态特征，但结合时间维度后就成为信号——"刚采用Snowflake"与"使用Snowflake已有5年"差异显著。时间范围参数可控制这一维度。

时间范围： 最近1天至最近1年。默认值：最近3个月。

部署命令：

bash api.sh POST /api/v1/signal/deploy/technography-search-agent '{"name": "<name>", "technographic_list": ["<tech>"], "technographic_variations": ["<variations>"], "technography_context": "<context>", "timeframe": <days>, "icp_id": <id>, "repeat": <true|false>}'

若需求模糊 — 例如，"投资AI的企业"既可能属于招聘类也可能属于社交类——请询问用户：

该需求可通过招聘信号或社交信号追踪，请问哪种更符合您的需求？

1. **招聘信号** — 揭示预算投入、团队建设、具体岗位需求
2. **社交信号** — 揭示企业公告、思想领导力、公开定位
3. **两者都选** — 部署两个信号以扩大覆盖范围 ⚡ *会消耗更多积分*

5. Confirm before deploying

5. 部署前确认

First, fetch available ICP profiles:

bash api.sh GET /api/v1/icp/list

. If the user has ICPs, present them:

I'll deploy a **{signal type}** signal:

**Name:** {auto-generated descriptive name}
**Query:** "{formatted prompt}"
**Timeframe:** {default}

**ICP Profile:**
{list available ICPs by name}
→ I'd recommend using **{first/most relevant ICP name}** to qualify results.
   Or "none" to skip ICP filtering.

⚡ *This will use credits from your plan.*

Other options:
- **Repeat daily** — re-run this signal every day for continuous monitoring
- **Audience name** — auto-add results to a named audience
- **Credit limit** — cap spending on this signal

Set any of these, or "deploy" to go with defaults.

If the user types "none" or skips ICP selection:

Auto-create a broad fallback ICP:

bash

bash api.sh POST /api/v1/icp/create '{"name": "Broad Default ICP", "target_roles": ["Any"], "employee_ranges": ["1-10", "11-50", "51-200", "201-500", "501-1000", "1001-5000", "5001-10000", "10001+"], "location": ["Any"]}'

Then tell the user:

No ICP selected, so I created a broad fallback ICP: **{name}** (ID: {id})

Using this ICP for your signal.

If the user has no ICP profiles:

You don't have an ICP profile yet. A quick one will make results much sharper —
it filters by company size, location, and the roles you're targeting.

1. **Quick setup** (recommended) — takes 30 seconds
2. **Skip** — auto-create a broad fallback ICP and continue

If quick setup → collect ICP name, target roles, company size, and location. Create via

bash api.sh POST /api/v1/icp/create '{"name": "<name>", "target_roles": ["<roles>"], "employee_ranges": ["<ranges>"], "location": ["<location>"]}'

If skip → auto-create the broad fallback ICP as above.

Then deploy with the selected or created ICP ID.

首先，获取可用的ICP画像：

bash api.sh GET /api/v1/icp/list

。若用户已有ICP画像，展示如下：

我将部署一个**{signal type}**信号：

**名称：** {自动生成的描述性名称}
**查询语句：** "{格式化后的提示词}"
**时间范围：** {默认值}

**ICP画像选项：**
{列出所有可用的ICP画像名称}
→ 我推荐使用**{第一个/最相关的ICP画像名称}**来筛选结果。
   或输入"none"跳过ICP筛选。

⚡ *该操作将消耗您套餐中的积分。*

其他可选配置：
- **每日重复执行** — 每天重新运行该信号以持续监控
- **受众名称** — 将结果自动添加至指定受众列表
- **积分限额** — 设置该信号的积分消耗上限

如需配置以上选项，请说明，或输入"deploy"使用默认配置。

若用户输入"none"或跳过ICP选择：

自动创建一个通用的 fallback ICP：

bash

bash api.sh POST /api/v1/icp/create '{"name": "Broad Default ICP", "target_roles": ["Any"], "employee_ranges": ["1-10", "11-50", "51-200", "201-500", "501-1000", "1001-5000", "5001-10000", "10001+"], "location": ["Any"]}'

随后告知用户：

未选择ICP画像，已为您创建一个通用 fallback ICP：**{name}**（ID: {id}）

该信号将使用此ICP画像。

若用户无可用ICP画像：

您目前没有ICP画像。快速创建一个ICP画像可大幅提升结果精准度——
它可按企业规模、地域和目标岗位进行筛选。

1. **快速创建**（推荐）— 耗时30秒
2. **跳过** — 自动创建通用 fallback ICP并继续

若选择快速创建 → 收集ICP名称、目标岗位、企业规模和地域信息。执行

bash api.sh POST /api/v1/icp/create '{"name": "<name>", "target_roles": ["<roles>"], "employee_ranges": ["<ranges>"], "location": ["<location>"]}'

完成创建。

若选择跳过 → 按上述方式自动创建通用 fallback ICP。

随后使用选定或创建的ICP ID部署信号。

6. Post-deploy

6. 部署完成后

Signal deployed: **{name}** (ID: {signal_id})

This is now scanning {job posts / social posts / tech stack data}.
Results come in as they're found — just say "check on {signal_name}" anytime.

信号已部署：**{name}**（ID: {signal_id}）

该信号正在扫描{招聘启事/社交内容/技术栈数据}。
结果将实时更新，您随时可以说“查看{signal_name}的结果”来获取最新数据。

7. Check back

7. 查看结果

Run

bash api.sh POST /api/v1/signal/ '{"signal_id": <id>}'

to get results found so far.

执行

bash api.sh POST /api/v1/signal/ '{"signal_id": <id>}'

获取当前已匹配的结果。