关于 gtm-workspace
用于创建和维护组织 GTM 工作区的 Skill，将公司信息、成员资料和共享标准以 Markdown 文件保存在本地工作区中。它负责工作区结构与健康检查，并要求事实可核实、变更经批准且提交到 Git。
主要功能
- 01创建或导入工作区
- 02维护组织与成员资料
- 03检查工作区结构和文件
- 04按批准内容修复偏差
- 05Git 提交及远程同步
适用场景
- 01为组织建立 GTM 工作区
- 02更新公司事实或成员信息
- 03检查并修复工作区布局
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/gtm-workspace确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/company-data.mdcontract.mdinteraction.mdinteractions.mdperson-data.mdupdates.mdscripts/check-update.mjstemplates/AGENTS.mdCLAUDE.mdgitignoreMEMBER.mdORG.mdtests/check-update.test.mjsinteraction.test.mjs详细介绍
GTM 工作区
触发条件
当请求涉及整个 GTM 工作区、组织事实或其成员时，应用此技能。
范围
一个工作区在 ~/.gtm/<org-slug>/ 下以 Markdown 的形式保存一个组织的 GTM 上下文，并以 git 作为记忆。此技能负责工作区根目录、ORG.md、members/ 和工作区健康状况，并在 references/ 中托管共享标准。ICP、角色画像、适配度检查和 workflows/ 属于其他 gtm 技能；Doctor 永远不会检查 workflows/ 的内部内容。
工作流托管和提供商连接属于 gtm-workflow。对于独立的 Local 或 Vercel 设置，请转到其共享的 scripts/setup.mjs；无需 GTM Agent 或 Slack。工作区 Doctor 会将连接健康状况委托给该技能的 Doctor。
输入
请求；按照契约中的发现顺序找到的工作区；来自用户、公司自有公开网站及其他安全公开来源的事实，不得杜撰；来自用户或来源的成员邮箱，不得推断。
角色
用户通过宿主的写入权限批准每项更改；Agent 提出更改、编辑、提交并报告。
流程
对话中使用的第一个 gtm 技能会按照更新说明检查一次是否有较新版本。按照交互中的六条规则沟通；复现对话。
| 任务 | 操作 |
|---|---|
| 创建 | 当 ~/.gtm/ 已有一个带远程地址的空克隆（为空，或仅包含共享 gtm-workflow 设置在工作区上线时发布的 workflows/、.gitignore 和 .github/）时，将脚手架内容填入其中，以其目录名作为 slug，不询问其所在位置，并在提交后运行 git push -u origin main；如果克隆既非空也不是工作区（例如包含 GitHub 初始化的 README），则用业务术语说明问题，绝不覆盖后搭建。否则询问其所在位置：仅在这台计算机上（推荐），或同时存放在名为 gtm-<slug> 的私有 GitHub 仓库中，并在 main 上运行 git init。将 templates/AGENTS.md、CLAUDE.md、ORG.md 和 gitignore（作为 .gitignore）复制到 ~/.gtm/<slug>/，根据用户和公开来源填写 ORG.md，提交；如果要共享，则运行 gh repo create gtm-<slug> --private --source . --push；首次推送到空仓库时运行 git push -u origin main。导入属于创建：将现有工作区复制或克隆到 ~/.gtm/<slug>/，而不是搭建脚手架。 |
| 更新 | 更改 ORG.md 中的事实，或根据模板添加、更改或删除 members/<slug>/MEMBER.md；邮箱为必填项。 |
| Doctor | 将根目录结构和每个文件与 templates/ 及契约进行比较；用业务术语报告偏差；将修复方案作为选项提供；按用户接受的方案重写，包括旧版布局（根目录中的 README、suborgs/、缺失或顺序错误的字段）；.github/ 由 gtm-workflow 的 Doctor 负责。工作区 slug 是目录名，绝不从 H1 推导。 |
每次保存：用一句话说明将进行哪些更改；若存在 origin/main，先拉取；通过宿主的写入路径编辑；在 main 上以通俗易懂的说明提交；存在远程地址时推送；验证提交（若存在远程地址，还要验证提交已到达 origin/main）；最后说明创建、更改或删除了什么。
输出
具有契约中根目录结构的工作区；每项更改都是 main 上的提交；共享时，使用私有 GitHub 仓库 gtm-<slug>。
例外
如果匹配到多个工作区且未指定其中任何一个，则询问用户，绝不保存偏好设置。无法确认的事实写为 Unknown。没有邮箱的成员不会创建。若用户要求删除整个工作区，Agent 绝不执行；应说明用户需要自行移除文件夹，若已共享，还需移除 GitHub 仓库。旧版 suborgs/ 单位将作为正文放入 ORG.md 的 ## Notes 下；如果用户希望拥有独立的 GTM 上下文，则为其创建单独的工作区。
QC
ORG.md按顺序包含 company data 中的 13 个字段，每个字段占一行；仅在 Location、Products and services 和 Tech stack 下使用嵌套项目符号。- 根目录仅包含the contract列出的内容；指针文件和
.gitignore与其模板逐字节匹配。 - 每个 slug 都遵循合约规则；每位成员都有电子邮件地址。
- 关于变更内容的结尾说明应与已验证的提交相符。
References
interaction 规则；interactions 对话；contract 中关于 slug、发现、根目录结构、来源和共享的说明；company data 和 person data 词汇表；templates/ 中的 AGENTS.md、CLAUDE.md、ORG.md、gitignore 和 MEMBER.md 模板。