cargo-project

Cargo 项目 — 在仓库中声明 Cargo 工作区

使用此技能在 TypeScript 中定义 Cargo 工作区（使用 @cargo-ai/cdk 中的 define* 构建器），并通过 cargo-ai project deploy 将其与 实时基础设施协调一致。它是命令式能力技能的声明式对应方案：无需为每个资源运行一条 CLI 命令，而是一次性编写整个资源图，并可重复部署；同时使用部署状态——保存在工作区中，并由已提交的 cargo.state.json 指向——将代码与 Cargo 创建的内容关联起来。项目 是存放 cargo.json（{ "resources": "infra" }）的文件夹：每条 cargo-ai project 命令都会查找其运行位置上方最近的项目；如果没有找到，就会停止。

“项目”和“工作区”是两回事——请勿混淆。 工作区是你登录的 Cargo 租户：其中保存模型、连接器、Agent、邮箱和额度；它也是 login --workspace-name 选择的对象，也是 whoami 报告的对象。项目是存放 cargo.json 的文件夹，用于声明资源并将其部署到工作区：它由 project init 创建，其中存放 cargo.state.json，并且所有命令都会通过向上查找最近的 cargo.json 来找到它。一个仓库可以包含多个项目，每个项目各有一个 cargo.json。一个项目每次只能部署到一个工作区——如果状态中的工作区不是当前选定的工作区，工作区保护机制会拒绝部署——同一个项目可以通过不同的部署状态，分别部署到开发和生产工作区。请称其为“项目”，不要将项目目录命名为 my-workspace。

引导设置

如果已经登录（cargo-ai whoami 会返回一个工作区），请跳至下一节。

npm install -g @cargo-ai/cli            # no global install? prefix every command with `npx @cargo-ai/cli`
cargo-ai login --email [email protected]  # emailed code, no browser; creates the account on first use
                                        # alternatives: --oauth (browser) · --token <api-token> (CI)
cargo-ai whoami                         # confirm the active workspace before any write
cargo-ai project --help                     # `unknown command` = CLI too old; reinstall @cargo-ai/cli@latest

项目还需要满足两项特定要求：项目必须将 @cargo-ai/cdk 作为依赖项，以便导入其中的 define* 构建器（cargo-ai project init 会创建包含该依赖项的 package.json，随后运行 npm install）；cargo-ai project 命令域则随 CLI 本身一起提供。

每条命令都会向 stdout 输出 JSON；失败时会以非零状态退出，并返回 {"errorMessage": "..."}。任何会创建运行或批次的操作都是异步的——请传入 --wait-until-finished，或轮询对应的 get 命令。安装完整技能包后，../cargo/references/prerequisites.md 会补充 CLI 版本固定、令牌作用域和仅限管理员使用的功能。

1) 此技能涵盖的内容

• 编写每种 Cargo 资源，并使用返回句柄的 define* 构建器；将句柄传给其他资源以连接资源（依赖关系图就是变量图）。
• 部署资源图：plan（离线差异）→ deploy（创建或更新，并写入状态）→ destroy（拆除）。此外还包括漂移处理（refresh）、接管已有资源（import）和恢复（rollback）。
• 类型检查配置，使其符合工作区中的实际集成架构（cargo-ai project types）。

项目涵盖所有资源类型，因此与每项命令式能力技能都有交集（cargo-connection、cargo-storage、cargo-ai、cargo-orchestration、 cargo-content、cargo-hosting，等等）。首先要决定应使用哪一种：

2）项目还是 CLI？——路由决策

声明式（此技能）与命令式（能力技能）。

当用户将资源作为构件进行管理时，使用项目：

• “搭建／启动／初始化整个工作区（以代码形式／使用模板）。”
• “让它可复现／受版本控制／纳入 git／可在不同环境（开发 → 生产）中重复部署。”
• “将这些连接器 + 模型 + Agent 一起部署”（由依赖关系连接起来的多资源图）。
• 任何需要能够重新运行和比较差异，且丢失定义会造成问题的情况。

当用户要进行一次性操作或探索时，使用相应的能力技能（命令式 cargo-ai <domain>）：

• “创建一个连接器”、“向这个模型添加一列”、“列出连接器”、“运行这个工作流”、“查询存储”、“读取这个 Agent 的记忆。”
• 任何无需写入代码的读取、临时查询或单次修改。

不确定时，询问结果是否需要提交并可重新部署。如果需要 → 使用项目；如果只是快速操作或读取 → 使用能力技能（参阅cargo 路由器选择正确的领域）。

开始编写前：先复述，再只询问无法读取的信息

项目请求通常只有一句话（“每周为我们的账户评分”），而从这句话到已部署资源图之间的差距，正是构建出错的根源。在第一个 define* 文件出现之前就弥合这个差距，而不是等到计划完成之后。

1. 先读取。 查看 cargo-ai whoami、connection connector list、storage model list、项目现有的 infra/，以及 references/cookbooks.md。切勿询问这些信息能回答的问题（连接了哪个 CRM、是否存在 Companies 模型、是否已有适用的操作指南）。
2. 用四行复述构建内容：持续到达的数据及其落点；触发方式（计划任务、webhook、记录变更）；读取和写入的内容；每次运行的成本（付费节点、记录数量、运行频率）。
3. 最多提三个问题，仅询问用户才知道的信息：哪些记录符合条件（细分条件）、结果写到哪里（某个渠道或 CRM 字段）、数据量或积分上限。每个问题都给出一个建议默认值，让用户回答“是”即可确认全部内容。
4. 等待用户确认后再编写。 如果用户已经表示直接构建，或请求中已明确所有部分，就将复述内容作为已陈述的假设继续执行；之后由计划审查环节让用户纠正。

操作指南中的 What you will be asked 表格已针对相应结果梳理好这一步：使用该表格，不要临时编造问题。

3) 生命周期

cargo-ai project init <dir>     scaffold the Cargo template: cargo.json + cargo.state.json, resources in infra/
        │
cargo-ai project types          generate per-workspace types for typed config (optional)
        │
   (author define* files)   importing a .ts file IS registration — no list to keep
        │
cargo-ai project plan           compile the graph, diff against the deploy state (creates nothing)
        │
cargo-ai project deploy         create/update resources in dependency order, write state
        │
cargo-ai project destroy        tear down resources recorded in state

project plan 说明哪些资源会发生变化；它不会展示一次 play 的执行过程。 对于超过三个节点的 definePlay / defineTool 图，除了计划，还应提供节点图的 Mermaid 流程图——路由、回退方案，以及每次定时运行都会产生费用的节点，都是审核者需要批准的内容。首次部署后， 从已部署的版本生成流程图；编写代码时，则从节点数组生成： ../cargo-orchestration/references/node-diagram.md。

其他分支：cargo-ai project check（验证目录树，不检查状态，也不调用 API — 这是 plan 的 CI／编辑器子集）· cargo-ai project info（查看这里有哪些内容：每个已声明资源、声明它的文件，以及它是否已部署）· cargo-ai project refresh （只读漂移报告）· deploy --refresh（覆盖代码之外的更改，重新应用代码）· deploy --prune（删除代码中已移除的资源）· cargo-ai project import <id> <uuid> （将现有的线上资源绑定到状态）· cargo-ai project pull（从线上工作区生成 define* 源代码并将其纳入管理）· cargo-ai project rollback（恢复部署前的状态快照）· cargo-ai project state（检查并重定向部署状态； 使用 state connect 从 GitHub 部署）· cargo-ai project graph（生成线上工作区资源的 Mermaid 图，或使用 --project [--plan] 查看本地代码）· deploy --dry-run / --draft（预览／暂存，但不正式上线）。

plan 和 info 回答的是不同问题。 plan 回答部署将执行什么 — 它以变更为单位，并以非零状态码退出，因此 CI 可以据此进行门禁检查。info 回答这里有哪些内容 — 它以资源为单位，且永远不会失败。check 是不包含差异对比的 plan： 它不需要状态，因此适用于编辑器或提交前钩子。运行不带子命令的 cargo-ai project 会显示帮助信息。

4) 文档层级

• 第 1 级 — SKILL.md（本文件）：决策模型、生命周期、关键规则和路由。
• 第 2 级 — 指南： guides/authoring-resources.md、 guides/deploy-and-state.md、 guides/executions.md、 guides/typed-config.md。
• 第 2.5 级 — 配方：recipes/*.md — 可按步骤执行的操作手册，可作为执行计划。
• 参考文档 — references/resources.md（完整的构建器目录）、references/commands.md（每个 cargo-ai project 子命令和标志）、 references/troubleshooting.md，以及 references/examples/full-workspace.md。

5) 阅读行为——根据任务找到文档并阅读

当任务涉及……	首先阅读	可了解的内容
编写 define* 文件、连接资源、使用 secret()/env()、编写 defineWorkflow 函数体（工具/播放逻辑）	guides/authoring-resources.md	构建器目录、句柄/引用模型、密钥，以及工作流函数体的编译方式。
plan / deploy / destroy、状态文件、漂移、接管现有资源、CI	guides/deploy-and-state.md	部署生命周期、cargo.state.json 语义、漂移/导入/回滚、异步构建。
从代码中一次性运行 play、工具或工作流（defineBatch / defineRun、outputs/、账本）	guides/executions.md	构建器、data 类型、执行记录的存放位置、plan 的输出内容、恰好一次账本及其状态。
类型化配置、cargo-ai project types、tsconfig 配置、工作流函数体中的 uses.<key>.<action> 连接器调用	guides/typed-config.md	project types 会生成什么内容，以及如何将其接入项目。
特定构建器的字段/规范/输出	references/resources.md	每个构建器 → 规范字段 → 各字段接受的引用 → 输出。
精确的命令标志	references/commands.md	每个 cargo-ai project 子命令及其标志。
部署错误/易踩坑之处	references/troubleshooting.md	已知故障模式及其修复方法。
编写已知的 GTM 成果之前；或成果配置完成后该推荐什么	references/cookbooks.md	按阶段排序的 Cookbook 菜单：包含完整项目示例的 gtm-skills、每个技能支持的适配方式，以及接下来该推荐什么。

操作手册 — 从头构建已知结果前，先查看菜单

getcargohq/gtm-skills 除了包含一次性技能，还收录了操作手册：其中的技能附带经过验证的项目资源，可完成与已部署管道相同的工作，并持续产出结果（TAM 构建、账户评分、通话记录、入站资格评估、CRM 数据补全、停滞交易提醒等）。每个文件夹都自成一体：拥有自己的模型、连接器和文件夹，没有共享基础，也没有 requires 依赖图。

菜单位于本地：references/cookbooks.md。 从头构建常见的 GTM 结果前，请先阅读；设置好某个操作手册后，也要再读一次：菜单按阶段顺序列出这些手册，而这个顺序就是接下来应推荐的内容——最靠前且尚未设置的操作手册。它由 gtm-skills 的 catalog.json 生成，因此不会出现偏差。

操作手册是经过验证的示例，不是待填写的模板。 每个手册都会在其 SKILL.md 中说明哪些内容可以调整、哪些内容必须保持不变，否则手册就无法正常运行，以及无论如何都必须回答哪些问题；每个手册也都附带自己的操作步骤。 project add 是这些步骤中的复制环节：

cargo-ai project add cookbook/tam-building               # inside a project
cargo-ai project init my-project --cookbook tam-building # no project yet: both at once

该命令会将资源写入 infra/tam-building/，并将操作步骤写入 .claude/skills/tam-building/，跳过任何会覆盖现有文件的操作。然后从技能的 Adapt 部分开始执行——开头几步是为在 GitHub 上找到该文件夹、但尚未将它放入项目的人编写的；如果从头开始照做，就会搭建第二个项目，并再次复制该文件夹。

复制后剩下的工作只有你能完成：核对已有声明，在原处调整复制的文件，使其符合项目的实际情况（不要根据技能的说明文字重新生成这些文件——安全性由 TypeScript 保证），进行规划并暂停，获得肯定答复后再部署，最后按照其 Done when 检查完成情况。

如果你正在处理任务，而当前会话中没有该技能，npx skills add getcargohq/gtm-skills/<slug> 会单独获取操作步骤，你可以直接阅读 .agents/skills/<slug>/SKILL.md；无需重新加载。若要在不安装的情况下阅读，运行 npx skills use getcargohq/gtm-skills@<slug> 即可查看。两种方式都不会获取项目资源——要获取资源，仍需使用 project add。

路由规则：一次性需求还是持续运行。 想要今天获得一份列表的用户需要 cargo-gtm（或 gtm-skills 的一次性技能 build-tam-list）；想要一个持续生成列表的管道的用户需要 tam-building。两者的说法可能相同（“构建我们的 TAM”），因此要留意用户是否希望结果持续产出。符合某个操作手册 → 安装并遵循它。没有符合的手册 → 根据下方的配方构建。

绝不要在非空目录中运行 cargo-ai project init --force。 它会替换项目的 package.json 并还原已调整的代码，但 cargo.state.json 会保留，因此下一次 plan 会将正在使用的工作区与无人编写的代码进行差异比较。请将技能文件夹复制为同级目录。

每个操作手册的状态都列在菜单的 State 列中。approved 表示该手册已部署到实际工作区并运行，且已检查结果；to-be-approved 表示它通过了类型检查和规划，但尚未经过部署验证，因此推荐时要说明这一点。无论状态如何，都应将技能的 Done when 作为验收测试，并在部署前检查 cargo-ai project plan。

Recipes — 在适用时按步骤操作

配方	适用场景……
recipes/scaffold-a-project.md	从头搭建新项目（init → types → plan → deploy）。
recipes/add-connector-and-model.md	添加数据源和一个以该数据源为来源的模型，并通过 handle 连接。
recipes/build-an-agent.md	组合模型、工具和 Agent（通过 uses 连接）并进行部署。
recipes/migrate-existing-workspace.md	通过 project import 将已上线的工作区纳入项目。
recipes/deploy-from-ci.md	为每个 PR 执行计划，并在每次合并后部署：连接 GitHub 仓库（project state connect），或者在无法连接时使用令牌配置自己的 CI。

6) 关键规则

• 提交 cargo.state.json——它现在是指针，而不是状态。 部署状态保存在你的工作区中；仓库只提交 {"stateUuid": "8f2c…"}。project init 会创建状态并写入该 指针，因此它会包含在脚手架提交中。请提交它：没有这个 uuid，全新 检出就无法找到状态，而且部署不会悄悄创建替代状态（否则旧状态跟踪的所有内容都会变成孤立资源）。状态只记录 uuid、哈希和输出——绝不包含机密值。它仍然是已部署的播放、Agent 或提醒的唯一 句柄（它们没有 slug）；链接丢失时，可用 project state bind <uuid> 恢复，或通过 cargo-ai project import 按资源恢复。将工作文件加入 Git 忽略列表（project init 会生成 此配置）：

  .cargo-ai/
  cargo.state.lock
  cargo.state.bak.json
  cargo.state.cache.json
  cargo.state.audit.jsonl
  

  每个项目只能有一个状态，并且每个工作区最多有 10 个活动状态：

  cargo-ai project state list            # every state here, and which one this project is on
  cargo-ai project state create          # create one for this project, write the pointer
  cargo-ai project state bind <uuid>     # repoint at an existing one
  

  在状态迁移到工作区之前创建的项目，其资源映射内嵌在 cargo.state.json 中，只要该文件保留，就会继续基于该文件进行部署——不会在后台自动迁移。执行 state create 才会进行迁移：映射会移到新状态中，文件则变为指针，然后提交该文件。迁移前请告知团队，因为如果队友在拉取新指针前进行部署，他们将基于一个已不存在的状态部署。 （删除状态：cargo-ai project state remove <uuid> 会删除状态，但不会触碰它跟踪的在线资源；若 cargo.state.json 指向该状态，则需使用 --force。）
• 有三种方式传入值，彼此不可互换。
  • secret("ENV_VAR")——在部署时从你的环境中读取，不纳入内容哈希或状态。部署前导出环境变量；若缺少该变量，部署会因 ${ENV_VAR} 占位符未解析而失败。
  • env("ENV_VAR")——在加载时从你的环境中读取，其值会纳入规格，因此也会纳入内容哈希。更改该值会显示为漂移。适用于你希望跟踪的非机密配置。
  • workspaceEnv("NAME")——指向工作区环境变量目录条目的指针。本地不会读取任何内容，也不会因此失败；该值保留在服务端，每次使用时都会重新读取，因此在工作区轮换该值后，资源会立即获取新值，无需重新部署。使用 cargo-ai workspaceManagement envVar 管理目录（参见 ../cargo-workspace-management/SKILL.md）。 secret() 和 workspaceEnv() 仅可用于类型为 secret 的架构位置——cargo-ai project types 会在且仅在这些位置打印联合类型。资源自身的 env 块接受 env() 或 secret()，并拒绝指针，因为 worker、应用、Agent 或脚本已经继承了整个工作区目录；在此处使用指针只会重复声明它本就能读取的变量。
• 轮换 secret() 后，光执行普通部署还不够。 将该值排除在内容哈希之外，可以避免轮换被视为漂移——但这也意味着 deploy 不会推送新值：哈希没有变化，因此资源不会重新应用。使用 deploy --refresh 轮换，或对该资源进行其他编辑。workspaceEnv() 无需此步骤；这也是它大部分吸引力所在。
• 通过句柄连接，绝不要使用 .uuid。 直接传入 define* 句柄（connector: hubspot、uses: [enrich]），或对代码中未定义的资源使用 xxRef("uuid")（connectorRef、modelRef、folderRef、toolRef、agentRef，等等）。引用需要按调用传入选项时，将其包装为 { ref, …options }（例如 uses: [{ ref: contacts, readOnly: true }]）。
• 工作区集成发生变化后，运行 cargo-ai project types——它会重新生成 .cargo-ai/，使 defineConnector/defineModel 配置（以及工作流主体中通过 uses 调用的 connector 操作）能根据实际架构进行类型检查。类型检查是额外保障，绝不是门槛：没有它也能部署。
• 项目是包含 cargo.json 的文件夹（@cargo-ai/cdk ≥ 1.0.112）。 该文件指定存放要加载的 .ts 文件的文件夹，{ "resources": "infra" }，并可选指定执行文件的位置，"executions": ["outputs"]（默认是 cargo.json 同级的 outputs/，会在任意深度读取；* 段可匹配文件夹，例如 ["outputs/*/executions"]——参见 guides/executions.md）。每条命令都会从运行位置向上查找，最远到仓库根目录，直到找到最近的 cargo.json，因此任何子目录都可用；包含多个项目的仓库中，每个项目各有一个 cargo.json，并以最近的为准。如果没有该文件，命令就会停止——不再根据 infra/ 文件夹或 package.json 猜测——并打印在项目根目录添加该文件的命令：

  echo '{ "resources": "infra" }' > cargo.json
  

  cargo.state.json 位于与 cargo.json 同级的位置，绝不放在 infra/ 中。遗留的 infra/cargo.state.json 会导致所有命令停止，并提示要运行的 mv 命令（存在两个状态文件时也会停止；保留指向此项目状态的那个）。--dir <path> 仍然可用：它指定从何处开始查找。资源应放在 infra/ 中，而非根目录，因为加载器会导入 resources 指定文件夹下的所有 .ts 文件，而仓库根目录也存放 scripts/——其中的文件会在导入时运行。
• 在 CI 中使用 --yes。 deploy 和 destroy 会请求确认；非交互式运行必须传入 --yes。
• 连接 GitHub 仓库后，合并时会部署——连接时也会部署。 cargo-ai project state connect 会在评论中规划每个 PR，并在每次推送到生产分支时运行 deploy --yes，从连接当刻的分支头提交开始（仅规划可使用 --no-auto-deploy）。如果合并后，播放和执行的总量会超过 100 封邮件、100 次 LinkedIn 操作、100 条聊天消息、5,000 次受众添加或 2,500 个积分，或无法计算，则会失败并提示 Needs approval: large impact，直到有人为 PR 添加 cargo:approve-impact 标签。该标签代表用户对费用的批准：只有用户明确同意后才能添加。此处无法解析 secret()（请使用 workspaceEnv()）；自动部署开启期间，状态的其他所有部署都会被拒绝（409 stateAutoDeployed）——应移除 GitHub Actions 部署，而不是两者并行运行。参见 recipes/deploy-from-ci.md。
• 包含付费节点的 definePlay/defineTool 图，在全面运行前需先进行样本运行。 部署不等于运行，但已部署播放第一次运行时，通常会对整个细分受众群执行批处理；计划播放则会在每次运行时为每个节点再次计费。在让所有对象加入（或启用计划任务）之前，先对10–20 条记录运行已部署工作流——cargo-ai orchestration batch create --workflow-uuid <uuid> --data '{"kind":"filter","modelUuid":"…","filter":…,"limit":15}'，或者使用 batch create --file ./plays/x.ts --data '…'，在不部署的情况下对模块进行试运行——然后向用户说明记录数和积分预估，并请用户批准全部加入。请阅读提供商的操作指南（../cargo-gtm/provider-playbooks/<slug>.md，尤其是 Recurring use 部分）以及 ../cargo-gtm/references/cost-discipline.md 中的审批关卡。
• 一次执行只会运行一次，在下一次部署时运行，无法撤销，也不会重试。 outputs/（或 cargo.json 中 executions 指定的文件夹）下的 defineBatch / defineRun 文件，会在资源应用后启动真实的批处理或运行；播放批处理可能会发送邮件并执行 LinkedIn 操作，同时消耗积分，回退代码也无法收回这些操作。对整个受众执行 filter / segment 就是完整批处理：在执行前先试运行，并根据 ../cargo-gtm/references/cost-discipline.md 按记录数和积分预估获得批准，之后才能进行 deploy（或在已连接的仓库中合并）。执行账本保存在工作区状态中，因此被拒绝或已完成的执行绝不会再次运行——请为其指定新 ID；执行需要工作区状态，在 --draft 下绝不会运行。参见 guides/executions.md。
• defineAlert 的操作调用付费节点时，每次触发都会再次计费。 警报的 actions 会作为真实运行触发，因此，如果 threshold 设置不当且 schedule 间隔很短，就可能每个周期都触发并计费。部署前使用 cargo-ai observability alert preview 设置合适的阈值；优先采用低成本的通知操作（例如发布消息的 Agent、connector 通知），避免使用会扩大发送范围的操作；如果操作会调用按积分计费的提供商，则同样遵循上述费用审批关卡。范围、阈值和触发语义见 ../cargo-observability/SKILL.md。
• defineMailbox 按月计费，defineDomain 则拥有其发布的记录。 邮箱只要存在，每月就会产生 100–125 个积分的费用（shared/private 为 100，google 为 125；可通过 cargo-ai mailboxManagement pricing get 获取实时价格），因此计划中出现 + create mailbox:… 就代表用户批准了一笔持续费用，而非一次性费用。邮箱的 domain、username 和 type 只能在创建时设置——修改其中任何一项都需要销毁并重建，也就是说会创建一个全新的收件箱，并从 45 天预热周期的起点重新开始。创建邮箱前，部署会轮询域名的 refreshStatus，最多等待 5 分钟，直到域名变为 active；它不会等待新邮箱，新邮箱会保持 pending，直到提供商发放凭据。对于 defineDomain，dnsRecords 是部署负责管理的记录集合，会与当前 DNS 区域合并：注册商购买域名时写入的记录以及部署之外添加的记录都会保留（但有一条记录无法与已声明的 CNAME 使用同一名称）。部署拥有其发布的记录，因此从列表中删除某条记录后，它会在下一次部署时被删除；[] 会删除此前部署发布的所有记录。省略 dnsRecords 可保持 DNS 区域不变；某个条目可以是应用的 domainRecords。请在代码中编辑受管理的记录，而不是在注册商 UI 中编辑：在外部编辑会导致部署停止（dns record … was edited outside the deploy）。未声明的 redirectUrl、dmarcEmail 和 dmarcPolicy 会保留当前值。对于在 UI 中购买的域名或邮箱，请使用 adopt: true（已接管的域名在部署发布记录前不拥有任何记录）。有关预热、抑制和发送的信息，参见 ../cargo-mailbox-management/SKILL.md。
• 将项目管理的资源路由到名称明确的文件夹。 在每个构建器上设置 folder:，让项目拥有的所有资源都进入专属文件夹；其名称应向 UI 用户明确表示“由代码管理——请勿手动编辑”（手动进行的 UI 编辑会在下一次 plan 时被识别为漂移）。文件夹按类型划分，因此每种类型都应有自己的文件夹，但共用一个简短易辨认的前缀——建议使用 🔒 Project（例如 🔒 Project Models、🔒 Project Agents）。名称应简短（过长的标签会在文件夹树中截断）；锁形 emoji 表示“请勿改动”。参见 guides/authoring-resources.md。

帮助

• 使用 cargo-ai project --help 和 cargo-ai project <subcommand> --help 查看当前可用的标志。
• 如果记录的命令／标志／响应与实际观察到的内容不符，请提交报告：cargo-ai workspaceManagement report create（参见 ../cargo-workspace-management/SKILL.md）。