Release v1.32.0: Add windows-remote-desktop-connection-doctor skill
- Add windows-remote-desktop-connection-doctor v1.0.0 for diagnosing AVD/W365 connection quality issues with transport protocol analysis and log parsing - Update claude-md-progressive-disclosurer SKILL.md and references - Update marketplace to v1.32.0 (37 skills) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
daymade
@@ -2,8 +2,8 @@
|
||||
name: claude-md-progressive-disclosurer
|
||||
description: |
|
||||
Optimize CLAUDE.md files using progressive disclosure.
|
||||
Goal: Maximize LLM working efficiency, NOT minimize line count.
|
||||
Use when: User wants to optimize CLAUDE.md, complains about context issues, or file exceeds 500 lines.
|
||||
Goal: Maximize information efficiency, readability, and maintainability.
|
||||
Use when: User wants to optimize CLAUDE.md, information is duplicated across files, or LLM repeatedly fails to follow rules.
|
||||
---
|
||||
|
||||
# CLAUDE.md 渐进式披露优化器
|
||||
@@ -12,7 +12,14 @@ description: |
|
||||
|
||||
> "找到最小的高信号 token 集合，最大化期望结果的可能性。" — Anthropic
|
||||
|
||||
**目标是最大化 LLM 工作效能，而非最小化行数。**
|
||||
**目标是最大化信息效率、可读性、可维护性。**
|
||||
|
||||
### 铁律：禁止用行数作为评价指标
|
||||
|
||||
- 行数少不代表更好，行数多不代表更差
|
||||
- 优化的评判标准是：**单一信息源**（同一信息不在多处维护）、**认知相关性**（当前任务不需要的信息不干扰注意力）、**维护一致性**（改一处不需要同步另一处）
|
||||
- 禁止在优化方案中出现"从 X 行精简到 Y 行"、"减少 Z%"等表述
|
||||
- 一个结构清晰、信息不重复的长文件，比一个砍掉关键信息的短文件更好
|
||||
|
||||
### 两层架构
|
||||
|
||||
@@ -285,16 +292,16 @@ function getDatabase() {
|
||||
|
||||
## 反模式警告
|
||||
|
||||
### ⚠️ 反模式 1：过度精简
|
||||
### ⚠️ 反模式 1：以行数为目标的过度精简
|
||||
|
||||
**案例**：把 2937 行压缩到 165 行
|
||||
**案例**：为了"减少行数"，移走了代码模式、诊断流程、目录映射
|
||||
|
||||
**结果**：
|
||||
- 丢失代码模式，每次重新推导
|
||||
- 丢失代码模式，LLM 每次重新推导
|
||||
- 丢失诊断流程，遇错不知查哪
|
||||
- 丢失目录映射，找文件效率低
|
||||
|
||||
**正确**：保留所有高频使用的内容，即使行数较多。
|
||||
**正确**：保留所有高频使用的内容。优化的判断标准是信息是否重复维护、是否与当前任务无关，而不是"文件太长"。
|
||||
|
||||
### ⚠️ 反模式 2：无触发条件的引用
|
||||
|
||||
@@ -320,6 +327,14 @@ function getDatabase() {
|
||||
|
||||
**正确**：移到 Level 2，保留触发条件。
|
||||
|
||||
### ⚠️ 反模式 5：用行数当 KPI
|
||||
|
||||
**案例**：优化方案写"从 2000 行精简到 500 行，减少 75%"
|
||||
|
||||
**问题**：把行数当成功指标，会驱动错误决策——为了凑数字而砍掉有用的信息。
|
||||
|
||||
**正确**：用信息质量评估优化效果——信息是否有重复？维护负担是否降低？LLM 是否能更快找到需要的信息？
|
||||
|
||||
---
|
||||
|
||||
## 信息量检验
|
||||
@@ -354,7 +369,7 @@ function getDatabase() {
|
||||
|------|--------|--------|
|
||||
| 位置 | `~/.claude/CLAUDE.md` | `项目/CLAUDE.md` |
|
||||
| References | `~/.claude/references/` | `docs/references/` |
|
||||
| 行数参考 | 100-300 | 300-600 |
|
||||
| 信息范围 | 个人偏好、全局规则 | 项目架构、团队规范 |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -4,13 +4,13 @@
|
||||
|
||||
---
|
||||
|
||||
## 案例 1：过度精简的失败
|
||||
## 案例 1：以行数为目标的过度精简
|
||||
|
||||
### 背景
|
||||
某项目 CLAUDE.md 原有 2937 行，尝试优化。
|
||||
某项目 CLAUDE.md 内容丰富，包含代码模式、诊断流程、目录映射等。
|
||||
|
||||
### 错误做法
|
||||
压缩到 165 行，移走了大部分内容。
|
||||
以"减少行数"为目标，移走了大部分内容，只保留简短描述和指针。
|
||||
|
||||
### 结果
|
||||
- ❌ 丢失代码模式，LLM 每次重新推导
|
||||
@@ -18,17 +18,17 @@
|
||||
- ❌ 丢失目录映射，找文件效率低
|
||||
|
||||
### 正确做法
|
||||
保留 482 行，关键内容如下：
|
||||
按**信息质量**而非行数判断去留：
|
||||
|
||||
| 内容 | 保留位置 | 原因 |
|
||||
|------|----------|------|
|
||||
| 核心命令表 | Level 1 | 高频使用 |
|
||||
| 懒加载代码模式 | Level 1 | 需要直接复制 |
|
||||
| ABI 错误诊断 | Level 1 | 完整流程 |
|
||||
| 详细 SOP | Level 2 | 有触发条件 |
|
||||
| 内容 | 保留位置 | 判断依据 |
|
||||
|------|----------|----------|
|
||||
| 核心命令表 | Level 1 | 高频使用，不应让 LLM 每次去查 |
|
||||
| 懒加载代码模式 | Level 1 | 需要直接复制，移走会导致重新推导 |
|
||||
| ABI 错误诊断 | Level 1 | 完整症状→原因→修复流程 |
|
||||
| 详细 SOP | Level 2 | 低频、有明确触发条件 |
|
||||
|
||||
### 教训
|
||||
**行数不是目标，效能才是。**
|
||||
**信息效率、可读性、可维护性是标准，行数不是。**
|
||||
|
||||
---
|
||||
|
||||
@@ -143,10 +143,10 @@ LLM 注意力呈 U 型分布：开头和末尾强，中间弱。只放中间会
|
||||
## 案例 6：缺少信息记录原则
|
||||
|
||||
### 背景
|
||||
优化完成后，CLAUDE.md 从 2937 行精简到 524 行，结构清晰。
|
||||
优化完成后，CLAUDE.md 结构清晰，信息分层合理。
|
||||
|
||||
### 问题
|
||||
后续用户继续要求 Claude "把这个记录到 CLAUDE.md"，Claude 没有判断标准，只能照做。一个月后 CLAUDE.md 又膨胀回 1500+ 行。
|
||||
后续用户继续要求 Claude "把这个记录到 CLAUDE.md"，Claude 没有判断标准，只能照做。逐渐出现信息重复维护、低频内容和高频内容混杂的问题。
|
||||
|
||||
### 错误做法
|
||||
只优化内容，不添加规则。
|
||||
@@ -219,3 +219,28 @@ LLM 注意力呈 U 型分布：开头和末尾强，中间弱。只放中间会
|
||||
| 边缘情况处理 | | ✅ |
|
||||
| 历史决策记录 | | ✅ |
|
||||
| 性能数据 | | ✅ |
|
||||
|
||||
---
|
||||
|
||||
## 案例 7：用行数当 KPI
|
||||
|
||||
### 错误做法
|
||||
优化方案写"当前 2,114 行，目标 ~580 行，约 73% 精简"，用行数和百分比作为成功指标。
|
||||
|
||||
### 问题
|
||||
行数驱动的优化会导致错误决策：
|
||||
- 为了凑数字而砍掉有用的代码模式
|
||||
- 为了"减少百分比"而合并不相关的章节
|
||||
- 把"短"等同于"好"，把"长"等同于"差"
|
||||
|
||||
### 正确做法
|
||||
用信息架构质量作为评估维度：
|
||||
|
||||
| 评估维度 | 问题 |
|
||||
|----------|------|
|
||||
| **单一信息源** | 这段信息是否在别处已经有了？如果是，消除重复 |
|
||||
| **认知相关性** | 这段信息在大多数开发场景下是否需要？如果不是，移到 Level 2 |
|
||||
| **维护一致性** | 改一处是否需要同步另一处？如果是，消除重复 |
|
||||
|
||||
### 教训
|
||||
**行数少不代表更好，行数多不代表更差。真正的标准是信息效率、可读性、可维护性。**
|
||||
|
||||
Reference in New Issue
Block a user