Community图像github.com

Mental – 心智模型构建技能

通过角色、边界与通信来阐释系统的全貌,从最简单的设置逐步演进到当前架构。仅当用户明确调用 /mental、$mental 或请求使用本技能时激活。始终包含 Mermaid 时序图或已渲染的 D2 图像。

Mental – 心智模型构建技能 是什么?

Mental 是一款面向 AI 代理的技能,专注于通过角色、边界和通信来揭示软件系统的深层结构。它的核心契约是:任何完整的解释必须在回复中直接包含一幅 Mermaid 时序图(默认使用 `sequenceDiagram` + `autonumber`)或一幅已渲染的 D2 图像;ASCII 箭头、列表、普通代码块、指向图的链接或未渲染的 D2 源码均不符合要求。该技能只在用户明确通过 `/mental`、`$mental` 或直接请求调用时激活,要求代理从最简系统(如本地运行的脚本)出发,逐步构建到目标架构的演化过程,同时清晰标注跨边界传递的具体内容(如 HTTP 请求、JSON 响应、事件等)。它要求代理在写长篇解释之前先构造图表,并强调图表的叙述准确性:必须通过编号的交互步骤与配套的文字描述来追踪一条完整的请求-响应链,让视觉图形与文字说明保持严格一致。Mental 适用于需要快速理解或向他人讲解系统架构的开发场景,默认使用 Mermaid(无需渲染工具),若用户偏好 D2 且渲染环境可用,则嵌入渲染后的图像。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/amrable/agent-skills/tree/HEAD/skills/mental

Installed? Explore more 图像 skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

心智模型

通过角色、边界和通信来阐释系统。

输出契约:图优先

完成的心智模型解释必须在回复中直接包含一张图。 先写一句简短的引导句,然后立即包含以下二者之一:

  • 使用 sequenceDiagram 和 autonumber 的围栏 mermaid 代码块(默认)。
  • 如果渲染可用且用户请求了 D2,则嵌入已渲染的 D2 图像。

然后用简洁的文字解释流程及其演变过程。先构造图,再写较长的解释,这样才能保证可视化内容不会被放到末尾。此契约同样适用于短回答以及继续已显式发起的心智模型讨论的后续解释。仅澄清性问题不需要图。如果用户明确要求不要图,则遵从该要求。

ASCII 箭头、项目符号列表、表格、普通代码块、图的链接、承诺稍后画图以及未渲染的 D2 源码均不满足此契约。不要问用户是否想要图。如果没有渲染器可用,仍然输出 Mermaid 源码;不要用文字替代它,因为聊天环境可能无法渲染该图。生成 Mermaid 代码块不需要任何图生成工具。

所需回复形状的示例(根据实际上下文调整角色):

浏览器请求 API 保存数据;API 拥有数据库访问权限。

```mermaid
sequenceDiagram
    autonumber
    participant 浏览器
    participant API
    participant 数据库
    浏览器->>API: 保存表单数据
    API->>数据库: 存储已接受的数据
    数据库-->>API: 已保存的记录
    API-->>浏览器: 成功响应
```

表单从浏览器开始。添加 API 使其能远程保存;添加数据库则使保存的数据能超越单个请求的存活时间。

显式调用

仅当用户明确请求时才使用本技能:/mental、$mental、或直接要求使用心智模型技能。一般的解释请求不会激活本技能。将此次调用视为解释请求,而不是实施、安装、发布或更改所解释系统的许可。

使用调用后跟随的主题,或从对话中推断该主题。只有当主题无法合理推断时,才提出一个精准的问题。

构建解释

  1. 将模型根植于对话和可用证据中。对于现有代码库,只需检查必要的入口点或配置,以建立相关关系。区分观察到的事实与假设。不要凭空捏造服务、成功的部署或已验证的行为。
  2. 从最小的可用系统开始:本地运行的单个脚本、显示页面的浏览器、或响应请求的服务。在引入基础设施之前先解释已经能工作的部分。
  3. 逐步向讨论中的系统推进。在每个有意义的阶段,解释新的需求、为满足该需求而添加的角色或连接,以及操作现在如何穿越系统。这些是解释性阶段,而非声称的历史时间线。如果用户询问实际项目演进,请使用可用历史并指出差距。
  4. 根据上下文选择角色:人、进程、服务、存储、注册表、队列或外部提供商。为每个角色赋予具体的职责。当位置影响理解时,按机器、进程或网络边界对相关角色进行分组。
  5. 按照顺序追踪一个具体的操作在角色间的传递,包括返回给调用者的结果。标记每个边界上穿过的内容:源码、包归档、HTTP 请求、JSON 响应、事件或存储的数据。在设置/分发和运行时通信都有意义时,将两者分开处理。
  6. 仅在可能引起混淆的地方解释区别。例如,包名选择要获取的内容,命令名选择要运行什么,而参数成为该命令的输入。对于浏览器/API 示例,需区分代码分发和后续的 API 请求。

倾向于用一段连贯的文字展示简短递进过程,而不是术语表或组件目录。如果用户只关心当前交互,则仅展示该流程,无需强行展示漫长的演进过程。命令和代码片段应锚定模型;避免列出选项清单、实施步骤详解和不相关的替代方案。保留能改变模型的细节,例如缓存避免重复下载,或异步确认在工作完成前到达。

图的准确性

使用本技能生成的每个回复必须至少包含一幅 Mermaid 图或一幅已渲染的 D2 图像。默认使用围栏 mermaid 代码块:它不需要渲染工具,且当渲染不可用时源码仍可读。

  • 优先使用带编号的时序图:以 sequenceDiagram 开头,紧接着 autonumber。让调用、消息和回复的顺序可见。以从左到右的可读顺序引入参与者。
  • 对回复和请求都进行编号,以便读者能跟随完整的交互。在文字中追踪编号步骤;保持引用与图一致。编号展示了所说明的场景,而非声称并发工作总是按固定顺序运行。当并发、选择或可选步骤改变模型时,使用 par、alt 或 opt。
  • 对于演进过程,为有意义的阶段使用独立的、小的编号序列;保持参与者名称稳定,并解释添加了哪个角色或消息。
  • 仅当拓扑或结构是主要问题且时序图会使之模糊时,或当用户请求时,才使用流程图。对于展示交互的 D2 图像,优先使用时序布局并显式对消息编号。
  • 使用具体的角色名称和带操作或数据标签的定向箭头。避免无标签的箭头和无法解释任何内容的装饰性方框。
  • 保持每张图聚焦于正在解释的交互。将不同的阶段或拥挤的系统拆分成小的图。在分层图中,标记哪些角色和连接是新引入的。
  • 保持标签简洁,对包含标点符号的流程图标签使用引号。在发送前检查节点引用、箭头方向、子图和围栏语法。
  • 包注册表分发代码;不要将其画成执行用户 CLI 的角色。数据库存储数据;不要将其画成发起普通应用请求的角色——除非这确实是系统的一个真实特性。
  • 如果用户偏爱 D2 且渲染器可用,则渲染并检查结果,然后嵌入图像。仅 D2 源码不满足图像要求。如果渲染不可用,则使用 Mermaid 并简要说明降级情况。不要为了解释模型而安装渲染器。

在图的后面附上一段简短的具体操作讲解。当模型清晰后即可结束;不要附加实施任务或通用总结。

发送前检查

检查回复本身:是否包含围栏 mermaid 代码块或嵌入的已渲染 D2 图像?如果两者都没有,则解释不完整。在发送前添加图。对于 Mermaid 时序图,确认 autonumber 已出现。检查其箭头是否与文字匹配,并且至少追踪一个使用具体角色和带标签通信的真实交互。

示例

当示例有助于校准解释时,请阅读 references/examples.md。其中包含 npm 分发、前端/后端调用、服务间调用和异步任务。根据实际上下文调整方法,而不是将这些角色引入到每次解释中。

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

相关技能