obsidian-layout-adjustment

Obsidian 布局调整

这项技能用于在遵循用户视觉语言的同时，通过 CSS 文件改变 Obsidian 的外观。

Obsidian 始终是同一种环境：应用框架、标签页标题、侧边停靠栏、视图标题、窗格外壳、笔记表面、属性、文件浏览器、反向链接、关系图、渲染后的 Markdown 和状态栏。保险库、主题、代码片段、插件和期望的审美方向会变化，但画布始终是 Obsidian。

核心行为是转换：

用户指出一个可见的 Obsidian 对象。将这个描述转换为稳定的 Obsidian 层／后端对象，安全编辑启用中的代码片段，为结果截图，并持续迭代，同时保留效果良好的状态。

这不是通用的 CSS 工作流，也不是固定主题生成器。

常规输出模式

这项技能应该加快实时样式调整，而不是把每个小请求都变成一份报告。

常规使用时：

1. 仅在能避免歧义时说明映射关系。
2. 映射说明要简短：通常一句话就够了。
3. 然后开始操作：检查启用中的代码片段、创建检查点、应用补丁、格式化、重新加载、截图。
4. 简要报告结果，包括已更改的文件、检查点和截图状态。

良好的常规更新：

“我将‘笔记上方的标签页’理解为工作区标签页标题，而不是视图标题中的箭头／书本／圆点。我会为启用中的代码片段创建检查点，仅修改对应的选择器系列，并为标签栏截图。”

除非符合以下情况，否则不要编写冗长的工作流报告：

• 用户要求提供计划、审计、审查或说明。
• 你正在运行评估或构建这项技能。
• 你正在重构，但不会更改视觉效果。
• 请求的含义不够明确，贸然操作风险较高。

重点是在快速推进的同时，避免陷入错误的 CSS 调整循环。

参考资料的使用

在以下情况下阅读 references/workflow-reference.md：

• 用户用自然语言指出可见的 Obsidian 对象。
• 请求的目标可能属于多个 Obsidian 层。
• 截图显示“没有变化”“仍然换行”“没有抬高”、边缘不齐、表面褪色或图标难以辨认。
• 你正在重构启用中的代码片段，但不改变已接受的外观。
• 你需要了解 Obsidian 表面映射、变更类型映射或故障模式列表。

此参考资料专为 Obsidian 编写。在将界面视作未知网页之前，请先查阅它。

操作循环

1. 从当前运行的保险库开始。
2. 读取 <vault>/.obsidian/appearance.json。
3. 将 enabledCssSnippets 视为当前样式的唯一可信来源。
4. 先读取启用中的代码片段，再查看归档、备份或旧实验。
5. 将用户的描述转换为 Obsidian 对象及其所属层。
6. 对变更类型进行分类：颜色、可读性、抬高、形状、结构、密度、简化、工作流或重构。
7. 在进行主观调整前，保存一个带名称的检查点：将启用中的代码片段复制到 .obsidian/snippet-archive/，切勿复制到 .obsidian/snippets，以保持代码片段选择器整洁。
8. 重新读取当前的确切代码块，然后只编辑一个所属层：舞台、外壳、标题、包装器或子元素。格式化会改变文件结构；根据记忆中的结构编写补丁，机械操作时可能会失准。
9. 格式化 CSS。
10. 重新加载 Obsidian／将其置于前台，并为受影响的准确区域截图。
11. 将截图和用户的修正作为依据。
12. 如果失败，请检查所属关系或恢复；不要继续向同一个错误目标叠加 CSS。
13. 只有在用户接受视觉效果后才进行重构。

编辑前先进行对象映射

用户通常会描述他们看到的内容，而不是选择器：

• “笔记上方的选项卡”
• “笔记上方的箭头／书本／省略号”
• “笔记左侧的按钮”
• “右侧边栏”
• “那些小区域里的链接”
• “笔记外围的东西”
• “选中的图标”
• “左上角的白色区域”

编辑前，先映射这些说法：

user phrase -> visible object -> Obsidian layer -> likely selector/settings surface -> change type -> owning layer

可能存在歧义时，复述映射结果：

“你说的笔记上方的选项卡，我理解为工作区选项卡标题，而不是笔记窗格内那排箭头／书本／省略号。”

这是防止出错的关键步骤。最令人恼火的失误，大多是改了一个看似合理、但并非用户所指的元素，或者改了子元素，而实际决定可见形状的是其包装层／标题／舞台。

稳定的层级结构

先使用这份简明映射，然后在当前库中确认确切的选择器：

用户指的对象	通常对应
左上角的白色／原生区域	标题栏／原生界面，或相邻的应用标题栏
笔记上方的选项卡	工作区选项卡标题
选项卡旁的加号	新建选项卡控件
绿色／顶部栏	应用框架或选项卡标题容器
最左侧的图标	功能区／侧边停靠栏
选中的侧边图标	活动的侧边停靠栏选项卡标题及图标状态
文件列表上方的按钮	文件浏览器导航控件
笔记／文件夹左侧的按钮	文件浏览器树形行
库名称／页脚	侧边停靠栏配置文件／页脚
笔记上方的箭头／书本／省略号	Markdown 视图标题
笔记／页面／纸张	Markdown 叶窗格、编辑器或可读表面
笔记的阴影／抬升／边缘	舞台、外壳、槽沟、溢出区域或伪元素之间的关系
属性	元数据容器或 Properties View 工作流
链接	阅读／编辑模式下的内部链接文本
右侧边栏	右侧工作区拆分区域和实用工具叶窗格
链接提及／反向链接	反向链接插件结果组
图谱	图谱插件叶窗格／画布
底部统计信息	状态栏

在 Obsidian 中操作时，应将可见对象及其后端层视为稳定不变。确切的类名可能因主题／插件／应用版本而异，因此修改前要在当前库中确认。

按更改类型区分处理

根据请求的不同，同一对象可能需要不同的处理：

• 颜色／强调色：同时更新背景、文本、边框、图标描边／填充，以及活动／悬停／焦点状态。
• 可读性：检查渲染后的对比度，尤其是彩色工具栏上的图标。
• 抬升／纵深感：确定前景、舞台、外壳、槽沟、溢出区域和外部阴影。抬升是一种关系，不只是 box-shadow。
• 圆角：检查父级外壳、子级圆角、溢出区域和相邻背景。
• 结构：为控制可见形状的包装层／标题／外壳设置样式。
• 简化：先移除包装层、边框、渐变、阴影或伪元素，再添加更多修饰。
• 属性／工作流：使用 CSS 压缩元数据前，考虑 Obsidian 的 Properties View 或显示设置。
• 重构：保留级联顺序，并确认截图没有变化。

如果目标涉及两种更改类型，就分两步处理。例如，先让侧边停靠栏图标清晰可读，再调整选中状态的颜色。

优先修改项

从以下内容开始：

• appearance.json 中的活动 CSS 片段
• 问题涉及工作区行为时，检查 Obsidian 设置
• 如果修改应保持可调整，则检查 Style Settings 或主题变量
• 稳定的 Obsidian 包装层：标签页标题、视图标题、窗格外壳、侧边停靠栏、文件行、笔记表面、反向链接分组

避免优先修改：

• Obsidian 应用程序包文件
• 社区插件源文件
• 已安装主题的源文件
• 仅为强制实现视觉样式而修改知识库内容
• 在排除活动片段和主题 CSS 之前修改应用内部代码或压缩代码

以下操作前，请先征得明确确认：

• 切换主题
• 禁用片段或插件
• 作为工作流变更来隐藏或移动属性
• 大幅更改全局排版或编辑器密度
• 删除归档的实验内容
• 更改 .obsidian/snippets 之外的文件或 Obsidian 设置

截图关卡

CSS 有效不代表视觉效果成功。截图才是产品的真实呈现。

每次进行有意义的视觉调整时：

1. 保存检查点。
2. 应用补丁。
3. 格式化 CSS。
4. 重新加载或切换到 Obsidian。
5. 截取受影响区域。
6. 将截图与问题描述进行比较。

如果其他窗口遮挡了 Obsidian，请重新截图。验证验证过程：确认 Obsidian 确实位于最前端，再采信截图（可用 AppleScript 检查最前端进程）。如果问题很小，只截取相关区域——使用 screencapture -R<x,y,w,h> out.png——框住边缘、图标、标签页、行或窗格。

如果截图证明修复无效，就继续处理、恢复原状，或说明修复失败。不要因为格式化成功，就当作问题已经解决而结束。

失败信号

用户的更正是选择器线索：

• “什么都没变”意味着选择器、样式层不正确，或存在裁切、遮挡、覆盖。
• “还是换行了”通常意味着包装层和子元素都被设置了样式。
• “没有抬高”意味着舞台、外壳和间距的关系不正确，或效果太微弱。
• “右侧变浅了”说明笔记上方可能有覆盖层或伪元素。
• “图标完全看不清”意味着必须同时处理活动/非活动按钮的填充色和图标颜色。
• “过头了”通常意味着应先移除样式，而不是再叠加一层。

如果某个方向连续失败两次，请恢复到最近一次有效检查点，并更改样式归属模型。

重构规则

不要在探索视觉风格时重构。

用户认可视觉效果后：

1. 保存基线检查点。
2. 添加或更新文件映射和章节标题。
3. 除非有意更改，否则保持选择器顺序不变。
4. 格式化 CSS。
5. 检查差异，确认没有意外的视觉变化。
6. 截取 Obsidian。
7. 将不活动的迭代版本归档到 .obsidian/snippets 之外。

CSS 文件大小通常没有级联混乱和活动片段选择器杂乱那么危险。

收尾报告

完成后，简短总结以下内容：

• 更改过的活动片段文件
• 保存的检查点路径
• 用户的哪些说法对应 Obsidian 的哪些样式层
• 已通过截图验证的内容
• 尚未验证或有意暂缓的事项

避免每次小调整后都解释完整工作流。工作流应体现在实际操作中：保存检查点、限定范围进行编辑、截图，并依据证据决定下一步。