warm-path-workspace

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Warm-Path Deal Workspace

暖路径交易工作区

Turn "here is a company, here are our LinkedIn connections" into one self-contained, shareable HTML workspace that answers two questions an account team actually has: who decides, and who do we already know who can get us to them.

Most stakeholder maps stop at the first question. The second is where deals are won, and it is the part people fake - they draw a line from every connection straight to the buyer, which makes an intern look as valuable as a VP. This skill scores every route instead, so the operator spends their scarcest resource (a teammate's willingness to make an ask) on routes that will actually land.

将“这是一家公司，这是我们的LinkedIn联系人”转化为一个独立、可共享的HTML工作区，解答客户团队真正关心的两个问题：谁做决策，以及我们已经认识谁可以帮我们对接决策者。

大多数利益相关者图谱仅停留在第一个问题上。第二个问题才是促成交易的关键，而这也是人们常敷衍了事的部分——他们会画一条线将每个联系人直接连接到买家，这让实习生看起来和副总裁一样有价值。本技能会为每条路径打分，让操作人员将最稀缺的资源（团队成员愿意提出请求的意愿）用在真正有效的路径上。

What gets built

构建内容

One HTML file, published with the

Artifact

tool, with a tab set per account and an account switcher on top when there is more than one:

Tab	Contents
Overview	Account brief, headcount and funding tiles, hiring-signal chart, recent activity
Stakeholders	Buying group grouped by deal role; each card opens a drawer with the LinkedIn deep dive, priorities, talking points, objections, a copy-ready opener, notable posts, career timeline - every claim behind an evidence dropdown
Relationship Map	YOU → warm connection → named intermediary → decision maker, colour and thickness weighted by route strength, plus a ranked chain list
Signals	Hiring surges, job changes, intent posts, funding, newest first
Plays	3-6 prioritized moves, each citing the signal or path behind it

通过

Artifact

工具发布一个HTML文件，每个客户对应一个标签页；当有多个客户时，顶部会显示客户切换器：

标签页	内容
概览	客户简报、员工人数和融资信息卡片、招聘信号图表、近期动态
利益相关者	按交易角色分组的采购组；每个卡片可展开抽屉，展示LinkedIn深度分析、优先级、沟通要点、异议、可直接复制的开场白、重要帖子、职业 timeline ——每项结论都附带证据下拉框
关系图谱	您 → 暖联系人 → 指定中间人 → 决策者，路线的颜色和粗细按路径强度加权，同时附带排名链路列表
信号	招聘激增、职位变动、意向帖子、融资信息，按时间倒序排列
行动方案	3-6个优先级行动，每个行动都引用背后的信号或路径

Inputs

输入项

Ask only for what is missing.

Input	Required	Default
Target account(s)	yes	-
LinkedIn connection export(s)	no, but the point of the skill	skip warm paths, say so
Seller company + one-line product	no	infer from context
Deal stage	no	"Prospecting"
Depth	no	6-8 stakeholders per account

Exports arrive as a bare

Connections.csv

, an unzipped

Basic_LinkedInDataExport_*

folder, or the raw

.zip

. All three work. When the export contains

Profile.csv

the owner's name is read from it automatically - do not ask the user who each file belongs to when the file already says. Confirm the detected names back to them, because attributing a connection to the wrong teammate sends the intro request to the wrong person.

仅询问缺失的信息。

输入项	是否必填	默认值
目标客户	是	-
LinkedIn联系人导出文件	否，但为技能核心功能	跳过暖路径，并告知用户
销售方公司 + 一句话产品介绍	否	从上下文推断
交易阶段	否	"潜在客户开发"
深度	否	每个客户6-8名利益相关者

导出文件可以是单独的

Connections.csv

、解压后的

Basic_LinkedInDataExport_*

文件夹，或原始

.zip

文件。这三种格式均支持。当导出文件包含

Profile.csv

时，会自动从中读取所有者姓名——当文件已包含相关信息时，无需询问用户每个文件属于谁。将检测到的姓名回传给用户确认，因为将联系人归属到错误的团队成员会导致引荐请求发送给错误的人。

Phase 0 - preflight and an isolated working directory

阶段0 - 预检与独立工作目录

Create a run-scoped working directory and use it for everything:

bash

WORK="$(mktemp -d -t wpw)"   # or <somewhere>/wpw-<account>-<timestamp>
mkdir -p "$WORK"

This matters more than it looks. Two runs sharing a scratch path will clobber each other's

connections.json

, and the failure is silent: in testing one run briefly reported that an owner had zero connections at an account when they had ten thousand. Cross-owner contamination is the worst corruption this tool can produce, because the operator ends up asking the wrong teammate for an intro to someone they have never met. One directory per run, always.

Then check Crustdata is reachable and surface the balance in one line. All Crustdata calls in this skill run through the Code Mode MCP (install.crustdata.com/mcp): plain-JavaScript

execute({ code })

scripts calling

await callTool(name, params)

— every script opens with a

// user query: ...

// model query: ...

comment, branches on

r.ok

, and returns only the compact projection it needs (

fields

is a response whitelist: the result carries only the groups you list). The preflight is

account_credits

(free):

// model query: preflight - Crustdata reachable + credit balance
const r = await callTool("account_credits", {});
return r.ok ? r.data : { error: r.message };

创建一个运行范围专属的工作目录，并将所有操作都放在该目录中：

bash

WORK="$(mktemp -d -t wpw)"   # 或 <somewhere>/wpw-<account>-<timestamp>
mkdir -p "$WORK"

这比看起来更重要。两个运行共享临时路径会互相覆盖对方的

connections.json

，且故障是静默的：在测试中，某次运行短暂报告某所有者在某客户处有0个联系人，而实际上他们有10000个。跨所有者污染是此工具可能产生的最严重问题，因为操作人员最终会向从未见过目标对象的团队成员请求引荐。每次运行都使用单独的目录，务必遵守。

然后检查Crustdata是否可访问，并在一行中显示余额。本技能中所有Crustdata调用都通过Code Mode MCP（install.crustdata.com/mcp）执行：纯JavaScript的

execute({ code })

脚本调用

await callTool(name, params)

——每个脚本都以

// user query: ...

或

// model query: ...

注释开头，根据

r.ok

分支处理，仅返回所需的紧凑结果（

fields

是响应白名单：结果仅包含您列出的分组）。预检使用免费的

account_credits

：

// model query: preflight - Crustdata reachable + credit balance
const r = await callTool("account_credits", {});
return r.ok ? r.data : { error: r.message };

Phase 1 - account brief (per account)

阶段1 - 客户简报（每个客户）

company_identify

(free) to resolve the company — it is fuzzy, one identifier can match several companies, so take the top

confidence_score

match — then one

company_enrich

crustdata_company_ids

with

exact_match: true

and

fields: ["basic_info", "headcount", "funding", "competitors", "people", "news", "hiring", "followers", "taxonomy"]

(the

people

group carries the decision-maker and CXO snapshot; list every group you read). Then

job_search

twice -

limit: 0

with a

group_by

aggregation on

job_details.category

for the aggregate, then

limit: 15

sorted by

metadata.date_added

desc for notable roles. Then

social_post_list_live

on the company (

company_domain

; 1 credit per post, so set

limit

deliberately — ~10 is plenty for the brief).

Check whether the account still exists as an independent company. Acquisitions change who holds budget and which brand people list. A recent deal belongs in the brief and in the alias list. In testing, Confluent turned out to be an IBM company mid-run, which changed the entire buying process.

Write a 3-4 sentence

brief

: what they do, their scale, what is changing, why now. Ground every number in the payload you just pulled.

Take the logo while you are here.

basic_info.logo_permalink

comes back from the free

company_identify

call (and from the enrich above) at no extra credit cost. Download it, base64 it, and write it to

account.logo_url

as a

data:image/jpeg;base64,...

URI - the media CDN serves these as

binary/octet-stream

, so a remote

<img src>

renders blank. The workspace shows it in the header and the account switcher; without it you get a monogram.

使用

company_identify

（免费）解析公司——它支持模糊匹配，一个标识符可能匹配多个公司，因此选择

confidence_score

最高的匹配项——然后通过

crustdata_company_ids

调用一次

company_enrich

，设置

exact_match: true

和

fields: ["basic_info", "headcount", "funding", "competitors", "people", "news", "hiring", "followers", "taxonomy"]

（

people

分组包含决策者和CXO快照；列出您需要读取的所有分组）。然后调用两次

job_search

——第一次

limit: 0

并按

job_details.category

进行

group_by

聚合，获取汇总信息；第二次

limit: 15

并按

metadata.date_added

降序排序，获取重要职位。然后对公司调用

social_post_list_live

（使用

company_domain

；每条帖子消耗1个积分，因此需谨慎设置

limit

——约10条足以用于简报）。

检查客户是否仍为独立公司。收购会改变预算持有人和人们列出的品牌。最近的交易应包含在简报和别名列表中。在测试中，Confluent在运行过程中被IBM收购，这完全改变了采购流程。

撰写3-4句话的

brief

：他们的业务、规模、正在发生的变化、为何是现在。所有数据都要基于您刚获取的 payload。

同时获取Logo。免费的

company_identify

调用（以及上述的

company_enrich

）会返回

basic_info.logo_permalink

，无需额外消耗积分。下载该Logo，转换为base64格式，并将其写入

account.logo_url

，格式为

data:image/jpeg;base64,...

URI——媒体CDN会将这些文件作为

binary/octet-stream

提供，因此远程

<img src>

会显示空白。工作区会在页眉和客户切换器中显示Logo；如果没有Logo，则会显示首字母缩写。

Phase 2 - buying group

阶段2 - 采购组

Seed with contacts the user named plus the

people

group from Phase 1, then discover with

person_search

filtered on

experience.employment_details.current.company_id

and senior

experience.employment_details.current.seniority_level

, biased to the function you sell into. Resolve enum values with

person_autocomplete

first - a wrong enum silently returns zero rows (the seniority vocabulary is a closed set:

CXO

Vice President

Director

Experienced Manager

Strategic

, ...).

Then run a second pass on stack ownership, not title. Seniority is a proxy for authority; owning the budget and the tools is the real thing. Search for people whose title or headline says they own the relevant systems (ops, platform, systems, enablement, tooling, "GTM systems", "talent operations"). In testing the single best-fit buyer at one account was a Senior Manager who owned 18 tools and a $5M budget, and a director-and-above sweep missed him entirely.

Trim to 6-8 people. Assign a provisional

deal_role

and

influence

(1-5). Set

entity

when someone sits in an acquired sub-brand rather than the parent - that is what lets a connection at that sub-brand route straight to them.

Acquisitions are where the warm paths hide. People at acquired companies often still list the original brand, so a connection at "Red Hat" never matches a search for "IBM". Web-search the acquisition history and write the full alias list to

aliases.json

json

{"IBM": ["ibm", "red hat", "hashicorp", "apptio", "nordcloud"]}

Multi-word aliases match as phrases, single words as whole tokens, so fragments like "edge" will not drag in unrelated firms. Watch for genuine collisions - "Observe.AI" is not the "Observe, Inc." that Snowflake bought, and both will appear.

以用户指定的联系人以及阶段1中的

people

分组为种子，然后使用

person_search

进行发现，过滤条件为

experience.employment_details.current.company_id

和高级别的

experience.employment_details.current.seniority_level

，偏向您销售的职能领域。首先使用

person_autocomplete

解析枚举值——错误的枚举会静默返回0行数据（职级词汇是封闭集合：

CXO

Vice President

Director

Experienced Manager

Strategic

, ...）。

然后针对技术栈所有权进行二次筛选，而非仅看头衔。职级是权力的代理；掌控预算和工具才是真正的权力。搜索头衔或简介中显示他们拥有相关系统（运维、平台、系统、赋能、工具、“GTM系统”、“人才运营”）的人员。在测试中，某客户的最佳买家是一位高级经理，他负责18个工具和500万美元的预算，而仅筛选总监及以上级别的操作完全漏掉了他。

筛选至6-8人。分配临时的

deal_role

和

influence

（1-5分）。当某人隶属于被收购的子品牌而非母公司时，设置

entity

——这让子品牌的联系人可以直接对接他们。

收购是暖路径隐藏的地方。被收购公司的员工通常仍会列出原品牌，因此“Red Hat”的联系人永远不会匹配“IBM”的搜索。通过网络搜索收购历史，并将完整的别名列表写入

aliases.json

：

json

{"IBM": ["ibm", "red hat", "hashicorp", "apptio", "nordcloud"]}

多词别名按短语匹配，单字别名按完整词匹配，因此像“edge”这样的片段不会引入无关公司。注意真正的冲突——"Observe.AI"不是Snowflake收购的"Observe, Inc."，两者都会出现。

Phase 3 - stakeholder deep dives

阶段3 - 利益相关者深度分析

Spawn one sub-agent per stakeholder, batched in a single message, using

references/stakeholder-agent.md

. Keep raw post dumps out of the main context. Assemble into

$WORK/<slug>/dossier.json

following

references/dossier-schema.md

Each person's photo (

basic_profile.profile_picture_permalink

) is already inside the

basic_profile

group the sub-agent requests - free. Base64 it into

photo_url

on the stakeholder, same

binary/octet-stream

rule as the logo. Cards and drawers look like a real buying group instead of a wall of initials.

为每个利益相关者生成一个子代理，批量发送到单个消息中，使用

references/stakeholder-agent.md

。将原始帖子转储排除在主上下文之外。按照

references/dossier-schema.md

将内容组装到

$WORK/<slug>/dossier.json

中。

每个人的照片（

basic_profile.profile_picture_permalink

）已包含在子代理请求的

basic_profile

分组中——免费。将其转换为base64格式并写入利益相关者的

photo_url

，遵循与Logo相同的

binary/octet-stream

规则。卡片和抽屉看起来像真实的采购组，而不是一堆首字母缩写。

Phase 4 - connections, bench, and verification

阶段4 - 联系人、候选池与验证

bash

python3 scripts/parse_connections.py --out "$WORK/connections.json" \
  --input "/path/Connections.csv" \
  --input "/path/Basic_LinkedInDataExport_2026.zip"     # append ':Name' to override the owner

Report per-owner totals back to the user. Then verify the bench before presenting it as live routes. Exports carry the employer as of export day and go stale silently - in testing one bench member had already left the account. Spot-check the matched rows with

person_enrich

(

fields: ["basic_profile", "experience"]

) and drop or flag anyone who has moved on.

Two blind spots are structural, cheap to state, and worth stating rather than shipping a map that merely looks complete:

connections with a blank company field match no alias and are invisible
ex-employees are invisible - the export carries current employer only, so someone who spent a decade at the target and just left will never appear despite being an ideal broker

bash

python3 scripts/parse_connections.py --out "$WORK/connections.json" \
  --input "/path/Connections.csv" \
  --input "/path/Basic_LinkedInDataExport_2026.zip"     # 追加 ':Name' 以覆盖所有者

向用户报告每个所有者的联系人总数。然后在将候选池展示为实时路径之前进行验证。导出文件中的雇主信息是导出当日的，会静默过期——在测试中，某候选池成员已离开该客户。使用

person_enrich

（

fields: ["basic_profile", "experience"]

）抽查匹配的行，并删除或标记已离职的人员。

有两个结构性盲点，成本低且值得说明，而非交付一个看似完整的图谱：

公司字段为空的联系人无法匹配任何别名，因此不可见
前员工不可见——导出文件仅包含当前雇主，因此在目标客户处工作了十年但刚离职的人员永远不会出现，尽管他们是理想的中间人

Phase 5 - route resolution

阶段5 - 路径解析

Read

references/chain-scoring.md

for the model and the honesty constraints. Three kinds of route exist, best first, and the builder detects the first two automatically:

Zero hop - the connection is a member of the buying group. Nothing beats this and it is easy to miss, because the bench and the buying group are built by different phases. The builder matches on LinkedIn URL then name; you get it for free.
Date-verified shared history - the connection and a stakeholder worked at the same company at overlapping times. This is the strongest evidenced bridge available, but only if the dates actually overlap: of 13 apparent "we both worked at X" ties in testing, only 3 survived the date check - the rest joined after the target had left. To enable it, enrich the bench members' work history and write
```
careers.json
```
:
json
```
{"https://www.linkedin.com/in/someone": [{"company": "Red Hat", "start": "2021-03", "end": "2023-08"}]}
```
Keyed by LinkedIn URL or lowercase name. The builder does the date arithmetic and records non-overlapping pairs as documented dead ends so nobody rediscovers them.

Org-layer bridge - everyone else. Resolve the senior leader of each function present in the bench, one

person_search

per (account, function) rather than per connection, and write

intermediaries.json

json

{"Acme": {"Engineering": [{"name": "...", "title": "VP, Platform Engineering",
                           "linkedin_url": "...",
                           "basis": "most senior Engineering leader at Acme (person_search, seniority=VP)"}]}}

Always fill

basis

with how you found them and why they qualify. Reporting lines are not in the data, so never phrase a basis as a confirmed manager relationship.

阅读

references/chain-scoring.md

了解模型和诚信约束。存在三种路径，按优先级排序，构建器会自动检测前两种：

零跳——联系人本身就是采购组成员。这是最佳路径，且容易被忽略，因为候选池和采购组是在不同阶段构建的。构建器会通过LinkedIn URL和姓名进行匹配；您可以自动获得此路径。
日期验证的共同经历——联系人和利益相关者曾在同一家公司重叠任职。这是可验证的最强桥梁，但前提是日期确实重叠：在测试的13个看似“我们都在X公司工作过”的关联中，只有3个通过了日期检查——其余的都是在目标人员离开后加入的。要启用此功能，需丰富候选池成员的工作经历并写入
```
careers.json
```
：
json
```
{"https://www.linkedin.com/in/someone": [{"company": "Red Hat", "start": "2021-03", "end": "2023-08"}]}
```
以LinkedIn URL或小写姓名为键。构建器会进行日期计算，并将不重叠的配对记录为已记录的死胡同，避免重复发现。

组织层桥梁——所有其他情况。解析候选池中每个职能的高级领导者，针对每个（客户，职能）调用一次

person_search

，并写入

intermediaries.json

：

json

{"Acme": {"Engineering": [{"name": "...", "title": "VP, Platform Engineering",
                           "linkedin_url": "...",
                           "basis": "most senior Engineering leader at Acme (person_search, seniority=VP)"}]}}

务必填写

basis

字段说明您如何找到他们以及他们符合条件的原因。数据中不包含汇报线，因此永远不要将依据表述为已确认的经理关系。

Phase 6 - signals and plays

阶段6 - 信号与行动方案

Assemble

signals[]

from the hiring surge, the buying signals the sub-agents surfaced, job changes, funding and recent news, newest first with a severity. Then write 3-6

plays[]

naming the connection, the intermediary and the decision maker, citing the signal that makes now the moment. "Reach out to the team" is not a play.

从招聘激增、子代理发现的采购信号、职位变动、融资和近期新闻中组装

signals[]

，按时间倒序排列并标注严重程度。然后撰写3-6个

plays[]

，指定联系人、中间人和决策者，引用为何现在是最佳时机的信号。“联系团队”不是有效的行动方案。

Phase 7 - build and publish

阶段7 - 构建与发布

bash

python3 scripts/build_workspace.py \
  --dossier "Acme=$WORK/acme/dossier.json" \
  --dossier "Globex=$WORK/globex/dossier.json" \
  --connections "$WORK/connections.json" \
  --aliases "$WORK/aliases.json" \
  --intermediaries "$WORK/intermediaries.json" \
  --careers "$WORK/careers.json" \
  --template assets/workspace-template.html \
  --title "Acme + Globex Deal Workspaces" \
  --out "$WORK/workspace.html"

The builder does all the deterministic work: matching connections to accounts, detecting zero-hop and shared-history routes, scoring and ranking every chain, wiring in intermediaries, recording dead ends, and injecting the data. Check its printed summary - warm counts, strong counts, zero-hop, verified ex-colleague, named org layers - before publishing.

Then publish it. Load the

artifact-design

skill (required before the first

Artifact

call), then call

Artifact

with

file_path

$WORK/workspace.html

, a stable title, a one-sentence description and a favicon. The artifact is the deliverable; a workspace left on disk helps nobody. Re-publishing the same file path redeploys to the same URL, which is what makes iteration cheap.

Report the headline numbers: stakeholders mapped, posts analysed, warm chains and how many are strong, zero-hop routes, signals, plays.

bash

python3 scripts/build_workspace.py \
  --dossier "Acme=$WORK/acme/dossier.json" \
  --dossier "Globex=$WORK/globex/dossier.json" \
  --connections "$WORK/connections.json" \
  --aliases "$WORK/aliases.json" \
  --intermediaries "$WORK/intermediaries.json" \
  --careers "$WORK/careers.json" \
  --template assets/workspace-template.html \
  --title "Acme + Globex Deal Workspaces" \
  --out "$WORK/workspace.html"

构建器会完成所有确定性工作：将联系人与客户匹配、检测零跳和共同经历路径、为每条链路打分和排名、接入中间人、记录死胡同、注入数据。在发布前检查其打印的摘要——暖路径数量、强路径数量、零跳路径、已验证的前同事、指定组织层。

然后发布它。加载

artifact-design

技能（首次调用

Artifact

前必填），然后调用

Artifact

，设置

file_path

$WORK/workspace.html

、稳定的标题、一句话描述和图标。工件是交付成果；留在磁盘上的工作区对任何人都没有帮助。重新发布相同的文件路径会重新部署到同一URL，这让迭代变得低成本。

报告关键数据：已映射的利益相关者数量、已分析的帖子数量、暖链路数量及其中强链路数量、零跳路径数量、信号数量、行动方案数量。

Phase 8 - iterate

阶段8 - 迭代

Common follow-ups: add a teammate's export and rebuild, add or re-run a stakeholder, change a deal role, widen the buying group. Each edits the inputs and re-runs Phase 7 to the same URL.

常见的后续操作：添加团队成员的导出文件并重新构建、添加或重新运行某利益相关者分析、更改交易角色、扩大采购组范围。每次操作都会编辑输入项并重新运行阶段7，发布到同一URL。

Guardrails worth holding

值得坚守的准则

Never fabricate, and make the artifact prove it. Every claim carries evidence citing the payload it came from; unevidenced claims go in

gaps

. The evidence dropdowns are why anyone trusts the page, and one confident invention undoes them all.

"No strong chains" is a success, not a failure. If the team's network does not reach the buying function, say so plainly and call the account warm-assisted outbound. Dressing up four weak chains as a way in wastes real social capital. In testing both an unaided run and a skill run reached that verdict independently on the same account, which is the system working.

Watch for name collisions. Company names are not unique and people share names. Verify a match is the right entity before it reaches the bench, and drop procurement "strategic sourcing" roles when you are looking for talent sourcing.

House style for anything sendable. Openers and talking points get pasted into real emails: no em dashes or en dashes, and no legal-entity suffixes in company names.

Adapt the layout to the content - never let it hide anything. The brand system below is fixed; the layout is not. If real content does not fit - a long company or person name, a 12-word title, 40 stakeholders, more chains than the graph can plot - change the layout, not the content: let the card grow, wrap instead of truncating, drop to one column, widen the column, raise the cap, or put the wide thing in its own scroll container. Never solve a fit problem by clipping a card, ellipsis-ing a name, or silently dropping rows. Where a cap really is unavoidable, say so in the UI ("showing the 18 strongest of 34 routes") so the reader knows what they are not seeing. Look at the rendered page (Phase 7's self-review) and fix what is cut off before you hand it over.

Crustdata branding on rendered artifacts. The bundled workspace template carries the real Crustdata brand system - keep it, and never strip it when editing the template:

Wordmark: the official pair ships in this skill's
```
assets/
```
-
```
crustdata-logo-light.png
```
(dark text, for light backgrounds) and
```
crustdata-logo-dark.png
```
(white text, for dark), the same files app.crustdata.com's header renders. Base64-inline the theme-appropriate variant at ~17px tall, linking to crustdata.com; the template shows both and switches them in CSS. Never hotlink a logo - rendered artifacts cannot fetch remote images.
Color: brand purple
```
#5547E2
```
(the product's primary) as the accent;
```
#8387FF
```
(the product's own lightened purple) as the dark-theme accent.
Type: Geist, the product font, embedded as a data-URI
```
@font-face
```
with the system stack as fallback.
Icons: Lucide, the dashboard's icon set, inlined as SVG with a
```
currentColor
```
stroke (the template's
```
licon()
```
helper holds the path data). No emojis in artifact UI.

Any OTHER page or document this skill renders (a one-off summary page, an exported report) carries the same system: base64-inline the wordmark pair from

assets/

behind a "Powered by" eyebrow, and copy the

@font-face

, the accent variables, and the

licon()

icon helper from

assets/workspace-template.html

. This is conditional: chat output and data files stay unbranded, and nothing gets rendered as an artifact just to carry the mark.

绝不编造，让工件自行证明。每项结论都附带引用其来源payload的证据；无证据的结论放入

gaps

。证据下拉框是人们信任此页面的原因，一次自信的编造会毁掉所有可信度。

“无强链路”是成功，而非失败。如果团队的网络无法触及采购职能，要明确说明，并将该客户归类为暖辅助外呼。将四个弱链路伪装成有效路径会浪费真实的社交资本。在测试中，手动运行和技能运行针对同一客户都得出了此结论，这表明系统运行正常。

注意名称冲突。公司名称不唯一，人名也会重复。在候选池确认匹配正确实体之前进行验证，当您寻找人才采购角色时，剔除采购部门的“战略采购”职位。

任何可发送内容的统一格式。开场白和沟通要点会被粘贴到真实邮件中：不要使用长破折号或短破折号，公司名称中不要包含法律实体后缀。

根据内容调整布局——绝不隐藏任何内容。以下品牌系统是固定的；布局则不是。如果真实内容无法适配——过长的公司或人名、12字的头衔、40名利益相关者、图谱无法容纳的过多链路——请更改布局，而非内容：让卡片扩大、换行而非截断、改为单列、加宽列、提高上限，或将宽内容放入独立的滚动容器。绝不要通过裁剪卡片、省略人名或静默删除行来解决适配问题。当确实需要设置上限时，要在UI中说明（“显示34条路径中最强的18条”），让读者知道他们看不到的内容。查看渲染后的页面（阶段7的自我检查），在交付前修复被截断的内容。

渲染工件上的Crustdata品牌。捆绑的工作区模板带有正式的Crustdata品牌系统——请保留，编辑模板时绝不要移除：

标志：正式的标志对包含在本技能的
```
assets/
```
中——
```
crustdata-logo-light.png
```
（深色文字，用于浅色背景）和
```
crustdata-logo-dark.png
```
（白色文字，用于深色背景），与app.crustdata.com页眉显示的文件相同。将适合主题的变体转换为base64内联，高度约17px，链接到crustdata.com；模板包含两种变体，并通过CSS切换。绝不要热链接Logo——渲染的工件无法获取远程图片。
颜色：品牌紫色
```
#5547E2
```
（产品主色）作为强调色；
```
#8387FF
```
（产品自身的浅紫色）作为深色主题强调色。
字体：Geist，产品字体，作为data-URI
```
@font-face
```
嵌入，系统字体栈作为备选。
图标：Lucide，仪表板的图标集，作为SVG内联，使用
```
currentColor
```
描边（模板的
```
licon()
```
助手包含路径数据）。工件UI中不要使用表情符号。

本技能渲染的任何其他页面或文档（一次性摘要页、导出报告）都应使用相同的系统：从

assets/

中获取标志对，以base64内联在“Powered by”标题下方，并从

assets/workspace-template.html

复制

@font-face

、强调色变量和

licon()

图标助手。此规则有条件：聊天输出和数据文件保持无品牌，不要仅为添加标志而将内容渲染为工件。

Tool dependencies

工具依赖

Crustdata MCP server (install.crustdata.com/mcp): a single Code Mode MCP exposing
```
list_tools
```
,
```
get_schema
```
, and
```
execute
```
. All Crustdata data tools are reached inside an
```
execute({ code })
```
plain-JavaScript script via
```
await callTool(name, params)
```
— author against the typed surface from
```
get_schema
```
, but write zero type annotations in the body. Tools used here:
```
company_identify
```
,
```
company_enrich
```
,
```
person_search
```
,
```
person_autocomplete
```
,
```
person_enrich
```
,
```
person_contact_enrich
```
,
```
job_search
```
,
```
social_post_list_live
```
,
```
web_search_live
```
(alias research),
```
account_credits
```
Python 3 for
```
scripts/parse_connections.py
```
and
```
scripts/build_workspace.py
```
(pure local processing, no network calls)
Artifact tool for publishing the workspace HTML

Crustdata MCP服务器（install.crustdata.com/mcp）：一个Code Mode MCP，暴露
```
list_tools
```
,
```
get_schema
```
, 和
```
execute
```
。所有Crustdata数据工具都通过
```
execute({ code })
```
纯JavaScript脚本中的
```
await callTool(name, params)
```
调用——根据
```
get_schema
```
的类型化接口编写，但在脚本主体中不要添加任何类型注解。此处使用的工具：
```
company_identify
```
,
```
company_enrich
```
,
```
person_search
```
,
```
person_autocomplete
```
,
```
person_enrich
```
,
```
person_contact_enrich
```
,
```
job_search
```
,
```
social_post_list_live
```
,
```
web_search_live
```
（别名调研）,
```
account_credits
```
Python 3：用于
```
scripts/parse_connections.py
```
和
```
scripts/build_workspace.py
```
（纯本地处理，无网络调用）
Artifact工具：用于发布工作区HTML

Bundled resources

捆绑资源

```
scripts/parse_connections.py
```
- normalises LinkedIn exports, auto-detects owner from Profile.csv
```
scripts/build_workspace.py
```
- bench matching, zero-hop and shared-history detection, chain scoring, HTML injection
```
assets/workspace-template.html
```
- the self-contained multi-account workspace renderer
```
references/dossier-schema.md
```
- the per-account dossier contract; read before writing one
```
references/stakeholder-agent.md
```
- the deep-dive sub-agent prompt; read before Phase 3
```
references/chain-scoring.md
```
- how routes are scored and resolved honestly; read before Phase 5

```
scripts/parse_connections.py
```
- 标准化LinkedIn导出文件，从Profile.csv自动检测所有者
```
scripts/build_workspace.py
```
- 候选池匹配、零跳和共同经历检测、链路打分、HTML注入
```
assets/workspace-template.html
```
- 独立的多客户工作区渲染器
```
references/dossier-schema.md
```
- 单客户档案契约；撰写前请阅读
```
references/stakeholder-agent.md
```
- 深度分析子代理提示；阶段3前请阅读
```
references/chain-scoring.md
```
- 路径如何被诚实打分和解析；阶段5前请阅读