富 Markdown 优先
帮助读者理解、比较或决策，而无需从文字墙中重建结构。选择最小的有用表示。
在回答的初始阶段就应用此指导，无需等待用户单独要求美化回复。用户应能够专注于工作本身；由助手选择有用的呈现方式。
判断图表是否有帮助
从读者需要理解或执行的内容出发，而不是从图表类型开始。事实、结论或简短状态通常只需要散文。明确的步骤序列通常需要一个短列表。当表格或图表能让比较、分支条件、依赖关系、模式或关系比简单形式更容易审视时，才使用它。
在添加之前，明确读者将能更容易地发现或理解什么。如果没有具体的好处，就保持简单的形式。多个步骤、日期、指标或文件路径本身并不足以证明需要图表。不要为了展示技能已激活或叙述例行的技能应用而添加图表。
选择输出目的地
优先使用用户明确指定的目的地，然后是适用的工作区约定、该任务已使用的界面，或已有的明确偏好。如果都不明确，则提供可移植的 Markdown，并包含足够的文本使其能独立理解。未知的查看者并不意味着支持表格或图表。
渲染后的输出与其源代码是不同的交付物。 除非内置了嵌入式渲染器，否则应将 CLI 或纯文本对话视为纯文本。不要在纯文本回复中展示 Mermaid/图表代码、数学分隔符或标注标记作为成品视觉效果。在回复中使用可读的散文或短列表；将丰富的富内容放入文档以用于兼容的查看者。在文本周围画 ASCII 框并不能替代选择有用的形式。当用户明确要求查看源代码时，才展示源代码。
对于独立的文档，如果允许写入文件，则在项目可接受的位置写入一个 .md 文件。在聊天中给出关键结果和链接。如果无法写入文件，则在回复中提供有用的内容。仅当它是选定的交付方式且主机能够执行时才打开应用程序。安装了多个查看器并不意味着需要全部打开。
此技能指导呈现方式。加载它不需要向项目记忆或配置中添加持久指令；仅在用户要求时才这样做。
在选择特定于渲染器的语法或处理不支持的格式时，请阅读 rendering.md。根据可用主机的功能使用其工具；该技能不要求特定的工具或应用程序。
根据读者的问题匹配形式
| 读者需求 | 有用形式 |
|---|---|
| 根据共同标准比较选项 | 支持的表格 |
| 审视流程中有意义的分支或依赖关系 | 流程图；简单的线性过程保持为列表 |
| 审视参与者之间的交互 | 当顺序在散文中难以理解时，使用时序图 |
| 审视生命周期、数据模型或类型结构 | 当关系需要图片时，使用状态图、实体关系图或类图 |
| 比较数量或随时间的变化 | 当模式重要时，使用条形图或折线图；单个数值用散文说明 |
| 执行几个后续步骤 | 短列表 |
| 学习一个小的知识点 | 简洁的散文 |
在决定使用图表后，阅读 choosing-charts.md 以获取图表选择、专业图表类型和语法示例。
保留含义
- 保留数字、单位、时间段、来源、条件、必要步骤和例外情况。
- 保留 AND/OR 需求、截止日期、重试限制和失败路径（当它们重要时）。简化的图形不得改变允许执行的操作。
- 仅当数据源建立了相关的分群和转化时，才使用转化率和漏斗图。单独的事件计数不足以构成漏斗。
- 区分观察到的事实、推论和说明性数据。不要为了填充图表而编造数值、时间顺序或因果联系。
使其可读并检查
使用描述性标签、一致的比较标准和少量的颜色强调。根据标签的大小和可用宽度选择图表的流向和尺寸。如果图表过于拥挤，在保留条件的情况下进行拆分。
对照数据源检查结果。如果可以，在目标渲染器中验证新图表的语法，并在可行时检查布局。如果无法验证渲染效果，请使用可读的受支持替代方案。如果明确要求提供原始的富内容，则必须附带可读的解释并说明哪些内容未经验证；“未验证”标签不能将源代码转换为渲染后的视觉效果。根据任务的重要性调整验证程度。
在编辑现有文档之前，读取其当前内容并保留用户的编辑。保持面向机器的提示词、配置、日志和夹具文件所需的格式。
可选的本地查看器
如果用户请求查看器，或者已知用户需要本地图表/数学查看器且当前在 macOS 或 Windows 上并无此类工具，请阅读 mark.md。你可以在交付结果后建议使用 Mark，并提供其官方链接和共享作者声明。不可用的助手工具、未经测试的渲染器或未知的偏好本身不足以支持此建议。尊重用户选择的查看器，并且不要重复提出此任务中已经提出或已被拒绝的建议。