Compound 🧠 是一个面向迭代式智能体循环的技能，用于高效管理项目知识与设计系统。它的目标是：快速检索上下文、在不造成膨胀的前提下存储学习成果，并跨页面维护一致的 UI。
用途
Compound 适用于智能体在迭代开发中需要反复读取和沉淀项目知识的场景。它解决两个问题：一是每次迭代开始时快速获取与当前任务相关的项目背景，避免重复查找和 token 浪费；二是把代码无法表达的决策理由、易错点、外部 API 特性等知识持久化下来，同时控制文档体积、避免重复。此外，它还管理设计系统，确保新建 UI 时沿用已有设计令牌与模式，保持页面间一致性。
主要能力
命令一览
| 命令 | 何时使用 | 目的 |
|---|---|---|
| compound retrieve | 迭代开始 | 查找与当前任务相关的知识 |
| compound store | 迭代结束 | 持久化代码未捕捉的学习成果 |
| compound design retrieve | 构建 UI 之前 | 加载设计系统令牌与模式 |
| compound design store | 做出 UI 决策之后 | 持久化设计令牌、模式、组件 |
| compound design sync | 跨页面工作 | 确保与既有 UI 一致 |
Compound Retrieve
目标：在 30 秒内以最少的 token 浪费获取相关上下文。
步骤：
- 索引扫描：列出所有知识文件，例如
find docs -name "*.md" -type f 2>/dev/null | head -50。 - 关键词提取：从当前任务中提取 3-5 个关键词，包括实体名（User、Auth、API）、技术术语（JWT、WebSocket、migration）、领域概念（billing、notifications）。
- 定向 Grep：在文档中并行搜索关键词，例如
grep -ril "keyword1\|keyword2\|keyword3" docs/ | head -10。 - 智能阅读：小于 100 行的文件全文阅读；大文件只读匹配段落（
grep -B2 -A5）；索引文件（README、index.md）略读以获取指针。 - 相关性过滤：只加载直接适用的知识。例如“JWT refresh tokens expire after 7 days”对 auth 任务有用，而“我们选了 React 而不是 Vue”与 auth 无关。
输出：一份可直接应用的相关项目上下文心智模型。
Compound Store
目标：持久化有价值的学习成果，且不产生重复或膨胀。
步骤：
- 识别可存储的知识：只存储代码注释无法捕捉的内容。可存储的包括：为什么选 X 而不是 Y（决策理由）、实现中发现的非显而易见陷阱、跨组件关系、外部 API 怪癖/速率限制/未文档化行为。不应存储：代码做了什么、如何运行命令（应放在 README 或 AGENTS.md）。
- 重复检查（关键）：写入任何内容前先搜索已有覆盖，例如
grep -ril "topic keyword" docs/和find docs -name "*keyword*" -type f。若找到，则读取已有文件并更新，把新信息合并到已有章节，更新 frontmatter 中的updated日期。 - 选择位置：架构决策放
docs/arch/；为什么选 X 而非 Y 放docs/decisions/；陷阱与边界放docs/gotchas/；可复用模式放docs/patterns/；外部 API 笔记放docs/integrations/；设计系统放docs/design/。 - 文件格式：包含 frontmatter（tags、updated、related），正文含 Clear Descriptive Title、Context、Key Points、Examples（如适用）、See Also。
- 体积管理：单文件目标 50-150 行，最大 200 行（超出则拆分）；每个文件聚焦一个主题。定期检查文件数，目标保持少于 50 个；若超过，则合并相关小文件、归档过时知识到
docs/_archive/、合并重叠内容。
Compound Design
目标：通过跟踪设计令牌、模式和组件决策，维护跨页面一致的 UI。
设计系统全部位于 docs/design/：
| 文件 | 用途 | 示例内容 |
|---|---|---|
| docs/design/tokens.md | 设计令牌 | 颜色、间距、排版、阴影、断点 |
| docs/design/components.md | 组件模式 | 按钮变体、卡片样式、表单输入 |
| docs/design/layout.md | 布局约定 | 网格系统、页面结构、响应式行为 |
| docs/design/motion.md | 动画与过渡 | 时长、缓动曲线、动画模式 |
| docs/design/decisions.md | 设计理由 | 为什么用 X 字体、为什么用 Y 配色 |
Compound Design Retrieve
在构建任何 UI 组件之前：检查 docs/design/ 是否存在；总是先加载 tokens.md；若构建组件则加载 components.md；若构建页面则加载 layout.md。若没有设计系统，运行 mise-en-place 第二阶段，或在首次 UI 工作中创建；未确立令牌前不要继续 UI 工作。
Compound Design Store
做出 UI 决策后持久化到 docs/design/。先检查已有设计系统，若存在则更新相关文件，否则创建结构。然后把令牌存入 tokens.md（含颜色、排版、间距、圆角、阴影、断点表格），把组件模式存入 components.md（按钮、卡片、表单、导航），把布局模式存入 layout.md（容器、页面布局、网格）。
Compound Design Sync
在既有项目的新页面工作时：先加载设计系统（cat docs/design/tokens.md docs/design/components.md docs/design/layout.md 2>/dev/null）；写 UI 前验证一致性，使用 tokens.md 中的准确令牌名（如 var(--color-primary)），遵循 components.md 的组件模式，匹配 layout.md 的布局约定；若扩展系统则更新对应文件；绝不创建一次性值——扩展系统或复用已有值。
设计系统反模式
- 硬编码值而非令牌，例如写
color: #3b82f6; padding: 16px;而非color: var(--color-primary); padding: var(--space-md);。 - 创建不一致的组件变体，各页面按钮样式不同。
- 忽略既有设计系统，未检查就开始编码。
- 把设计令牌写在代码注释里而非集中到
docs/design/tokens.md。 - 在系统之外创建令牌，如一次性值
padding: 18px; color: #4a7c59;。
通用反模式
- 创建近似重复文件，例如
auth-issues.md与authentication-problems.md。 - 存储显而易见的信息，如“如何启动服务器”应放在 README/AGENTS.md。
- 巨大的单体文件，如 500 行的
knowledge.md。 - 模糊文件名，如
notes.md、stuff.md、misc.md。 - 忘记更新已有文件，而是新建如
jwt-issue-2.md。
使用方式
按迭代节奏使用：迭代开始时运行 compound retrieve 获取相关上下文；迭代结束时运行 compound store 沉淀学习成果。构建 UI 前运行 compound design retrieve，做出 UI 决策后运行 compound design store，跨页面工作时运行 compound design sync。知识统一存放在 docs/ 下，设计系统统一存放在 docs/design/ 下。每个文件聚焦一个主题，优先更新已有文件而非新建。
适用场景
- 迭代式智能体开发循环中需要反复读取和写入项目知识。
- 需要沉淀决策理由、易错点、外部 API 特性等代码外知识。
- 多页面项目中需要维护设计令牌、组件与布局一致性。
- 希望控制知识库规模、避免重复文件与文档膨胀的团队。
限制
资料未提供该技能的具体安装要求、支持的平台或运行环境信息。资料未提供收费、价格相关信息。资料未提供关于 mise-en-place 的详细说明（仅在文档中提及作为创建设计系统的备选路径）。资料未提供除文档中列出的命令与文件结构之外的其他功能说明。