educates-workshop-authoring

Educates 工作坊编写技能

此技能为 Educates 培训平台的交互式工作坊创建提供指导。

初始工作坊创建

当用户要求创建工作坊时，请按以下步骤操作：

1. 收集工作坊详情

从用户处收集以下信息，或根据上下文推断：

• 标题：简短、易读的工作坊标题
• 描述：用一到两句话说明工作坊涵盖的内容
• 名称：机器可读的标识符（小写，可使用连字符，最多 25 个字符，建议使用 lab- 前缀）

如果用户提供了主题，但未明确给出具体值，请提出合理的默认值，并在继续之前确认。

2. 确定工作坊位置

请用户从以下选项中选择一个：

• 使用当前目录作为工作坊根目录
• 使用工作坊名称创建新的子目录

根据目录推导工作坊名称：

如果用户选择使用当前工作目录：

1. 检查目录名称是否符合命名约定（小写，可使用连字符，最多 25 个字符）。注意：使用目录名称时，建议使用 lab- 前缀，但并非必需。
2. 如果符合要求，则将目录名称用作工作坊名称
3. 如果不符合要求，则根据工作坊主题或标题推断合适的名称，并在继续之前与用户确认（除非用户已经明确提供了名称）

3. 确定工作坊要求

终端应用始终默认启用。为明确起见，请始终显式包含 enabled: true 和 layout: split。

根据工作坊的技术要求，询问用户是否需要其他会话应用：

• 编辑器：用户是否需要在浏览器中编辑或查看文件？
• Kubernetes 访问权限：用户是否要运行 kubectl 命令或与 Kubernetes API 交互？
• Kubernetes 控制台：可视化集群视图是否能帮助用户？
• Docker：用户是否要构建或运行容器？
• 镜像仓库：用户是否要推送容器镜像？
• 虚拟集群：工作坊是否需要集群管理员操作？
• Git 服务：用户是否需要本地 Git 仓库（例如用于 CI/CD 流水线）？
• 幻灯片：工作坊是否会在说明之外附带演示文稿？

根据工作坊主题推断合理的默认设置。例如，Kubernetes 工作坊可能需要启用编辑器、Kubernetes 访问权限和控制台。

4. 创建工作坊结构

在选定的位置创建以下目录结构：

<workshop-root>/
├── README.md                    # Workshop title and description
├── exercises/
│   └── README.md                # Placeholder to ensure directory is preserved
├── resources/
│   └── workshop.yaml            # Educates Workshop definition
└── workshop/
    └── content/                 # Workshop instruction pages (Markdown)

exercises 目录

始终将 exercises/ 目录作为初始工作坊结构的一部分创建。此目录是工作坊用户的工作区——将他们在工作坊期间需要的所有文件放在这里，例如源代码、配置文件、示例数据、YAML 清单、模板或起始项目。将所有面向用户的文件放在 exercises/ 下，可使工作坊环境保持整洁，避免主目录杂乱无章。

当导入工作坊会话容器的工作坊文件中存在此目录时，Educates 会对其进行特殊处理：

• 终端工作目录：工作坊仪表板中的嵌入式终端会将 ~/exercises 设为当前工作目录，而不是主目录。
• 编辑器根目录：VS Code 编辑器会打开 ~/exercises，而不是主目录，因此用户只会看到与工作坊相关的文件，不会被隐藏的点文件或主目录中的其他内容分散注意力。

只有在工作坊会话启动时 exercises/ 目录已经存在，才会触发此特殊行为。不能通过工作坊说明在之后创建该目录——它必须包含在已发布的工作坊文件中。

重要：该目录至少必须包含一个文件。 将工作坊文件发布到 Git 仓库或 OCI 镜像制品时，空目录不会被保留。为确保该目录包含在内，请添加一个 README.md，其中简要说明“本工作坊的练习文件”或类似占位内容。除非工作坊源代码由 Git 仓库管理且适合使用此约定，否则请避免使用 .gitkeep 文件。

由于始终建议使用 exercises/ 目录，工作坊说明不应需要创建该目录。此目录下文件在可点击操作中使用的路径必须带有 ~/exercises 前缀（例如，~/exercises/deployment.yaml）。可点击操作中的示例引用文件时已遵循此约定。

5. 生成 workshop.yaml

完整的 workshop.yaml 结构和选项请参阅 references/workshop-yaml-reference.md。

根据收集到的详细信息生成 resources/workshop.yaml 文件。

关键：使用正确的 publish 和 workshop.files 格式。

workshop.yaml 必须包含以下结构完全一致的部分（将实际工作坊名称填入相应位置）：

spec:
  publish:
    image: "$(image_repository)/{workshop-name}-files:$(workshop_version)"
    files:
    - directory:
        path: .
      includePaths:
      - /workshop/**
      - /exercises/**
      - /README.md
  workshop:
    files:
    - image:
        url: "$(image_repository)/{workshop-name}-files:$(workshop_version)"

**重要：**不要使用 spec.content.files——这是已弃用的格式。始终使用上面所示的 spec.publish 和 spec.workshop.files。必须按原样使用 $(image_repository) 和 $(workshop_version) 变量，以支持本地工作坊发布和部署工作流。spec.publish.files 部分控制哪些文件会打包到已发布的 OCI 镜像中——仅包含列出的路径，以缩小镜像体积。spec.workshop.files 部分指定运行时从何处获取文件；由于已发布的镜像已进行筛选，因此这里不需要 includePaths。spec.workshop.files 数组还支持 Git 和 HTTP 源，并且可以包含多个按顺序叠加的条目——详情请参阅 workshop YAML 参考中的“Alternative File Sources”部分。

其他配置：

• 将 metadata.name 设置为工作坊名称
• 根据收集到的详细信息设置 spec.title 和 spec.description
• 将 spec.duration 设置为预估完成时间（例如 15m、30m、1h）
• 将 spec.difficulty 设置为以下值之一：beginner、intermediate、advanced、extreme
• 始终启用终端，设置 enabled: true 和 layout: split
• 仅启用工作坊所需的其他会话应用程序
• 默认将 spec.session.namespaces.security.token.enabled 设置为 false（由于历史原因，该项默认处于启用状态）
• 仅当工作坊需要 kubectl 或使用 Kubernetes 控制台时，才将 spec.session.namespaces.security.token.enabled 设置为 true
• 省略不需要的应用程序（不要设置 enabled: false）

6. 添加用于发布的 GitHub Actions 工作流（仅在用户要求时）

**初始创建工作坊期间请跳过此步骤，除非用户明确要求使用 GitHub action 将工作坊发布到 GitHub 容器注册表。**如果用户在工作坊创建完成后返回现有工作坊，并要求添加发布支持，此步骤同样适用。

此步骤仅适用于位于独立 Git 仓库中的工作坊。如果工作坊属于包含多个工作坊的课程，请勿使用此 GitHub action——课程的发布方式有所不同。

收到请求后，在工作坊仓库中创建 .github/workflows/publish-workshop.yaml 文件。完整的工作流配置、action 参数，以及发布与 workshop.yaml 中 spec.publish 部分的关联方式，请参阅 references/workshop-publishing-reference.md。

7. 添加本地 Docker 兼容性（仅在需要时）

除非用户明确要求工作坊既能在 Kubernetes 上运行，也能在本地 Docker 上运行，否则请跳过此步骤。 如果用户之后回到现有工作坊，并要求追溯添加本地 Docker 支持，也需要执行此步骤。

并非所有工作坊都兼容本地 Docker 部署。需要访问 Kubernetes、使用虚拟集群或会话镜像仓库的工作坊，以及在工作坊定义中使用 environment.objects、session.objects 或 request.objects 的工作坊，均无法在本地 Docker 上运行。

如果用户要求为兼容的工作坊添加本地 Docker 支持，主要改动是在工作坊定义和工作坊说明中的所有会话代理 URL 后追加 ingress_port_suffix 数据变量。使用标准端口（Kubernetes）时，此变量为空字符串；使用非标准端口（本地 Docker）时，此变量包含端口号，因此添加该变量不会影响 Kubernetes 部署。

完整的限制列表、端口后缀的适用位置，以及如何为现有工作坊追溯添加本地 Docker 支持，请参阅 references/local-docker-deployment-reference.md。

8. 创建 AI 助手说明文件

如果满足以下任一条件，请跳过此步骤：

• 工作坊根目录中已存在 AI 助手说明文件（例如 CLAUDE.md、AGENTS.md）
• 父目录中已存在 AI 助手说明文件（这表明该工作坊属于更大的项目，例如使用 educates-course-design skill 创建的课程）

在项目根目录中创建 AI 助手说明文件，让后续 AI 交互能够自动了解项目背景以及应使用哪些 skills。对于 Claude Code，该文件为 CLAUDE.md；其他 AI 编码 Agent 使用不同的约定（例如 AGENTS.md）。

说明文件应包含：

• 指向 README.md 的链接，以查看项目概览和说明
• Skill 引用——说明何时调用各个 skill：
  • 创建或修改工作坊定义、说明页面和练习文件时，使用 educates-workshop-authoring skill
  • 如果之后将此工作坊纳入多工作坊课程，则在课程规划时使用 educates-course-design skill

请确保此文件仅包含 AI 专用说明和项目专属覆盖规则。不要重复 README.md 中已有的内容，而应引用该文件。

9. 编写工作坊说明

工作坊说明以 Markdown 文件的形式放置在 workshop/content/ 目录中，并由 Hugo 渲染。

通过可点击操作引导学习

默认情况下，工作坊说明应提供引导式体验，所有代码交互——查看、运行和修改——都通过可点击操作完成。不要要求学习者在终端中输入命令，或手动在编辑器中编写代码。相反，每次交互都应使用相应的可点击操作（terminal:execute、editor:open-file、editor:replace-matching-text 等）。这样可以让学习者专注于概念，而不是操作过程。如果请求工作坊的人明确要求采用不同的体验，则相应调整。

完整的设计理念（包括学习者应如何查看、运行和修改代码，以及如何将 exercises/ 目录构建为预先填充内容的工作区），请参阅 references/workshop-design-principles.md。

指令中的可点击操作

工作坊指令使用可点击操作——一种特殊的围栏代码块，用户可通过点击执行命令、编辑文件并与工作坊环境交互。有关操作类型的完整列表和详细语法，请参阅 references/clickable-actions-reference.md。

**终端命令的关键 YAML 安全规则：**生成 terminal:execute 可点击操作时，如果命令包含 YAML 中具有特殊含义的字符（冒号、井号、花括号、方括号等），或命令跨越多行，请始终使用 YAML 块标量语法（command: |-）。这样可以防止 YAML 解析器误解命令。例如：

```terminal:execute
command: |-
  docker run --rm -p 8080:80 nginx:latest
```

还要确保 Shell 命令使用正确的引号——包含空格路径的变量展开应使用双引号，含有特殊字符的字符串应正确转义，等等。详细指导和示例请参阅可点击操作参考中的“YAML Syntax Safety”部分。

**包含缩进文本的编辑器操作的关键 YAML 安全规则：**生成编辑器可点击操作（editor:select-matching-text、editor:replace-matching-text 等）时，如果 match、replacement 或 text 的内容以空格开头——也就是说，每一行都有缩进——必须使用 YAML 块标量缩进指示符（例如 |2、|4）来保留空白。否则，YAML 解析器会去掉开头的空格，导致匹配失败或替换内容的缩进不正确。例如：

```editor:replace-matching-text
file: ~/exercises/deployment.yaml
match: |2
      containers:
      - name: app
        image: myapp:v1
replacement: |2
      containers:
      - name: app
        image: myapp:v2
```

另一种无需缩进指示符的方法是：扩展匹配范围，使其包含从第 1 列开始的上下文。例如，不要只匹配缩进的函数体，而是将函数定义行（例如 def my_function():）也包含在内，这样块标量的首行就没有前导空格，使用普通的 | 即可。这对顶层函数很有效，但对类方法或其他本身带有缩进的结构可能无济于事。有关缩进指示符的完整详情，请参阅编辑器文件操作参考。

**文本属性中尾随空行的关键 YAML 安全规则：**当编辑器可点击操作的 text 或 replacement 属性以一个或多个空行结尾时，这些空行可能在两个阶段丢失：YAML 默认的“clip”裁剪方式会去掉块标量值末尾的换行符，而 Hugo 的 Markdown 处理器会去掉代码围栏末尾的空行。要保留尾随空行，必须同时执行以下两项操作：在块标量上使用 + 保留裁剪指示符（使用 |+ 而非 |），并将 eot: true 设为 YAML 中的最后一个属性。例如：

```editor:insert-lines-before-selection
file: ~/exercises/app.py
text: |+
  # --- Section boundary ---

eot: true
```

|+ 会告知 YAML 保留尾随换行符，而 eot: true 属性（对可点击操作没有实际作用）可确保这些空行不属于代码围栏中的尾随内容，从而避免被 Hugo 去掉。详细指导请参阅可点击操作参考中的“Trailing blank lines in text properties”部分。

跟踪终端工作目录

当 exercises/ 目录存在时，每个终端会话的当前工作目录都是 ~/exercises，而非主目录。编写工作坊说明时，必须在说明的每个步骤中跟踪每个终端的当前工作目录。在 terminal:execute 操作中，任何 cd 命令都会更改该终端后续所有命令的工作目录。

如果弄错，就会导致命令引用错误的文件路径。可以：

• 跟踪工作目录并使用正确的相对路径。 例如，如果终端位于 ~/exercises，且需要访问 ~/exercises/deployment.yaml，则使用 deployment.yaml。如果前一步运行了 cd ~/exercises/myapp，那么 deployment.yaml 应写为 ../deployment.yaml，或者使用完整路径。
• 使用绝对路径以避免歧义。 例如，无论当前目录是什么，始终使用 ~/exercises/deployment.yaml。

当工作坊使用分屏终端布局（两个终端）时，请分别跟踪每个终端的工作目录；在一个终端中执行 cd 不会影响另一个终端。

仪表板标签页的可见性

工作坊仪表板在屏幕右侧一次只显示一个标签页（左侧显示工作坊说明）。会话启动时，默认显示 Terminal 标签页。用户可以点击标签页标题或使用 dashboard:open-dashboard 可点击操作来切换标签页。

编写说明时需要注意这一点，因为某些操作会隐式更改当前显示的标签页。terminal:execute 操作会切换到 Terminal 标签页，并隐藏用户正在查看的其他标签页（例如 Web 应用仪表板）。如果工作坊使用自定义仪表板标签页（例如用于显示通过会话代理访问的 Web 应用），则在运行终端命令后，必须明确引导用户切回该标签页，以便查看结果。

仪表板标签页是没有 URL 栏的 iframe，用户无法查看或更改标签页指向的 URL。由于内容嵌入在 iframe 中，浏览器中的任何位置也都不会显示嵌入式 Web 应用的页面标题；浏览器标签页或窗口的标题由最顶层的父页面决定，而非 iframe 内容。要更改仪表板标签页显示的内容，请使用带有新 url 的 dashboard:reload-dashboard。如果只需显示某个标签页而不重新加载其内容，请使用 dashboard:open-dashboard（不要使用不带 URL 的 dashboard:reload-dashboard）。如果工作坊会在说明中更改标签页的 URL，建议使用 dashboard:create-dashboard 动态创建标签页，而不是在 spec.session.dashboards 中预先定义，这样初始 URL 就能在上下文中显示。

有关在工作坊说明中处理标签页切换的详细模式和示例，请参阅 references/workshop-dashboard-reference.md。

说明中的数据变量

工作坊说明应使用数据变量进行参数化，而不是将特定于会话的值硬编码。Educates 提供会话命名空间、入口域、会话主机名以及许多其他上下文相关值的数据变量。使用 Hugo param shortcode 插入这些变量：

Deploy the application to the `{{< param session_namespace >}}` namespace.

数据变量也可用于可点击操作：

```terminal:execute
command: kubectl get pods -n {{< param session_namespace >}}
```

在可点击操作中的终端命令里，也可以使用对应的大写环境变量（例如 $SESSION_NAMESPACE），因为终端 shell 会自动设置这些变量。有关可用数据变量的完整列表，以及它们可用于哪些上下文，请参阅 references/data-variables-reference.md。

页面结构

每个页面都需要包含 YAML frontmatter，且至少有一个 title 属性：

---
title: Page Title
---

This is the introductory paragraph for the page. It appears immediately
after the frontmatter with no heading.

## First Section

Content for the first section...

## Second Section

Content for the second section...

内容指南：

• 使用标准 Markdown 编写页面内容
• 不要使用一级标题（#）——frontmatter 中的 title 会自动生成页面标题
• 在 frontmatter 后立即开始撰写介绍段落
• 其他部分使用二级标题（##）及以下级别的标题
• 使用提示框 shortcode 突出重要信息：使用 {{< note >}} 提示技巧，使用 {{< warning >}} 提醒注意事项，使用 {{< danger >}} 警示严重风险。语法和用法说明请参见 references/hugo-shortcodes-reference.md。
• 聚焦于工作坊主题，而非平台。 工作坊说明应教授主题内容，而不是讲解 Educates 的工作方式。当工作坊需要特定于平台的配置（例如，设置会话代理以访问已部署的服务、配置入口或使用数据变量）时，应将这些内容作为练习中的自然步骤呈现，不要特别强调 Educates 的内部机制。除非工作坊专门介绍 Educates 平台本身，否则不要说“我们将了解 Educates 的配置方式”或“这是 Educates 处理入口的方式”等内容。概述、总结和学习目标应描述用户将从主题中学到什么，而不是支撑工作坊的基础设施。

文件命名约定

使用数字前缀为页面排序：nn-page-name.md

建议的结构：

• 00-workshop-overview.md - 介绍和目标
• 01-first-topic.md - 第一个教学页面
• 02-second-topic.md - 继续递增，编写核心内容
• 99-workshop-summary.md - 总结和后续步骤

将 00- 保留给概述，将 99- 保留给总结。核心教学页面从 01- 开始，并依次递增。

页面包

对于简单页面，使用单个 .md 文件。对于包含本地嵌入图片的页面，改用页面包：

workshop/content/
├── 00-workshop-overview.md
├── 01-first-topic/
│   ├── index.md
│   └── diagram.png
├── 02-second-topic.md
└── 99-workshop-summary.md

页面包是一个包含 index.md 及相关资源（图片等）的目录。有关在工作坊页面中添加图片的详细指南，请参见 references/images-in-workshop-pages.md。

10. 验证工作坊定义

生成 resources/workshop.yaml 后，请验证以下关键项：

必需部分均已存在：

• 存在 spec.publish 部分，其中包含 image 和 files 字段
• spec.publish.files 使用 includePaths，仅选择 /workshop/**、/exercises/** 和 /README.md
• 存在包含 files 数组的 spec.workshop 部分
• spec.publish.image 和 spec.workshop.files 均使用 $(image_repository) 和 $(workshop_version) 变量

未使用已弃用的格式：

• 不存在 spec.content.files（请改用 spec.workshop.files）

应用设置：

• 终端包含 enabled: true 和 layout: split
• 仅包含必需的应用（完全省略已禁用的应用）
• 除非需要访问 Kubernetes，否则明确将 spec.session.namespaces.security.token.enabled 设置为 false

11. 验证 Workshop 说明

生成 Workshop 说明页面后，请验证以下内容：

Terminal 工作目录正确性：

• 已知每个终端的初始工作目录（存在 exercises 目录时为 ~/exercises，否则为 ~）
• 已跟踪 terminal:execute 操作中的每条 cd 命令，并确认每个步骤之后的工作目录
• 终端命令中的所有相对文件路径都与说明中相应位置的工作目录一致
• 使用分屏终端时，已分别跟踪每个终端的工作目录

文件路径一致性：

• editor 可点击操作中的文件路径在适当情况下使用 ~/exercises 前缀
• 正文中引用的文件路径与可点击操作中使用的路径一致

Dashboard 标签页可见性：

• 在用户查看非终端 dashboard 标签页（例如 Web 应用）之后执行任何 terminal:execute 操作时，说明会引导用户返回正确的标签页：无需刷新内容时使用 dashboard:open-dashboard，需要重新加载内容或更改 URL 时使用 dashboard:reload-dashboard
• 说明中始终跟踪当前显示的 dashboard 标签页，就像跟踪终端工作目录一样
• 不会仅为显示标签页而使用不带 url 的 dashboard:reload-dashboard；这种情况下应使用 dashboard:open-dashboard
• Workshop 期间使用 dashboard:reload-dashboard 更改 dashboard 标签页的 URL 时，说明中会使用 dashboard:create-dashboard 创建初始 dashboard（而非在 spec.session.dashboards 中预先定义），以便读者能看到初始 URL

编辑器操作中的 YAML 语法：

• 对于 match、replacement 或 text 内容以空格开头的每个 editor:select-matching-text、editor:replace-matching-text 或类似操作，都使用 YAML 块标量缩进指示符（|2、|4 等）；或者将匹配内容扩展为包含从第 1 列开始的上下文，以便使用普通的 |
• 对于 text 或 replacement 属性以空白行结尾的每个编辑器可点击操作，都使用 |+ 保留空白行，并将 eot: true 设为最后一个 YAML 属性，以防止 YAML 和 Hugo 删除这些空白行

引导式说明：

• 所有代码查看操作都使用编辑器可点击操作（editor:open-file、editor:select-matching-text），而不是普通代码块或 cat 之类的终端命令
• 所有命令执行都使用 terminal:execute 可点击操作；不会要求学习者手动输入命令
• 所有代码修改都使用编辑器可点击操作（editor:replace-matching-text、editor:append-lines-after-match、editor:insert-lines-before-match 等）；不会要求学习者手动编辑文件
• 仅当内容必须针对每位学习者进行自定义且无法通过数据变量处理时，才使用 workshop:copy 或 workshop:copy-and-edit

内容重点：

• Workshop 概述和摘要介绍主题内容，而非 Educates 平台
• 学习目标聚焦于用户将学到的主题知识
• 平台相关步骤（代理、入口、数据变量）作为练习的自然组成部分呈现，不会特别强调 Educates 的内部机制

12. 更新规划文档（仅限课程工作坊）

如果工作坊属于设有规划文档的课程（即存在包含工作坊计划的 planning/ 目录），请检查实施过程中所做的重大变更是否需要同步到规划文档中。目标是确保工作坊计划准确无误，让后续工作坊的规划能够基于正确信息展开。

需要更新的内容：

• 页面变更：如果更改了某个页面的主题或标题，请重命名页面文件，使其与新内容相符，并相应更新工作坊计划中的页面列表。
• 方案变更：如果更改了整体方案——例如换用其他技术、简化或重构练习，或选择了其他库或工具——请更新工作坊计划，描述实际构建的内容，而不是原先计划的内容。
• 文件重命名：如果重命名了页面文件，请检查其他工作坊页面或规划文档是否仍引用旧文件名。
• 对后续工作坊的影响：对于连续安排的工作坊，请检查下一场工作坊的计划或实现是否引用了变更内容——其“与上一场工作坊的衔接”部分、练习或叙事线索可能仍基于原先的方案。

请使用 educates-course-design skill 进行这些更新——它负责规划文档的格式，并确保变更遵循正确的结构。重要的是，最终的工作坊计划应反映实际构建的设计，而非最初的草案。

参考指南

如需了解特定主题的详细指导，请参阅：

• Workshop 设计原则 - 引导式体验理念、禁止手动输入的规则，以及关于学员应如何查看、运行和修改代码的指导
• Workshop YAML 参考 - 完整的 workshop.yaml 结构和选项
• Workshop 页面中的图片 - 如何使用页面包和静态资源添加图片
• 可点击操作参考 - 所有可点击操作类型的索引、YAML 语法安全指南，以及指向 references/clickable-actions/ 中各类别参考文档的链接
• Workshop 工具参考 - Workshop 环境中可用的命令行工具，包括用于 JSON/YAML 处理、Kubernetes 管理、容器处理和负载测试的实用工具
• Kubernetes 访问参考 - Namespace 隔离、会话 Namespace 参考，以及适用于可访问 Kubernetes 的 Workshop 的 Pod 安全策略
• 数据变量参考 - 用于参数化 Workshop 说明、终端命令和 Workshop 定义的完整数据变量列表
• Workshop 仪表板参考 - 仪表板布局、单标签页可见性行为，以及在 Workshop 说明中引导用户切换标签页的模式
• Workshop 镜像参考 - Workshop 的容器镜像选择，包括预构建的 JDK 和 Conda 镜像
• Java 语言参考 - JDK 镜像选择、Maven/Gradle 构建命令、项目布局，以及适用于 Java Workshop 的 Spring Boot 模式
• Python 语言参考 - Python 版本管理、uv/pip 软件包安装、项目布局，以及适用于 Python Workshop 的 Web 框架模式
• Workshop 设置参考 - Workshop 容器的设置脚本、环境变量、后台服务和终端自定义
• Hugo Shortcode 参考 - 提示框（注释、警告、危险）、路径条件渲染，以及用于 Workshop 说明的自定义 shortcode
• 会话对象参考 - 为每个会话预先创建 Kubernetes 资源、共享环境对象、请求对象，以及 Workshop 容器资源配置
• Workshop 发布参考 - 如何添加 GitHub Actions 工作流，通过 Educates publish-workshop GitHub Action 将独立 Workshop 发布到 GitHub 容器注册表。当用户要求设置 Workshop 发布时，请参阅此文档，无论是在初次创建时，还是之后将其添加到现有 Workshop 时。
• 本地 Docker 部署参考 - 既需要在本地 Docker 上运行，也需要在 Kubernetes 上运行的 Workshop 所受的限制和所需的更改。当用户要求兼容本地 Docker 时，请参阅此文档，无论是在初次创建时，还是之后为现有 Workshop 添加兼容支持时。
• 本地集群部署参考 - 如何在使用 educates create-cluster 创建的本地 Educates 集群上发布、部署、更新和删除 Workshop。当用户要求在本地集群上发布或部署 Workshop 时，请参阅此文档。不要自动运行这些命令——仅在用户明确要求管理本地集群中的 Workshop 时运行。

技能版本

当用户询问技能版本时，请读取 VERSION.txt 文件并向用户报告其内容。

获取帮助

如需了解更多信息，请访问 Educates 文档：https://docs.educates.dev/