diff --git a/skills/what-is-it/README.md b/skills/what-is-it/README.md
new file mode 100644
index 0000000..e0ebf6b
--- /dev/null
+++ b/skills/what-is-it/README.md
@@ -0,0 +1,53 @@
+# what-is-it
+
+帮助用户从零理解陌生概念、技术、系统或知识领域，建立能用于独立推理的整体心智模型。
+
+## 什么时候使用
+
+- 第一次接触某项技术、学科、产品、协议、组织或抽象概念。
+- 想理解一个主题的全貌、核心原理及关键概念之间的联系。
+- 已经知道几个名词，但还不能把它们串成完整的系统理解。
+- 明确想建立心智模型、认知框架、全局地图，或弄清系统的工作机制。
+
+不适合只要一句定义、翻译、数值、操作命令或具体故障排查的请求；这些场景应直接回答或使用更专门的 skill。
+
+## 使用前准备
+
+通常不需要准备。若有要求，可以一并说明：
+
+- 你的已有基础和目标读者。
+- 希望快速概览，还是系统深入理解。
+- 想重点了解动机、运行机制、案例、边界或替代方案。
+
+## 使用示例
+
+```text
+$what-is-it Kubernetes 是什么？我没接触过容器编排。
+```
+
+```text
+$what-is-it 帮我从零建立对债券市场的整体认知框架。
+```
+
+```text
+$what-is-it 我知道 DNS、域名和 IP，但不理解它们之间如何协作。
+```
+
+## Agent 会做什么
+
+1. 先定位主题、已有知识、疑惑和期望深度。
+2. 先建立全局地图，再解释关键概念、运行机制和设计取舍。
+3. 用一个贯穿始终的具体场景串联知识，并说明条件变化时的结果。
+4. 区分事实、推测、类比和不确定性，补充适用边界与常见误区。
+5. 在适当情况下给出迁移问题和下一步学习路径。
+
+## 如何判断完成
+
+读完后，应该能够用自己的话回答：
+
+- 它是什么、为什么存在。
+- 它由哪些部分组成，如何协作运作。
+- 什么时候适合使用，什么时候不适合。
+- 关键条件改变时，结果为什么会改变。
+
+本 skill 默认只输出解释，不修改文件。只有用户明确要求时，才把结果写入或改写为笔记、文章或其他文件。
diff --git a/skills/what-is-it/SKILL.md b/skills/what-is-it/SKILL.md
new file mode 100644
index 0000000..10a0415
--- /dev/null
+++ b/skills/what-is-it/SKILL.md
@@ -0,0 +1,141 @@
+---
+name: what-is-it
+description: 从零解释陌生概念、技术、系统或知识领域，帮助用户建立整体认知框架和可用于独立推理的心智模型，而不只是给出定义或堆砌术语。Use when the user asks “这是什么”“介绍一下”“从零讲解”“帮我建立心智模型”“整体理解某领域”, or explicitly invokes what-is-it. For a narrow factual question or a requested one-sentence definition, answer briefly instead of forcing a full tutorial.
+---
+
+# What Is It — 从零建立心智模型
+
+## 目标
+
+帮助对某个主题几乎没有先验知识的用户，从“听过一个名称”走到“能说清它解决什么问题、怎样运作、在什么条件下适用，并能够独立推理新情况”。
+
+交付的不只是知识清单，而是一套**可理解、可使用、可修正**的心智模型：
+
+- **知识框架**：领域中有哪些关键概念，它们分别处于什么位置、有什么联系。
+- **心智模型**：这些概念如何互动，哪些因素导致哪些结果，系统为什么这样运作。
+- **边界意识**：模型在哪些条件下成立、不成立；哪些是简化、类比或尚不确定的结论。
+
+始终坚持：**先整体、后局部；先为什么、再是什么、最后怎么做；讲关系和因果，不孤立罗列术语。**
+
+## 适用场景
+
+适用：
+- 用户第一次接触某项技术、学科、产品、协议、组织或抽象概念。
+- 用户希望从零入门，理解全貌、核心原理及其联系。
+- 用户已知道若干名词，但无法把它们串联成系统性的理解。
+- 用户明确要求建立“心智模型”“认知框架”“全局地图”，或者想理解一个系统的工作机制。
+
+不适用或需要缩小范围：
+- 用户仅要求一个定义、翻译、数值、操作命令或简短事实：直接回答，除非用户明确请求系统讲解。
+- 用户在排查具体故障：优先诊断和解决问题；若需要补齐底层概念，再按本 Skill 的思路解释相关部分。
+- 用户已提供明确的知识水平、篇幅或关注点：以用户要求为准，不强制从零开始。
+
+## 工作流程
+
+### 1. 定位主题和学习目标
+
+从问题中提取：主题、用户已有知识、想解决的疑惑、期望深度。
+
+- 未说明基础时，默认对**该主题**零基础，但不要把用户视作对所有事情都不懂。
+- 未说明深度时，先提供足够建立全貌的入门版本；允许后续继续深入。
+- 只有当主题含义真正不明确、会导致不同解释时才提一个澄清问题；否则按最常见含义开始讲解，并在必要时说明假设。
+- 不先抛一长串反问或要求用户选择学习路线。
+
+### 2. 第一阶段：建立全局地图（What / Why / Where）
+
+优先回答以下问题，按主题合并组织，不必机械逐条编号：
+
+1. **一句话直觉**：它是什么？用最少的新术语描述本质。
+2. **问题与动机**：它在解决什么痛点？如果没有它，人们通常如何处理？为什么需要它？
+3. **系统边界**：它是什么、不是什么；与相邻概念、替代方案有什么关系？
+4. **组成和结构**：核心部分有哪些？分别承担什么职责？它们之间的关系是什么？
+
+尽量给出一幅可记忆的文字地图：例如“输入 → 关键环节 → 输出”，或“核心对象 A → 与 B 协作 → 产生 C”。对于非流程型主题，使用概念关系图、层级结构或几条关键维度，避免强行套用流水线。
+
+### 3. 第二阶段：解释运行机制（How / Why）
+
+围绕最重要的 2–5 个概念，讲清楚：
+
+- 各概念为何存在，承担什么功能。
+- 它们怎样协作，信息、控制、资源或影响是如何传递的。
+- 最关键的因果链：**什么条件 → 发生什么 → 为什么导致这个结果**。
+- 必要的设计取舍：为什么这样做而不那样做；得到什么、牺牲什么。
+
+不要用一串新术语解释另一串术语。第一次出现关键术语时，给出简单定义，并说明它在全局地图中的位置。
+
+可以使用熟悉的类比降低理解成本，但必须指出重要的**类比失效点**，避免用户把比喻当作事实。
+
+### 4. 用一个贯穿始终的具体场景串联知识
+
+选择一个典型、尽量贴近现实的案例，按时间顺序或因果顺序演示：
+
+- 初始状态和目标是什么？
+- 哪些部分开始工作？它们如何相互作用？
+- 最终产生什么结果？
+- 如果一个关键条件改变，结果会如何变化？
+
+优先使用**一个讲透的例子**，不要堆砌很多互不相干的小例子。若主题跨多个学科，优先使用与主题最贴合的例子，而不是一律套软件工程场景。
+
+### 5. 说明适用边界与常见误区
+
+至少明确最重要的边界或限制：
+
+- 什么时候适用，什么时候不适用？
+- 哪些常见说法容易误导初学者？
+- 哪些内容只是便于入门的近似，哪些区别一旦进入实践就必须注意？
+- 如果领域存在分歧、例外或未知，区分确定事实、常见观点和推测。
+
+遵循“**地图不是领土**”：心智模型是对现实的简化，而不是现实本身。
+
+### 6. 验证用户是否获得可推理的模型
+
+在适当情况下给出 1–2 个**迁移问题或反事实推演**，例如：
+
+- “如果去掉组件 B，系统可能出现什么变化？为什么？”
+- “如果约束条件从 X 变成 Y，你会怎样判断是否还应该采用它？”
+- “遇到 Z，你会先检查框架中的哪个环节？”
+
+提供简短参考思路，或邀请用户先尝试推理；不要强行考试，更不要在用户没有请求时生成冗长测验。
+
+### 7. 给出下一步学习路径
+
+结尾用简短内容区分：
+
+- **现在需要记住的核心模型**：用 1–3 句话重新连接“问题—结构—机制—边界”。
+- **下一步值得学什么**：按依赖关系推荐少量后续概念，解释为什么先学它们。
+
+如果用户明确表示只需概览，可省略学习路径和验证问题。
+
+## 输出策略
+
+根据用户的要求自动切换深度，不强制输出固定的七段模板。
+
+**简明模式**（“简单说说”“一句话介绍”）：一句话本质 + 解决的问题 + 一个关键机制或例子；通常 1–4 段。
+
+**标准模式**（默认“介绍一下”“从零理解”）：先全局概览，再讲 2–5 个关键概念及关系、主要运行机制、贯穿案例与边界，最后给出简短的心智模型总结。
+
+**深入模式**（“系统讲解”“彻底理解”“深入原理”）：加入历史动机、结构图、逐步推演、设计取舍、例外情况、与替代方案的比较，以及迁移问题。内容较多时按照由浅入深的层次组织。
+
+可以使用标题、表格、ASCII 图或简洁流程图辅助理解，但只在它们比纯文字更清楚时使用。**不要为了显得系统而扩大篇幅。**
+
+## 回答质量检查
+
+完成前快速检查：
+
+- 用户能否说清“它解决什么问题”，而非仅复述定义？
+- 用户是否知道关键部件/概念之间的关系，而非只记住术语？
+- 用户能否理解一个“条件改变 → 结果改变”的因果推理？
+- 是否给出真实可感的场景和核心适用边界？
+- 是否引入未解释的专业名词，或把类比误认为事实？
+- 是否匹配用户要求的篇幅和深度？
+
+如任何一项明显不满足，优先修正解释结构，而不是简单继续追加知识点。
+
+## 使用示例
+
+- `$what-is-it Kubernetes 是什么？我没接触过容器编排。`
+- `$what-is-it 帮我从零建立对债券市场的整体认知框架。`
+- `$what-is-it 什么是 EtherNet/IP？先讲清它在工业通信体系中的位置。`
+- `$what-is-it 我知道 DNS、域名和 IP，但不理解它们之间如何协作。`
+
+输出的目标是让用户最终能够独立回答：**“它是什么、为什么存在、如何运作、什么时候适合、条件变化时会怎样？”**