block-kit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Block Kit

Help the developer build a rich Block Kit layout. If

$0

is provided, it specifies the target surface (

message

modal

, or

home-tab

This skill walks through surface selection, layout planning, JSON generation, and validation. Block types, elements, and fields come from the live docs (see Source of Truth below) — discover them and read each component's schema there, never from memory.

Common Block Kit mistakes (and why): A few errors recur often enough to flag up front. Most others are caught by
blocks.validate
in Step 5, so lean on validation rather than memorizing rules.
"type": "text"
is not a thing. Text is a composition object:
{ "type": "plain_text", "text": "..." }
or
{ "type": "mrkdwn", "text": "..." }
.
markdown
is a block type, not a text type. A
markdown
block holds standard markdown; text objects inside other blocks use
mrkdwn
(see mrkdwn vs. the
markdown
block in Step 4). Slack's
mrkdwn
is
*bold*
/
_italic_
/
~strike~
, not
**bold**
.
Messages need a top-level
text
fallback.
blocks.validate
won't flag a missing one, but notifications and screen readers display it instead of the blocks — so summarize what the layout conveys rather than leaving it empty.

帮助开发者构建丰富的Block Kit布局。若提供

$0

，则指定目标载体（

message

、

modal

或

home-tab

）。

此技能会引导完成载体选择、布局规划、JSON生成和验证流程。块类型、元素和字段均来自官方实时文档（见下方权威来源）——请从文档中查找并查看每个组件的 schema，切勿凭记忆操作。

常见Block Kit错误（及原因）： 有一些错误出现频率很高，特此提前提醒。大多数其他错误会在步骤5中被
blocks.validate
检测到，因此请依赖验证而非记忆规则。
"type": "text"
不存在。文本是一种组合对象：
{ "type": "plain_text", "text": "..." }
或
{ "type": "mrkdwn", "text": "..." }
。
markdown
是块类型，而非文本类型。
markdown
块用于承载标准markdown；其他块内的文本对象使用
mrkdwn
（见步骤4中的mrkdwn 与
markdown
块的区别）。Slack的
mrkdwn
语法为
*bold*
/
_italic_
/
~strike~
，而非
**bold**
。
消息需要顶层
text
备用文本。
blocks.validate
不会标记缺失的备用文本，但通知和屏幕阅读器会显示它而非块内容——因此请概述布局传达的信息，不要留空。

Source of Truth: the Live Docs

权威来源：官方实时文档

Every block, element, and composition object is documented on

docs.slack.dev

. Append

.md

to any reference URL to fetch it as markdown with WebFetch (no auth required).

Master index: the authoritative list of every block, block element, and composition object, each linking to its own page:
```
https://docs.slack.dev/reference/block-kit.md
```
. WebFetch it to confirm a type exists and to get the link to its page.

Per-component pages carry the full field schema (a fields table with required/optional flags and constraints, plus JSON examples):

Blocks:

https://docs.slack.dev/reference/block-kit/blocks/<slug>-block.md

Block elements:

https://docs.slack.dev/reference/block-kit/block-elements/<slug>-element.md

Composition objects:

https://docs.slack.dev/reference/block-kit/composition-objects/<slug>.md

The slug is not always the type name. For example
```
datepicker
```
maps to
```
date-picker-element.md
```
, and every
```
*_select
```
menu (
```
static_select
```
,
```
users_select
```
,
```
multi_channels_select
```
, and so on) is documented on
```
select-menu-element.md
```
. When unsure of a slug, follow the link from the master index rather than building the URL by hand.

Surface payload structure lives in the surface guides: messages at

https://docs.slack.dev/messaging/formatting-message-text.md

, modals at

https://docs.slack.dev/surfaces/modals.md

, and Home tabs at

https://docs.slack.dev/surfaces/app-home.md

Never use a block type, element, or field you have not seen on a live page.

每个块、元素和组合对象均记录在

docs.slack.dev

上。在任何参考URL后添加

.md

，即可通过WebFetch获取其markdown格式内容（无需授权）。

主索引：包含所有块、块元素和组合对象的权威列表，每个条目均链接至其专属页面：
```
https://docs.slack.dev/reference/block-kit.md
```
。通过WebFetch获取该页面，确认类型是否存在并获取其页面链接。

组件专属页面：包含完整的字段schema（带有必填/可选标记和约束的字段表，以及JSON示例）：

块：

https://docs.slack.dev/reference/block-kit/blocks/<slug>-block.md

块元素：

https://docs.slack.dev/reference/block-kit/block-elements/<slug>-element.md

组合对象：

https://docs.slack.dev/reference/block-kit/composition-objects/<slug>.md

slug并非总是类型名称。例如
```
datepicker
```
对应
```
date-picker-element.md
```
，所有
```
*_select
```
菜单（
```
static_select
```
、
```
users_select
```
、
```
multi_channels_select
```
等）均记录在
```
select-menu-element.md
```
上。若不确定slug，请从主索引中点击链接，而非手动构建URL。

载体负载结构：记录在载体指南中：消息见

https://docs.slack.dev/messaging/formatting-message-text.md

，模态框见

https://docs.slack.dev/surfaces/modals.md

，主页标签见

https://docs.slack.dev/surfaces/app-home.md

。

切勿使用未在实时页面中见过的块类型、元素或字段。

Fast Path (for clear, specific requests)

快速路径（适用于明确、具体的需求）

If the developer's request is specific enough to determine both the target surface and the desired layout, collapse Steps 1-4 into a single pass:

Determine the surface from
```
$0
```
or context
Fetch only the doc pages for the blocks and elements mentioned
Generate the JSON directly
Proceed to Step 5 (validation)

Fast-path indicators (skip the full workflow):

Developer provides existing JSON to modify → use Modification Mode instead
Developer names specific block types: "add an actions block with two buttons"
Developer describes a well-known pattern: "approval message", "feedback form", "settings modal"
Developer provides a complete description in one message with enough detail to build

Full-workflow indicators (use Steps 1-7):

Vague requests: "make something cool", "build a dashboard"
Exploratory: "what can Block Kit do?", "show me my options"
Complex layouts: 10+ blocks, nested modals, conditional logic
Developer asks for help deciding what to build

若开发者的请求足够具体，可确定目标载体和所需布局，则可将步骤1-4合并为一步：

从
```
$0
```
或上下文确定载体
仅获取提及的块和元素的文档页面
直接生成JSON
进入步骤5（验证）

快速路径触发标识（跳过完整流程）：

开发者提供现有JSON用于修改→改用修改模式
开发者指定具体块类型："添加一个包含两个按钮的actions块"
开发者描述知名模式："审批消息"、"反馈表单"、"设置模态框"
开发者在一条消息中提供足够详细的完整描述，可直接构建

完整流程触发标识（使用步骤1-7）：

模糊请求："做些炫酷的东西"、"构建一个仪表盘"
探索性请求："Block Kit能做什么？"、"展示我的可选方案"
复杂布局：10个以上块、嵌套模态框、条件逻辑
开发者请求帮助决定构建内容

Modification Mode

修改模式

If the developer provides existing Block Kit JSON (pasted inline, in a file, or referenced from code), enter Modification Mode instead of the full creation workflow:

Parse the existing structure:
- List each block by index, type, and a short description of its content
- Infer the surface:
```
"type": "modal"
```
  = modal,
```
"type": "home"
```
  = home tab, bare
```
blocks
```
  array = message
Ask what changes they want:
- Add blocks (where in the sequence?)
- Remove blocks (which ones?)
- Modify blocks (which block, what change?)
- Reorder blocks
Apply changes while preserving:
- All existing
```
block_id
```
  values (these are referenced in app interaction handlers)
- All existing
```
action_id
```
  values (these map to event listeners)
- Existing styles, text content, and structure for unchanged blocks
Validate the modified JSON: proceed to Step 5 (validation)

Detection: If the developer's message contains a JSON array starting with

[{"type":

or a view object with

"blocks":

, enter Modification Mode automatically. If they say "edit", "update", "modify", or "change" in reference to existing blocks, ask them to provide the current JSON.

若开发者提供现有Block Kit JSON（内联粘贴、文件中或代码引用），则进入修改模式而非完整创建流程：

解析现有结构：
- 按索引、类型和内容简短描述列出每个块
- 推断载体：
```
"type": "modal"
```
  =模态框，
```
"type": "home"
```
  =主页标签，纯
```
blocks
```
  数组=消息
询问所需更改：
- 添加块（在序列中的哪个位置？）
- 删除块（哪些块？）
- 修改块（哪个块，做什么更改？）
- 重新排序块
应用更改时保留以下内容：
- 所有现有
```
block_id
```
  值（这些值在应用交互处理程序中被引用）
- 所有现有
```
action_id
```
  值（这些值映射到事件监听器）
- 未更改块的现有样式、文本内容和结构
验证修改后的JSON：进入步骤5（验证）

检测规则：若开发者的消息包含以

[{"type":

开头的JSON数组，或带有

"blocks":

的视图对象，则自动进入修改模式。若开发者提及"编辑"、"更新"、"修改"或"更改"现有块，请要求他们提供当前JSON。

Step 1: Determine the Target Surface

步骤1：确定目标载体

$0

is provided and matches one of

message

modal

, or

home-tab

, use it directly.

Otherwise, ask the developer using AskUserQuestion:

Message: Conversational content posted to a channel or DM. Max 50 blocks.
Modal: A dialog or form opened by a user action. Max 100 blocks.
Home tab: A persistent, per-user dashboard in the App Home. Max 100 blocks.

Once the surface is determined, use the correct payload structure for it:

Message: a
```
{ "text": "Fallback text", "blocks": [...] }
```
object posted via
```
chat.postMessage
```
(and friends). The
```
text
```
field is the notification/accessibility fallback. For message text formatting (mrkdwn, mentions, dates), see
```
https://docs.slack.dev/messaging/formatting-message-text.md
```
.
Modal: a view object (
```
{ "type": "modal", "title": ..., "blocks": [...] }
```
). For the full view object structure, lifecycle, and the rule that
```
submit
```
is required when the view contains any
```
input
```
block, see
```
https://docs.slack.dev/surfaces/modals.md
```
.

Home tab: a view object (

{ "type": "home", "blocks": [...] }

) published via

views.publish

. For structure and behavior, see

https://docs.slack.dev/surfaces/app-home.md

若提供

$0

且匹配

message

、

modal

或

home-tab

之一，则直接使用该值。

否则，使用AskUserQuestion询问开发者：

Message：发布到频道或私信的对话内容。最多50个块。
Modal：由用户操作触发打开的对话框或表单。最多100个块。
Home tab：App Home中持久化的用户专属仪表盘。最多100个块。

确定载体后，使用对应的负载结构：

Message：通过
```
chat.postMessage
```
（及相关方法）发布的
```
{ "text": "备用文本", "blocks": [...] }
```
对象。
```
text
```
字段是通知/无障碍备用文本。关于消息文本格式（mrkdwn、提及、日期），请查看
```
https://docs.slack.dev/messaging/formatting-message-text.md
```
。
Modal：视图对象（
```
{ "type": "modal", "title": ..., "blocks": [...] }
```
）。关于完整视图对象结构、生命周期，以及当视图包含任何
```
input
```
块时必须包含
```
submit
```
的规则，请查看
```
https://docs.slack.dev/surfaces/modals.md
```
。

Home tab：通过

views.publish

发布的视图对象（

{ "type": "home", "blocks": [...] }

）。关于结构和行为，请查看

https://docs.slack.dev/surfaces/app-home.md

。

Step 2: Understand What to Build

步骤2：明确构建需求

Ask the developer to describe what they want their layout to look like or accomplish.

If they need inspiration, suggest examples — several map directly onto a ready-made template in

references/common-patterns.md

(named in parentheses), which you can start from in Step 3:

"A feedback form with a text input and a category selector" (Simple Form Modal)
"A notification message with an alert banner, description, and Approve/Reject buttons" (Notification Alert / Approval Message)
"A dashboard home tab with a welcome header, key metrics in fields, and quick-action buttons" (Dashboard Home Tab)
"A settings modal with dropdowns, checkboxes, and a time picker" (Settings Modal with Multiple Input Types)
"A table of sprint tasks with status and points" (Data Table)

Get enough detail to plan the layout before generating any JSON.

请开发者描述他们希望布局呈现的样子或实现的功能。

若他们需要灵感，可提供示例——部分示例直接对应

references/common-patterns.md

中的现成模板（括号内为模板名称），可在步骤3中以此为起点：

"包含文本输入框和类别选择器的反馈表单"（简单表单模态框）
"带有警告横幅、描述和批准/拒绝按钮的通知消息"（通知警告/审批消息）
"包含欢迎标题、关键指标字段和快速操作按钮的仪表盘主页标签"（仪表盘主页标签）
"包含下拉菜单、复选框和时间选择器的设置模态框"（多输入类型设置模态框）
"包含状态和点数的 sprint 任务表格"（数据表格）

在生成任何JSON之前，获取足够的细节以规划布局。

Step 3: Plan the Block Layout

步骤3：规划块布局

Based on the developer's description:

Fetch only what you need from the live docs:
- WebFetch the master index (
```
https://docs.slack.dev/reference/block-kit.md
```
  ) to confirm the block and element types you plan to use exist and to grab links to their pages.
- Check
```
references/common-patterns.md
```
  (the one local reference file) if the request matches a common pattern; start from the template instead of building from scratch.
- Defer reading individual component pages until Step 4, when you build each block's fields.

Propose a numbered block outline. For example:

text

1. header: "Weekly Report"
2. section: Summary text with a datepicker accessory
3. divider
4. section: Status fields (Name, Role, Team)
5. actions: "Approve" button (primary) and "Reject" button (danger)

Present the outline to the developer and ask for approval or changes before generating JSON.

Surface constraints to check:

Block count limit: 50 for messages, 100 for modals/home tabs
Modal-specific: if using
```
input
```
blocks, the modal payload must include a
```
submit
```
field
Table: only one
```
table
```
block per message
Surface compatibility (whether a block is valid on the chosen surface) and element compatibility (whether an element is allowed inside a given block) are not always spelled out on a component's doc page. Build the layout from the docs, and let
```
blocks.validate
```
in Step 5 confirm it. It is the authoritative check.

根据开发者的描述：

仅从实时文档获取所需内容：
- 通过WebFetch获取主索引（
```
https://docs.slack.dev/reference/block-kit.md
```
  ），确认计划使用的块和元素类型是否存在，并获取其页面链接。
- 若请求匹配常见模式，可查看
```
references/common-patterns.md
```
  （本地参考文件）；以此模板为起点，而非从零开始构建。
- 延迟读取单个组件页面，直到步骤4构建每个块的字段时再进行。

提出编号的块大纲示例：

text

1. header: "每周报告"
2. section: 包含日期选择器附件的摘要文本
3. divider
4. section: 状态字段（姓名、角色、团队）
5. actions: "批准"按钮（primary）和"拒绝"按钮（danger）

将大纲呈现给开发者，在生成JSON前请求批准或修改。

需检查的载体约束：

块数量限制：消息最多50个，模态框/主页标签最多100个
模态框专属：若使用
```
input
```
块，模态框负载必须包含
```
submit
```
字段
表格：每条消息仅允许一个
```
table
```
块
载体兼容性（块是否适用于所选载体）和元素兼容性（元素是否允许在给定块内）并非总是在组件文档页面中明确说明。请根据文档构建布局，并通过步骤5中的
```
blocks.validate
```
确认。这是权威检查方式。

Step 4: Generate the Block Kit JSON

步骤4：生成Block Kit JSON

Once the layout is approved, build each block from its live doc page, fetching each page's fields table (required vs optional, constraints) and JSON example with WebFetch. The URL patterns are in Source of Truth above; the one slug to remember is that every

*_select

menu (

static_select

users_select

multi_channels_select

, …) lives on

select-menu-element.md

. Fetch pages as you need them and reuse what you have already fetched — don't re-fetch the same page for every block of the same type. Then build the payload block-by-block and wrap it in the surface structure from Step 1.

Guidelines:

Use descriptive
```
action_id
```
values (e.g.,
```
"approve_report_btn"
```
not
```
"action_1"
```
) — they identify the element in your interaction handlers
Include
```
block_id
```
values where the developer will need them for interaction handling
For modals, include
```
title
```
,
```
submit
```
,
```
close
```
, and
```
callback_id
```
; for home tabs, the
```
type: "home"
```
wrapper
Use
```
mrkdwn
```
text for rich formatting,
```
plain_text
```
where required (headers, labels, modal title)

mrkdwn vs. the
markdown
block:

section

and

context

blocks format text with Slack's

mrkdwn

(

*bold*

_italic_

~strike~

`code`

) — use these for short, interactive layouts. The separate

markdown

block (Messages only) renders standard markdown (

**bold**

, headings, tables, numbered lists) and is meant for AI/LLM-generated or long-form content that already exists in standard markdown. Reach for it when the developer has such content or needs those features in the message body; there is a cumulative 12,000-character limit across all

markdown

blocks in one message.

Accessibility is easy to skip and hard to retrofit, so build it in now:

Give images descriptive
```
alt_text
```
(what the image shows, not just "image"), and make sure image-heavy layouts also carry the key information as text
Summarize the layout in the message's
```
text
```
fallback (notifications and screen readers show it instead of the blocks)
Use
```
header
```
blocks for logical section headings — they convey document structure to assistive tech

Present the complete payload to the developer in the Step 1 surface structure.

布局获批后，从实时文档页面构建每个块，通过WebFetch获取每个页面的字段表（必填/可选、约束）和JSON示例。URL模式见上方权威来源；需记住的一个slug是：所有

*_select

菜单（

static_select

、

users_select

、

multi_channels_select

等）均在

select-menu-element.md

上。按需获取页面并重复使用已获取的内容——无需为同一类型的每个块重新获取页面。然后逐个构建负载块，并使用步骤1中的载体结构进行封装。

指南：

使用描述性
```
action_id
```
值（例如
```
"approve_report_btn"
```
而非
```
"action_1"
```
）——它们在交互处理程序中标识元素
在开发者需要进行交互处理的位置包含
```
block_id
```
值
对于模态框，包含
```
title
```
、
```
submit
```
、
```
close
```
和
```
callback_id
```
；对于主页标签，包含
```
type: "home"
```
封装
使用
```
mrkdwn
```
文本实现富格式，在需要的位置使用
```
plain_text
```
（标题、标签、模态框标题）

mrkdwn 与
markdown
块的区别：

section

和

context

块使用Slack的

mrkdwn

（

*bold*

、

_italic_

、

~strike~

、

`code`

）格式化文本——适用于短交互式布局。独立的

markdown

块（仅消息可用）渲染标准markdown（

**bold**

、标题、表格、编号列表），适用于AI/LLM生成或已存在的长格式内容。当开发者拥有此类内容或需要在消息正文中使用这些功能时再选择它；单条消息中所有

markdown

块的累计字符限制为12000个。

无障碍设计容易被忽略且难以后期补充，因此请从一开始就纳入：

为图片添加描述性
```
alt_text
```
（说明图片内容，而非仅写"image"），确保图片密集的布局也通过文本传达关键信息
在消息的
```
text
```
备用文本中概述布局内容（通知和屏幕阅读器会显示它而非块内容）
使用
```
header
```
块作为逻辑章节标题——它们向辅助技术传达文档结构

将完整负载以步骤1中的载体结构呈现给开发者。

Step 5: Validate

步骤5：验证

Always validate.

blocks.validate

is a public Web API method, so no auth token is required.

The authoritative reference for this method (its parameters, auth requirements, and response/error shape) is the live doc. WebFetch it before relying on any detail here:

https://docs.slack.dev/reference/methods/blocks.validate.md

. It documents the accepted parameters (

blocks

for a message's blocks array,

view

for a modal/home-tab view,

message

for a full message payload; send exactly one) and the response shape.

务必进行验证。

blocks.validate

是公共Web API方法，无需授权令牌。

此方法的权威参考（参数、授权要求、响应/错误格式）见实时文档。在依赖此处的任何细节之前，请通过WebFetch获取该文档：

https://docs.slack.dev/reference/methods/blocks.validate.md

。文档记录了接受的参数（

blocks

对应消息的块数组，

view

对应模态框/主页标签视图，

message

对应完整消息负载；仅需发送其中一个）和响应格式。

5a. Build the validation request

5a. 构建验证请求

Prefer the Slack CLI when it's available, since it reuses the slack-cli skill's CLI detection and needs no token wrangling. If the CLI isn't installed, fall back to curl. Both call the same public method and return the same response, so Step 5b applies either way.

Path A: Slack CLI (preferred).

Use the

slack:slack-cli

skill, Step 1: Detect the Slack CLI, to check whether the public CLI is installed and resolve its command (

SLACK_CMD

If the CLI is available, use the

slack:slack-cli

skill, Step 4: Calling Web API Methods (
slack api
), to invoke it. That step covers the

SLACK_CMD api <method> key=value …

syntax. Run

SLACK_CMD api --help

first to confirm the syntax and the flag that skips authentication.

blocks.validate

needs no token, so call it without authentication. Don't hard-code that flag from memory; read it from the help output so this stays correct if it's ever renamed. Pass the payload as a positional

key=value

argument:

blocks=<JSON array>

for messages, or

view=<JSON view object>

for modals and home tabs.

Path B: curl (fallback, when the CLI isn't installed).

POST to the endpoint with the Bash tool. The API uses form-urlencoded encoding, so pass the JSON directly as the parameter value.

For messages, send the

blocks

array as a form-encoded parameter:

bash

curl -s -X POST 'https://slack.com/api/blocks.validate' \
  -d 'blocks=[ ... the blocks array ... ]'

For modals and home tabs, send the complete view object in the

view

field:

bash

curl -s -X POST 'https://slack.com/api/blocks.validate' \
  -d 'view={ "type": "modal", "title": ..., "blocks": [...] }'

若Slack CLI可用，优先使用它，因为它可复用slack-cli技能的CLI检测功能，无需处理令牌。若未安装CLI，则回退到curl。两种方式调用的是同一个公共方法，返回相同响应，因此步骤5b均适用。

路径A：Slack CLI（优先）

使用

slack:slack-cli

技能的步骤1：检测Slack CLI，检查是否已安装公共CLI并解析其命令（

SLACK_CMD

）。

若CLI可用，使用

slack:slack-cli

技能的步骤4：调用Web API方法（
slack api
）来调用它。该步骤涵盖
SLACK_CMD api <method> key=value …
语法。先运行
SLACK_CMD api --help
确认语法以及跳过身份验证的标志。

blocks.validate

无需令牌，因此无需身份验证即可调用。请勿凭记忆硬编码该标志；请从帮助输出中读取，以便在标志重命名时保持正确性。将负载作为位置

key=value

参数传递：消息使用

blocks=<JSON array>

，模态框和主页标签使用

view=<JSON view object>

。

路径B：curl（回退，当CLI未安装时）

通过Bash工具向端点发送POST请求。API使用form-urlencoded编码，因此直接将JSON作为参数值传递。

对于消息，将

blocks

数组作为表单编码参数发送：

bash

curl -s -X POST 'https://slack.com/api/blocks.validate' \
  -d 'blocks=[ ... the blocks array ... ]'

对于模态框和主页标签，在

view

字段中发送完整视图对象：

bash

curl -s -X POST 'https://slack.com/api/blocks.validate' \
  -d 'view={ "type": "modal", "title": ..., "blocks": [...] }'

5b. Handle the response

5b. 处理响应

Success:

json

{ "ok": true }

Tell the developer their blocks are valid.

Failure:

json

{
  "ok": false,
  "error": "invalid_blocks",
  "errors": [
    {
      "code": "missing_field",
      "message": "missing required field: type",
      "field": "type",
      "pointer": "/0"
    }
  ]
}

When validation fails:

Read each error.
```
pointer
```
is a JSON pointer to the offending node (e.g.,
```
/0
```
= first block,
```
/2/elements/1
```
= second element of the third block,
```
/0/text/type
```
= the
```
type
```
field of the first block's text object).
```
message
```
describes the problem, and
```
constraint
```
(when present) names the rule that failed and its expected values.
Fix the JSON. For the authoritative meaning of an error code and the field requirements behind it, consult the live method doc (
```
https://docs.slack.dev/reference/methods/blocks.validate.md
```
) and the relevant block/element/composition-object page you fetched in Steps 3-4.
Re-validate. Repeat until
```
"ok": true
```
.

成功：

json

{ "ok": true }

告知开发者他们的块验证通过。

失败：

json

{
  "ok": false,
  "error": "invalid_blocks",
  "errors": [
    {
      "code": "missing_field",
      "message": "missing required field: type",
      "field": "type",
      "pointer": "/0"
    }
  ]
}

验证失败时：

读取每个错误。
```
pointer
```
是指向错误节点的JSON指针（例如
```
/0
```
=第一个块，
```
/2/elements/1
```
=第三个块的第二个元素，
```
/0/text/type
```
=第一个块的文本对象的
```
type
```
字段）。
```
message
```
描述问题，
```
constraint
```
（若存在）指明违反的规则及其预期值。
修复JSON。若需了解错误代码的权威含义及背后的字段要求，请查阅实时方法文档（
```
https://docs.slack.dev/reference/methods/blocks.validate.md
```
）以及步骤3-4中获取的相关块/元素/组合对象页面。
重新验证。重复此过程直到返回
```
"ok": true
```
。

Step 6: Deliver the Final Output

步骤6：交付最终输出

Present the validated payload, then help the developer put it to use.

呈现验证通过的负载，然后帮助开发者将其投入使用。

Send it

发送负载

Building the payload is this skill's job; sending it (

chat.postMessage

views.open

views.publish

, and the token/scope handling around them) belongs to the Web API layer. To call the right method — via the Slack CLI, raw curl, or a Bolt SDK — use the

slack:slack-api

skill, Step 4: Call the Method (Manage), passing this payload as the method's

blocks

argument (messages) or

view

argument (modals and home tabs). That skill matches the argument names to the SDK or HTTP call so we don't duplicate them here.

构建负载是此技能的职责；发送负载（

chat.postMessage

、

views.open

、

views.publish

及相关令牌/权限处理）属于Web API层。要调用正确的方法——通过Slack CLI、原始curl或Bolt SDK，请使用

slack:slack-api

技能的步骤4：调用方法（管理），将此负载作为方法的

blocks

参数（消息）或

view

参数（模态框和主页标签）传递。该技能会将参数名称匹配到SDK或HTTP调用，因此此处不再重复。

Preview it

预览布局

Help the developer view their layout with the Block Kit Builder. Prefer the Slack CLI if it is installed. The CLI automatically loads the blocks, saving the developer from copying and pasting. If the CLI is not available, provide the standard Builder link instead.

Path A: Slack CLI (preferred).

Use the

slack:slack-cli

skill, Step 1: Detect the Slack CLI, to check whether the public CLI is installed and resolve its command (

SLACK_CMD

If the CLI is available, run

SLACK_CMD blocks preview --help

to see how to pass the blocks and open the preview. The command loads the blocks into the Block Kit Builder in the developer's browser.

Because you run the CLI non-interactively, this command also needs a

--team

flag. Resolve the team ID with the

slack:slack-cli

skill, Step 2: Command Discovery via Help, whose "Resolving

--app

and

--team

values" guidance covers running

SLACK_CMD auth list

; Any authenticated workspace works for a preview, if several are available, pick one and mention which you used rather than blocking on the choice.

Path B: Block Kit Builder link (fallback, when the CLI isn't installed).

Offer the Block Kit Builder link so the developer can paste the JSON in and tweak visually:

https://app.slack.com/block-kit-builder

. Builder needs an object (

{ "blocks": [...] }

or a full view object), not a bare array.

帮助开发者通过Block Kit Builder查看其布局。若已安装Slack CLI，优先使用它。CLI会自动加载块，省去开发者复制粘贴的步骤。若CLI不可用，则提供标准Builder链接。

路径A：Slack CLI（优先）

使用

slack:slack-cli

技能的步骤1：检测Slack CLI，检查是否已安装公共CLI并解析其命令（

SLACK_CMD

）。

若CLI可用，运行

SLACK_CMD blocks preview --help

查看如何传递块并打开预览。该命令会将块加载到开发者浏览器中的Block Kit Builder。

由于是非交互式运行CLI，此命令还需要

--team

标志。使用

slack:slack-cli

技能的步骤2：通过帮助发现命令中的"解析

--app

和

--team

值"指南，运行

SLACK_CMD auth list

来解析团队ID；任何已认证的工作区均可用于预览，若有多个可用，选择一个并告知开发者，无需等待选择。

路径B：Block Kit Builder链接（回退，当CLI未安装时）

提供Block Kit Builder链接，让开发者粘贴JSON并进行可视化调整：

https://app.slack.com/block-kit-builder

。Builder需要对象（

{ "blocks": [...] }

或完整视图对象），而非纯数组。

Step 7: Iterate

步骤7：迭代

Ask whether the developer wants to add, modify, remove, or reorder blocks, or build a layout for a different surface. If they want to change the layout you just produced, re-enter Modification Mode (it preserves their

block_id

action_id

values); for a fresh layout, loop back to Step 3.

询问开发者是否需要添加、修改、删除或重新排序块，或为其他载体构建布局。若他们想要修改刚生成的布局，则重新进入修改模式（保留

block_id

action_id

值）；若需构建新布局，则回到步骤3。

Notes

注意事项

Scope: this skill owns building and validating the Block Kit payload — choosing the surface, composing the JSON from the live docs, and confirming it with
```
blocks.validate
```
. Sending it lives in the Web API layer (
```
slack:slack-api
```
), and CLI detection/auth in
```
slack:slack-cli
```
.
blocks.validate
needs no auth — it's a public method, so it works without a token whether you call it via the CLI or curl. Always validate before finalizing (Step 5).

范围：此技能负责构建和验证Block Kit负载——选择载体、从实时文档编写JSON、通过
```
blocks.validate
```
确认。发送负载属于Web API层（
```
slack:slack-api
```
），CLI检测/授权属于
```
slack:slack-cli
```
。
blocks.validate
无需授权——它是公共方法，因此无论通过CLI还是curl调用，无需令牌即可工作。在最终确定前务必进行验证（步骤5）。