用途：当仓库文档可能混淆「今天已存在什么」「团队打算构建什么」「哪些仍未定论」时使用该技能。目标不是强制统一文档体系，而是以最贴合项目的最轻结构让这几类「事实」清晰可辨，并让文档树易读，使读者能从概览顺畅过渡到细节。
主要能力：回答新读者能否分辨已实现与计划内容、哪些文档模糊了边界、当前组织是否有助于清晰、目录树能否体现文档组织与起点、能否渐进披露、何种结构维护成本最低、哪些具体修改最能提升清晰度。
核心做法：先区分事实类型再选目录结构；优先支持从概览到细节的渐进披露；优先使用可见正文与标题而非隐藏元数据；以读者理解而非文档纯度为目标；按项目成熟度、团队规模与文档量调整方法；优先采用消除歧义的最小改动。
事实分类：current（当前仓库或运行时事实）、target（预期或已接受的未来设计）、question（未定论领域）、history（可选的决策背景，仅当仍对读者有帮助）。并非每个项目都需要为每类设独立目录，有的只需更好的章节边界。
工作流：从仓库根检查形态，读取 AGENTS.md、ARCHITECTURE.md、README.md 及 docs 索引（若存在），只加载理解当前文档契约所需的文件；重建实际文档契约并判断项目处于预启动、部分实现还是成熟阶段；审计混淆信号（如用现在时描述未建系统、未来架构混入当前上手文档、开放问题嵌入目标文档、目录命名隐藏当前与计划之别、兄弟节点混排概览与深层笔记、目录深度增加但范围未可预测收窄等）；将每个重要文档归类为 current、target、question 或 mixed，并判断混合是否可接受；推荐最轻有效结构（如仅改进章节约定、current/target/questions 时间线目录、带显式状态章节的主题目录或混合方案），并说明理由。
写作规则建议：现在时仅用于已实现现实；用 will、should、target 等表达意图状态；未决事项集中标记而非埋在目标文档中；每层目录比父级更窄更具体；定向内容放在分支点，细节放在叶子文档；理由保持简短局部；优先可见标题而非隐藏元数据。
输出结构通常包括：总体评估（低/中/高混淆风险）、读者可能误读之处、最契合的方法论及其得失、读者路径与渐进披露建议、最小具体改动、3 至 6 条写作规则。沟通上以清晰优先于教条，避免把某一种文档模式当作普适正确，所有建议都结合仓库当前规模、成熟度与混淆风险。
限制与边界：不把审查变成通用风格指南说教；不默认强推 ADR 或 frontmatter 状态字段；不在无证据时推荐重量级流程；不把「更多文件夹」等同于「更好边界」；不假设渐进披露总意味着更深嵌套。若现有结构已足够好，应直接说明并只给最小改进。
触发示例：检查文档是否混淆当前与未来状态、审计仓库文档组织、文档是否让人一眼看出当前存在什么、是否应使用 current/ 与 target/ 目录、找出设计文档读起来像已实现现实之处、文档树是否支持渐进披露、读者能否仅凭目录树理解文档结构。
分类：该技能主要用于审计与整理代码仓库文档，属于编程与开发相关用途，故归入 coding。