frontend-docs-generator

name	frontend-docs-generator
description	用于根据 ERARK 标杆文档规范，将 Vue/UI 代码重构记录、组件分析结果输出为“稳定可查阅的开发者字典”。当用户要求“总结架构”、“撰写UI文档”、“生成状态栏文档”时自动调用此 skill。

Instructions

此 Skill 强制规定了前端/UI 组件的文档撰写结构和禁忌，确保文档具备强排错能力，拒绝空洞的总结和废话。

核心铁律 (The Absolute Laws)

1. 代码即文档，拒绝抽象概括：讲业务前，必定先用真实代码块把数据结构、接口契约（Interface/Type/Enum）原汁原味地摆出来。不要用“包含了阈值”这种废话概括常量，把常量对象完整贴出来！
2. 避免行数浪费（二选一原则）：在展示状态数据时，如果你已经选择用 Markdown 表格完整列出了所有状态并详尽解释（例如包含了 UiMode, PHYSICS_CONSTANTS 等），就不要再重复贴一大段仅包含这些定义的无注释原代码块。要么选择“带有详细注释的代码块”，要么选择“包含完整字段信息的数据列表（表格）”。
3. 因地制宜，绝不机械套用空标题：
   • 如果一个模块只是一个单独的文件（如 .ts），把文件路径写在标题上即可，绝对不要强行写一个 ## 组成 的空标题。
   • 绝对不要在纯逻辑的 .ts 文件下写 ## 样式骨架。只有包含真实 DOM 和 CSS 约束的 .vue 或 HTML 文件才配拥有这个标题。
4. 多维度的流转剖析：系统级别的交互逻辑、事件流转绝不能只用一个 # 补充点 草草概括。必须根据实际业务，拆分成多个独立的 # 级标题（如 # 用户交互流程、# 数据拦截流转）进行深度剖析。

强制文档骨架 (The Mandatory Structure)

未来的每一份系统架构文档，必须包含以下顶级结构：

一、 总体简介

用 1-2 段话，说明该系统的业务边界、核心机制以及它在整个项目中的地位。

二、 内容组成 (系统总览字典)

必须使用 Markdown 表格，将该系统涉及的所有核心文件、子组件全部列出。 格式范例：

# 内容组成
| 模块名称 | 对应工作区路径 | 说明 |
| :--- | :--- | :--- |
| **全局 UI 入口** | `src/ARK_STATUSBAR/components/GlobalStatusBar.vue` | 常驻浮动状态栏组件，挂载 4 个业务 Tab 并处理物理外壳拖拽。 |
...

三、 模块解剖 (按核心模块分章节)

针对上面表格中的核心文件，逐一进行 # 级章节的深入解剖。如果模块由多文件组成才写 ## 组成；如果是单文件，直接把文件路径挂在模块标题旁。

剖析维度要求：

1. 状态 (State)：选择带有详细注释的真实代码块，或包含所有属性说明的 Markdown 表格。务必穷尽所有的状态变量，不要遗漏如 isSnapping 或 PHYSICS_CONSTANTS 的细节。
2. 函数 (Functions)：表格（| 函数签名 | 触发时机 | 副作用与逻辑 |）。复杂的函数必须配上 ASCII 调用链。
3. 事件 (Events)：表格记录向内监听（Listeners）与向外发射（Emits）的 Payload。
4. 样式骨架 (DOM & CSS)：仅限 Vue/UI 文件。必须贴出决定布局生死的精简 HTML 树，并强制列出红线 CSS 字典（如 min-width: 0、grid-template-rows: 0fr）并解释其防崩溃排错原理（如：防止 Grid Blowout）。

四、 系统交互与业务流转 (Holistic Workflows)

拆分出多个单独的 # 级标题来讲解事件流转和逻辑机制。不要写一个敷衍的“补充点”。 例如：# 拖拽坐标系的动态双轨移交原理 或 # 气泡状态下的橡皮筋反馈与触发机制。

五、 扩展指南 (Extension)

给开发者的“傻瓜教程”。必须是 1-2-3-4 的明确代码步骤。（如：新增一个 Tab 面板需要改哪几个文件、加哪几行代码）。

六、 故障排查 (Troubleshooting)

基于真实开发历史记录的 Debug 字典。 必须使用 Markdown 表格：| 具体的视觉崩溃/错误症状 | 根本诱因 (Root Cause) | 去哪里检查代码 (Checklist) |。

七、 补充要点 (Redlines)

架构级别的绝对警告、不可触碰的历史遗留代码区（如：不准覆盖原生 CSS 圆角设计等）。