需要把 GTM 知识（ICP、人物画像、打法、异议…

在 Cargo 工作区的 context 仓库中读写 GTM 知识库文件，并构建/查询其知识图谱。

适用场景

解决思路

1. 先确认已登录：运行 `cargo-ai whoami` 检查工作区；未登录则执行 `npm install -g @cargo-ai/cli`（无全局安装时每条命令前加 `npx @cargo-ai/cli`），再用 `cargo-ai login --email you@company.com`（邮件验证码，无浏览器；首次使用会创建账号），或用 `--oauth`（浏览器）或 `--token <api-token>`（CI）。
2. 在首次写入前用 `cargo-ai whoami` 确认目标工作区（workspace.uuid、workspace.name），把工作区名读回给用户确认；若名称含糊（如 Main、Test、人名、内部代号），先向用户询问公司名和规范域名（example.com）并确认；若登录时未绑定工作区，重新执行 `cargo-ai login --oauth --workspace-uuid <uuid>` 或 `--token <workspace-scoped-token>`。
3. 编辑前先探查现有内容：`cargo-ai context runtime browse` 列出运行时沙箱根目录条目，`cargo-ai context graph get` 获取由仓库 md/mdx 文件派生的完整知识图谱。
4. 浏览与读取：`cargo-ai context runtime browse [--path <path>]` 列出子路径条目；`cargo-ai context runtime read --path <path> [--start-line <n>] [--end-line <n>]` 读取整文件或行区间（1 起始、两端包含）。
5. 写入新文件：`cargo-ai context runtime write --path <path> --content <content> [--commit-message <message>]`，会创建或覆盖文件并向默认分支推送提交。
6. 每个 .md/.mdx 文件开头写 YAML frontmatter，设置 `title` 和 `description`；frontmatter 不会被校验，缺失/为空/格式错误仍会写入并提交，只是图谱索引效果差（缺 title 回退到文件名，节点摘要回退到首段）。
7. 编辑已有文件：`cargo-ai context runtime edit --path <path> --old-string <old> --new-string <new> [--commit-message <message>]`，替换唯一匹配的子串；`--old-string` 必须在文件中恰好出现一次；`--new-string` 传空字符串即删除匹配内容。
8. 较大重构时优先用 `write` 整文件覆盖，而不是多次连续 `edit`。
9. 在沙箱中执行命令：`cargo-ai context runtime execute --command <command> [--args <json>]`，`--args` 是字符串参数的 JSON 数组，无参命令可省略；execute 的改动不会推送，仅用于构建、测试或检查。
10. 利用只读的 `.files/` 目录：工作区通过 `cargo-ai content file upload` 上传的 PDF、CSV、文本会出现在沙箱 `.files/` 下，可被 execute/read/browse 读取（如 `cargo-ai context runtime execute --command ls --args '["-1",".files"]'`）；该目录在提交树之外，不会被推送，也不能在此增改内容文件。
11. 按领域组织文件：`global/`（公司使命、语气、定位、叙事、定价）、`icp/`（理想客户画像）、`persona/`（买家角色）、`jtbd/`（待办任务）、`alternative/`（竞品、替代方案、现状）、`client/`（客户档案、案例、参考账号）、`insight/`（市场洞察）、`medium/`（渠道打法）、`objection/`（异议+回应+证据）、`play/`（GTM 打法：信号→受众→渠道→序列→结果）、`proof/`（原子化证据点）、`signal/`（购买信号与意图触发）。
12. 遵循文件命名与引用约定：文件名用 `kebab-case.md`；交叉引用用 `domain/slug` 形式且不带 `.md` 扩展名（如 `persona/vp-sales-mid-market`）。
13. 要让引用成为图谱边，必须使用三种形式之一：frontmatter 的 `references:` 列表（引用来源时首选）、正文中的 Markdown 链接 `[label](path)`、或正文中的 wikilink `[[path]]`（扩展名可选）；纯文本中裸写路径不会生成边。
14. 引用路径优先用根相对路径（先从仓库根解析，再相对引用文件解析）；扩展名可选，解析器会按 .md、.mdx、.yaml、.yml 顺序自动尝试；目标文件必须存在，否则边会断裂，引用前用 `runtime browse` 验证。
15. 新增条目前先读取该领域的模板：`cargo-ai context runtime read --path persona/_template.md`；`_template.*` 文件被排除在图谱外，永远不要引用它们。
16. 新增条目流程：确认目标领域并复制其模板 → 用 `write` 在 `<domain>/<slug>.md` 写入含 `title` + `description` 和正文各节的完整内容 → 在合适处添加 `domain/slug` 交叉引用（必要时保持双向）→ 运行 `cargo-ai context graph get` 重建图谱以验证新条目及其链接。
17. 从销售通话分析得出的编辑应逐条应用并人工审核，不要批量处理；用 agent 循环处理大量通话容易过度放大最响亮的信号而遗漏细节。
18. 引导与刷新生命周期：一次性引导（从公开来源播种 global/、persona/、client/、proof/、objection/、signal/，再针对播种后的仓库开启新的 agent 会话）；每 2–4 周刷新（拉取最近约 3 个月销售通话记录 → 逐条分析、人工在环 → 应用重复阈值后才把结论提升到 context → 通过生成序列排列验证 → 对比前后图谱并淘汰过时条目）。
19. 用 `cargo-ai context graph get` 查询知识图谱：审计跨领域交叉引用（如找出链接到 play 但没有 proof 的 persona）、写新条目前发现已有内容避免重复、为需要工作区类型化结构的下游 agent 提供支持；响应包含每个节点的解析后 frontmatter 和出站 `domain/slug` 引用，可用 jq 切片。
20. 任何创建 run 或 batch 的命令都是异步的，传 `--wait-until-finished` 或轮询对应的 `get`；所有命令向 stdout 打印 JSON，失败时以非零退出并输出 `{"errorMessage": "..."}`。
21. 用 `--help` 查看帮助：`cargo-ai context --help` 及各子命令（runtime browse/read/write/edit/execute、graph get）的 `--help`。

适用边界 · 注意事项

• 通过分析赢单/丢单数据来发现谁真正购买时——那是 cargo-gtm 的职责，本技能只把结论写下来，不负责推导。
• 需要存储结构化记录而非散文时——使用 cargo-storage。
• 需要把文档作为 RAG 附件挂到 agent 时——使用 cargo-content（`cargo-ai content file upload`）；上传运行时无关文件（CSV、PDF）用于批量运行时用 cargo-workspace-management（`cargo-ai workspaceManagement file upload`）。