Back to Details

compound-docs

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

compound-docs Skill

compound-docs 技能

Purpose: Automatically document solved problems to build searchable institutional knowledge with category-based organization (enum-validated problem types).
用途： 自动记录已解决的问题，构建基于分类组织（枚举验证的问题类型）的可搜索机构知识库。

Overview

概述

This skill captures problem solutions immediately after confirmation, creating structured documentation that serves as a searchable knowledge base for future sessions.
Organization: Single-file architecture - each problem documented as one markdown file in its symptom category directory (e.g., 
docs/solutions/performance-issues/n-plus-one-briefs.md
). Files use YAML frontmatter for metadata and searchability.
<critical_sequence name="documentation-capture" enforce_order="strict">
本技能会在问题解决确认后立即捕获解决方案，创建结构化文档，作为未来会话的可搜索知识库。
组织方式： 单文件架构 - 每个问题作为一个markdown文件记录在其症状分类目录中（例如：
docs/solutions/performance-issues/n-plus-one-briefs.md
）。文件使用YAML前置元数据来提供元信息，提升可搜索性。
<critical_sequence name="documentation-capture" enforce_order="strict">

7-Step Process

7步流程

<step number="1" required="true">
<step number="1" required="true">

Step 1: Detect Confirmation

步骤1：检测确认

Auto-invoke after phrases:
  • "that worked"
  • "it's fixed"
  • "working now"
  • "problem solved"
  • "that did it"
OR manual: 
/doc-fix
command
Non-trivial problems only:
  • Multiple investigation attempts needed
  • Tricky debugging that took time
  • Non-obvious solution
  • Future sessions would benefit
Skip documentation for:
  • Simple typos
  • Obvious syntax errors
  • Trivial fixes immediately corrected </step>
<step number="2" required="true" depends_on="1">
自动触发短语：
  • “这样可行”
  • “问题修复了”
  • “现在正常了”
  • “问题解决了”
  • “成功了”
或手动触发： 
/doc-fix
命令
仅处理非简单问题：
  • 需要多次尝试排查
  • 耗时的复杂调试
  • 非显而易见的解决方案
  • 对未来会话有帮助
跳过文档记录的情况：
  • 简单拼写错误
  • 明显的语法错误
  • 立即修正的微小问题 </step>
<step number="2" required="true" depends_on="1">

Step 2: Gather Context

步骤2：收集上下文

Extract from conversation history:
Required information:
  • Module name: Which module or component had the problem
  • Symptom: Observable error/behavior (exact error messages)
  • Investigation attempts: What didn't work and why
  • Root cause: Technical explanation of actual problem
  • Solution: What fixed it (code/config changes)
  • Prevention: How to avoid in future
Environment details:
  • Rails version
  • Stage (0-6 or post-implementation)
  • OS version
  • File/line references
BLOCKING REQUIREMENT: If critical context is missing (module name, exact error, stage, or resolution steps), ask user and WAIT for response before proceeding to Step 3:
I need a few details to document this properly:

1. Which module had this issue? [ModuleName]
2. What was the exact error message or symptom?
3. What stage were you in? (0-6 or post-implementation)

[Continue after user provides details]
</step> <step number="3" required="false" depends_on="2">
从对话历史中提取：
必填信息：
  • 模块名称：出现问题的模块或组件
  • 症状：可观察到的错误/行为（精确的错误信息）
  • 排查尝试：哪些方法无效及原因
  • 根本原因：问题的技术解释
  • 解决方案：修复方法（代码/配置变更）
  • 预防措施：未来如何避免
环境细节：
  • Rails 版本
  • 阶段（0-6 或实施后）
  • 操作系统版本
  • 文件/行引用
阻塞要求： 如果缺少关键上下文（模块名称、精确错误、阶段或解决步骤），询问用户并等待回复后再进入步骤3：
我需要一些细节来正确记录这个问题：

1. 哪个模块出现了这个问题？[模块名称]
2. 精确的错误信息或症状是什么？
3. 当时处于哪个阶段？（0-6 或实施后）

[用户提供详情后继续]
</step> <step number="3" required="false" depends_on="2">

Step 3: Check Existing Docs

步骤3：检查现有文档

Search docs/solutions/ for similar issues:
bash
undefined
在docs/solutions/中搜索类似问题：
bash
undefined

Search by error message keywords

按错误信息关键词搜索

grep -r "exact error phrase" docs/solutions/
grep -r "exact error phrase" docs/solutions/

Search by symptom category

按症状分类搜索

ls docs/solutions/[category]/

**IF similar issue found:**

THEN present decision options:
Found similar issue: docs/solutions/[path]
What's next?
  1. Create new doc with cross-reference (recommended)
  2. Update existing doc (only if same root cause)
  3. Other
Choose (1-3): _

WAIT for user response, then execute chosen action.

**ELSE** (no similar issue found):

Proceed directly to Step 4 (no user interaction needed).
</step>

<step number="4" required="true" depends_on="2">
ls docs/solutions/[category]/

**如果找到类似问题：**

则提供决策选项：
找到类似问题：docs/solutions/[path]
下一步操作？
  1. 创建新文档并添加交叉引用（推荐）
  2. 更新现有文档（仅当根本原因相同时）
  3. 其他
请选择（1-3）：_

等待用户回复，然后执行所选操作。

**如果未找到类似问题：**

直接进入步骤4（无需用户交互）。
</step>

<step number="4" required="true" depends_on="2">

Step 4: Generate Filename

步骤4：生成文件名

Format: 
[sanitized-symptom]-[module]-[YYYYMMDD].md
Sanitization rules:
  • Lowercase
  • Replace spaces with hyphens
  • Remove special characters except hyphens
  • Truncate to reasonable length (< 80 chars)
Examples:
  • missing-include-BriefSystem-20251110.md
  • parameter-not-saving-state-EmailProcessing-20251110.md
  • webview-crash-on-resize-Assistant-20251110.md
    </step>
<step number="5" required="true" depends_on="4" blocking="true">
格式：
[sanitized-symptom]-[module]-[YYYYMMDD].md
清理规则：
  • 小写
  • 用连字符替换空格
  • 移除连字符以外的特殊字符
  • 截断至合理长度（<80字符）
示例：
  • missing-include-BriefSystem-20251110.md
  • parameter-not-saving-state-EmailProcessing-20251110.md
  • webview-crash-on-resize-Assistant-20251110.md
    </step>
<step number="5" required="true" depends_on="4" blocking="true">

Step 5: Validate YAML Schema

步骤5：验证YAML Schema

CRITICAL: All docs require validated YAML frontmatter with enum validation.
<validation_gate name="yaml-schema" blocking="true">
Validate against schema: Load 
schema.yaml
and classify the problem against the enum values defined in yaml-schema.md. Ensure all required fields are present and match allowed values exactly.
BLOCK if validation fails:
❌ YAML validation failed

Errors:
- problem_type: must be one of schema enums, got "compilation_error"
- severity: must be one of [critical, high, medium, low], got "invalid"
- symptoms: must be array with 1-5 items, got string

Please provide corrected values.
GATE ENFORCEMENT: Do NOT proceed to Step 6 (Create Documentation) until YAML frontmatter passes all validation rules defined in 
schema.yaml
.
</validation_gate> </step>
<step number="6" required="true" depends_on="5">
关键要求： 所有文档都需要经过枚举验证的YAML前置元数据。
<validation_gate name="yaml-schema" blocking="true">
根据Schema验证： 加载
schema.yaml
，并根据yaml-schema.md中定义的枚举值对问题进行分类。确保所有必填字段都存在，且完全匹配允许的值。
验证失败则阻塞：
❌ YAML验证失败

错误：
- problem_type: 必须是Schema枚举值之一，得到 "compilation_error"
- severity: 必须是 [critical, high, medium, low] 之一，得到 "invalid"
- symptoms: 必须是包含1-5项的数组，得到字符串

请提供修正后的值。
验证门强制要求： 在YAML前置元数据通过
schema.yaml
定义的所有验证规则之前，不得进入步骤6（创建文档）。
</validation_gate> </step>
<step number="6" required="true" depends_on="5">

Step 6: Create Documentation

步骤6：创建文档

Determine category from problem_type: Use the category mapping defined in yaml-schema.md (lines 49-61).
Create documentation file:
bash
PROBLEM_TYPE="[from validated YAML]"
CATEGORY="[mapped from problem_type]"
FILENAME="[generated-filename].md"
DOC_PATH="docs/solutions/${CATEGORY}/${FILENAME}"
根据problem_type确定分类： 使用yaml-schema.md（第49-61行）中定义的分类映射。
创建文档文件：
bash
PROBLEM_TYPE="[来自已验证的YAML]"
CATEGORY="[从problem_type映射得到]"
FILENAME="[生成的文件名].md"
DOC_PATH="docs/solutions/${CATEGORY}/${FILENAME}"

Create directory if needed

按需创建目录

mkdir -p "docs/solutions/${CATEGORY}"
mkdir -p "docs/solutions/${CATEGORY}"

Write documentation using template from assets/resolution-template.md

使用assets/resolution-template.md中的模板编写文档

(Content populated with Step 2 context and validated YAML frontmatter)

（内容填充步骤2的上下文和已验证的YAML前置元数据）


**Result:**
- Single file in category directory
- Enum validation ensures consistent categorization

**Create documentation:** Populate the structure from `assets/resolution-template.md` with context gathered in Step 2 and validated YAML frontmatter from Step 5.
</step>

<step number="7" required="false" depends_on="6">

**结果：**
- 分类目录中的单个文件
- 枚举验证确保分类一致性

**创建文档：** 使用步骤2收集的上下文和步骤5中已验证的YAML前置元数据，填充`assets/resolution-template.md`的结构。
</step>

<step number="7" required="false" depends_on="6">

Step 7: Cross-Reference & Critical Pattern Detection

步骤7：交叉引用与关键模式检测

If similar issues found in Step 3:
Update existing doc:
bash
undefined
如果在步骤3中找到类似问题：
更新现有文档：
bash
undefined

Add Related Issues link to similar doc

向类似文档添加相关问题链接

echo "- See also: $FILENAME" >> [similar-doc.md]

**Update new doc:**
Already includes cross-reference from Step 6.

**Update patterns if applicable:**

If this represents a common pattern (3+ similar issues):

```bash
echo "- 另请参阅: $FILENAME" >> [similar-doc.md]

**更新新文档：**
已在步骤6中包含交叉引用。

**适用时更新模式：**

如果这代表一个常见模式（3个及以上类似问题）：

```bash

Add to docs/solutions/patterns/common-solutions.md

添加到docs/solutions/patterns/common-solutions.md

cat >> docs/solutions/patterns/common-solutions.md << 'EOF'
cat >> docs/solutions/patterns/common-solutions.md << 'EOF'

[Pattern Name]

[模式名称]

Common symptom: [Description] Root cause: [Technical explanation] Solution pattern: [General approach]
Examples:
  • [Link to doc 1]
  • [Link to doc 2]
  • [Link to doc 3] EOF

**Critical Pattern Detection (Optional Proactive Suggestion):**

If this issue has automatic indicators suggesting it might be critical:
- Severity: `critical` in YAML
- Affects multiple modules OR foundational stage (Stage 2 or 3)
- Non-obvious solution

Then in the decision menu (Step 8), add a note:
💡 This might be worth adding to Required Reading (Option 2)

But **NEVER auto-promote**. User decides via decision menu (Option 2).

**Template for critical pattern addition:**

When user selects Option 2 (Add to Required Reading), use the template from `assets/critical-pattern-template.md` to structure the pattern entry. Number it sequentially based on existing patterns in `docs/solutions/patterns/critical-patterns.md`.
</step>

</critical_sequence>

---

<decision_gate name="post-documentation" wait_for_user="true">
常见症状： [描述] 根本原因： [技术解释] 解决方案模式： [通用方法]
示例：
  • [文档1链接]
  • [文档2链接]
  • [文档3链接] EOF

**关键模式检测（可选主动建议）：**

如果该问题有自动指标表明可能是关键问题：
- YAML中的严重性为`critical`
- 影响多个模块或基础阶段（阶段2或3）
- 非显而易见的解决方案

则在步骤8的决策菜单中添加提示：
💡 此问题可能值得添加到必读内容中（选项2）

但**绝不能自动升级**。用户通过决策菜单（选项2）决定。

**关键模式添加模板：**

当用户选择选项2（添加到必读内容）时，使用`assets/critical-pattern-template.md`中的模板构建模式条目。根据`docs/solutions/patterns/critical-patterns.md`中的现有模式按顺序编号。
</step>

</critical_sequence>

---

<decision_gate name="post-documentation" wait_for_user="true">

Decision Menu After Capture

捕获完成后的决策菜单

After successful documentation, present options and WAIT for user response:
✓ Solution documented

File created:
- docs/solutions/[category]/[filename].md

What's next?
1. Continue workflow (recommended)
2. Add to Required Reading - Promote to critical patterns (critical-patterns.md)
3. Link related issues - Connect to similar problems
4. Add to existing skill - Add to a learning skill (e.g., hotwire-native)
5. Create new skill - Extract into new learning skill
6. View documentation - See what was captured
7. Other
Handle responses:
Option 1: Continue workflow
  • Return to calling skill/workflow
  • Documentation is complete
Option 2: Add to Required Reading ⭐ PRIMARY PATH FOR CRITICAL PATTERNS
User selects this when:
  • System made this mistake multiple times across different modules
  • Solution is non-obvious but must be followed every time
  • Foundational requirement (Rails, Rails API, threading, etc.)
Action:
  1. Extract pattern from the documentation
  2. Format as ❌ WRONG vs ✅ CORRECT with code examples
  3. Add to 
    docs/solutions/patterns/critical-patterns.md
  4. Add cross-reference back to this doc
  5. Confirm: "✓ Added to Required Reading. All subagents will see this pattern before code generation."
Option 3: Link related issues
  • Prompt: "Which doc to link? (provide filename or describe)"
  • Search docs/solutions/ for the doc
  • Add cross-reference to both docs
  • Confirm: "✓ Cross-reference added"
Option 4: Add to existing skill
User selects this when the documented solution relates to an existing learning skill:
Action:
  1. Prompt: "Which skill? (hotwire-native, etc.)"
  2. Determine which reference file to update (resources.md, patterns.md, or examples.md)
  3. Add link and brief description to appropriate section
  4. Confirm: "✓ Added to [skill-name] skill in [file]"
Example: For Hotwire Native Tailwind variants solution:
  • Add to 
    hotwire-native/references/resources.md
    under "Project-Specific Resources"
  • Add to 
    hotwire-native/references/examples.md
    with link to solution doc
Option 5: Create new skill
User selects this when the solution represents the start of a new learning domain:
Action:
  1. Prompt: "What should the new skill be called? (e.g., stripe-billing, email-processing)"
  2. Run 
    python3 .claude/skills/skill-creator/scripts/init_skill.py [skill-name]
  3. Create initial reference files with this solution as first example
  4. Confirm: "✓ Created new [skill-name] skill with this solution as first example"
Option 6: View documentation
  • Display the created documentation
  • Present decision menu again
Option 7: Other
  • Ask what they'd like to do
</decision_gate>
<integration_protocol>
文档创建成功后，提供选项并等待用户回复：
✓ 解决方案已记录

已创建文件：
- docs/solutions/[category]/[filename].md

下一步操作？
1. 继续工作流（推荐）
2. 添加到必读内容 - 升级为关键模式（critical-patterns.md）
3. 关联相关问题 - 连接到类似问题
4. 添加到现有技能 - 添加到学习技能（例如hotwire-native）
5. 创建新技能 - 提取为新的学习技能
6. 查看文档 - 查看已捕获的内容
7. 其他
响应处理：
选项1：继续工作流
  • 返回调用的技能/工作流
  • 文档记录完成
选项2：添加到必读内容 ⭐ 关键模式的主要路径
用户选择此选项的场景：
  • 系统在不同模块中多次犯此错误
  • 解决方案非显而易见但必须每次遵循
  • 基础要求（Rails、Rails API、线程等）
操作：
  1. 从文档中提取模式
  2. 格式化为❌ 错误 vs ✅ 正确，并附带代码示例
  3. 添加到
    docs/solutions/patterns/critical-patterns.md
  4. 添加指向此文档的交叉引用
  5. 确认："✓ 已添加到必读内容。所有子代理在生成代码前都会看到此模式。"
选项3：关联相关问题
  • 提示："要关联哪个文档？（提供文件名或描述）"
  • 在docs/solutions/中搜索该文档
  • 向两个文档添加交叉引用
  • 确认："✓ 已添加交叉引用"
选项4：添加到现有技能
用户选择此选项的场景：已记录的解决方案与现有学习技能相关
操作：
  1. 提示："哪个技能？（例如hotwire-native）"
  2. 确定要更新的参考文件（resources.md、patterns.md或examples.md）
  3. 向相应部分添加链接和简短描述
  4. 确认："✓ 已添加到[技能名称]技能的[文件]中"
示例：对于Hotwire Native Tailwind变体解决方案：
  • 添加到
    hotwire-native/references/resources.md
    的“项目特定资源”下
  • 添加到
    hotwire-native/references/examples.md
    并附带解决方案文档链接
选项5：创建新技能
用户选择此选项的场景：解决方案代表新学习领域的开端
操作：
  1. 提示："新技能的名称是什么？（例如stripe-billing、email-processing）"
  2. 运行
    python3 .claude/skills/skill-creator/scripts/init_skill.py [skill-name]
  3. 创建初始参考文件，并将此解决方案作为第一个示例
  4. 确认："✓ 已创建新的[技能名称]技能，此解决方案为第一个示例"
选项6：查看文档
  • 显示已创建的文档
  • 再次呈现决策菜单
选项7：其他
  • 询问用户想要执行的操作
</decision_gate>
<integration_protocol>

Integration Points

集成点

Invoked by:
  • /compound command (primary interface)
  • Manual invocation in conversation after solution confirmed
  • Can be triggered by detecting confirmation phrases like "that worked", "it's fixed", etc.
Invokes:
  • None (terminal skill - does not delegate to other skills)
Handoff expectations: All context needed for documentation should be present in conversation history before invocation.
</integration_protocol>
<success_criteria>
调用者：
  • /compound 命令（主要接口）
  • 解决方案确认后在对话中手动调用
  • 可通过检测确认短语触发，如“that worked”、“it's fixed”等
调用对象：
  • 无（终端技能 - 不委托给其他技能）
交接期望： 调用前，对话历史中应包含文档所需的所有上下文。
</integration_protocol>
<success_criteria>

Success Criteria

成功标准

Documentation is successful when ALL of the following are true:
  • ✅ YAML frontmatter validated (all required fields, correct formats)
  • ✅ File created in docs/solutions/[category]/[filename].md
  • ✅ Enum values match schema.yaml exactly
  • ✅ Code examples included in solution section
  • ✅ Cross-references added if related issues found
  • ✅ User presented with decision menu and action confirmed
</success_criteria>
当满足以下所有条件时，文档记录成功：
  • ✅ YAML前置元数据已验证（所有必填字段、格式正确）
  • ✅ 文件已创建在docs/solutions/[category]/[filename].md
  • ✅ 枚举值与schema.yaml完全匹配
  • ✅ 解决方案部分包含代码示例
  • ✅ 若找到相关问题则已添加交叉引用
  • ✅ 已向用户展示决策菜单并确认操作
</success_criteria>

Error Handling

错误处理

Missing context:
  • Ask user for missing details
  • Don't proceed until critical info provided
YAML validation failure:
  • Show specific errors
  • Present retry with corrected values
  • BLOCK until valid
Similar issue ambiguity:
  • Present multiple matches
  • Let user choose: new doc, update existing, or link as duplicate
Module not in modules documentation:
  • Warn but don't block
  • Proceed with documentation
  • Suggest: "Add [Module] to modules documentation if not there"
上下文缺失：
  • 询问用户获取缺失的细节
  • 提供关键信息前不得继续
YAML验证失败：
  • 显示具体错误
  • 提示用户重试并提供修正后的值
  • 阻塞直到验证通过
类似问题歧义：
  • 展示多个匹配结果
  • 让用户选择：创建新文档、更新现有文档或标记为重复链接
模块未在模块文档中：
  • 发出警告但不阻塞
  • 继续记录文档
  • 建议：“如果[模块]未在模块文档中，请添加进去”

Execution Guidelines

执行指南

MUST do:
  • Validate YAML frontmatter (BLOCK if invalid per Step 5 validation gate)
  • Extract exact error messages from conversation
  • Include code examples in solution section
  • Create directories before writing files (
    mkdir -p
    )
  • Ask user and WAIT if critical context missing
MUST NOT do:
  • Skip YAML validation (validation gate is blocking)
  • Use vague descriptions (not searchable)
  • Omit code examples or cross-references
必须执行：
  • 验证YAML前置元数据（步骤5的验证门为阻塞型）
  • 从对话中提取精确的错误信息
  • 在解决方案部分包含代码示例
  • 写入文件前创建目录（使用
    mkdir -p
    ）
  • 若关键上下文缺失，询问用户并等待
禁止执行：
  • 跳过YAML验证（验证门为阻塞型）
  • 使用模糊描述（不可搜索）
  • 省略代码示例或交叉引用

Quality Guidelines

质量指南

Good documentation has:
  • ✅ Exact error messages (copy-paste from output)
  • ✅ Specific file:line references
  • ✅ Observable symptoms (what you saw, not interpretations)
  • ✅ Failed attempts documented (helps avoid wrong paths)
  • ✅ Technical explanation (not just "what" but "why")
  • ✅ Code examples (before/after if applicable)
  • ✅ Prevention guidance (how to catch early)
  • ✅ Cross-references (related issues)
Avoid:
  • ❌ Vague descriptions ("something was wrong")
  • ❌ Missing technical details ("fixed the code")
  • ❌ No context (which version? which file?)
  • ❌ Just code dumps (explain why it works)
  • ❌ No prevention guidance
  • ❌ No cross-references
优质文档具备：
  • ✅ 精确的错误信息（从输出中复制粘贴）
  • ✅ 具体的文件:行引用
  • ✅ 可观察的症状（实际看到的内容，而非解读）
  • ✅ 记录失败的尝试（有助于避免错误路径）
  • ✅ 技术解释（不仅说明“是什么”，还要说明“为什么”）
  • ✅ 代码示例（适用时包含前后对比）
  • ✅ 预防指导（如何提前发现）
  • ✅ 交叉引用（相关问题）
需避免：
  • ❌ 模糊描述（“出了点问题”）
  • ❌ 缺少技术细节（“修复了代码”）
  • ❌ 无上下文（哪个版本？哪个文件？）
  • ❌ 仅代码片段（解释其工作原理）
  • ❌ 无预防指导
  • ❌ 无交叉引用

Example Scenario

示例场景

User: "That worked! The N+1 query is fixed."
Skill activates:
  1. Detect confirmation: "That worked!" triggers auto-invoke
  2. Gather context:
    • Module: Brief System
    • Symptom: Brief generation taking >5 seconds, N+1 query when loading email threads
    • Failed attempts: Added pagination (didn't help), checked background job performance
    • Solution: Added eager loading with 
      includes(:emails)
      on Brief model
    • Root cause: Missing eager loading causing separate database query per email thread
  3. Check existing: No similar issue found
  4. Generate filename: 
    n-plus-one-brief-generation-BriefSystem-20251110.md
  5. Validate YAML:
    yaml
    module: Brief System
date: 2025-11-10
problem_type: performance_issue
component: rails_model
symptoms:
  - "N+1 query when loading email threads"
  - "Brief generation taking >5 seconds"
root_cause: missing_include
severity: high
tags: [n-plus-one, eager-loading, performance]
    ✅ Valid
  6. Create documentation: 
    • docs/solutions/performance-issues/n-plus-one-brief-generation-BriefSystem-20251110.md
  7. Cross-reference: None needed (no similar issues)
Output:
✓ Solution documented

File created:
- docs/solutions/performance-issues/n-plus-one-brief-generation-BriefSystem-20251110.md

What's next?
1. Continue workflow (recommended)
2. Add to Required Reading - Promote to critical patterns (critical-patterns.md)
3. Link related issues - Connect to similar problems
4. Add to existing skill - Add to a learning skill (e.g., hotwire-native)
5. Create new skill - Extract into new learning skill
6. View documentation - See what was captured
7. Other
用户： “这样可行！N+1查询问题修复了。”
技能激活：
  1. 检测确认： “这样可行！”触发自动调用
  2. 收集上下文：
    • 模块：Brief System
    • 症状：Brief生成耗时超过5秒，加载邮件线程时出现N+1查询
    • 失败尝试：添加分页（无效），检查后台作业性能
    • 解决方案：在Brief模型中添加
      includes(:emails)
      预加载
    • 根本原因：缺少预加载导致每个邮件线程触发单独的数据库查询
  3. 检查现有文档： 未找到类似问题
  4. 生成文件名： 
    n-plus-one-brief-generation-BriefSystem-20251110.md
  5. 验证YAML：
    yaml
    module: Brief System
date: 2025-11-10
problem_type: performance_issue
component: rails_model
symptoms:
  - "N+1 query when loading email threads"
  - "Brief generation taking >5 seconds"
root_cause: missing_include
severity: high
tags: [n-plus-one, eager-loading, performance]
    ✅ 验证通过
  6. 创建文档： 
    • docs/solutions/performance-issues/n-plus-one-brief-generation-BriefSystem-20251110.md
  7. 交叉引用： 无需（无类似问题）
输出：
✓ 解决方案已记录

已创建文件：
- docs/solutions/performance-issues/n-plus-one-brief-generation-BriefSystem-20251110.md

下一步操作？
1. 继续工作流（推荐）
2. 添加到必读内容 - 升级为关键模式（critical-patterns.md）
3. 关联相关问题 - 连接到类似问题
4. 添加到现有技能 - 添加到学习技能（例如hotwire-native）
5. 创建新技能 - 提取为新的学习技能
6. 查看文档 - 查看已捕获的内容
7. 其他

Future Enhancements

未来增强

Not in Phase 7 scope, but potential:
  • Search by date range
  • Filter by severity
  • Tag-based search interface
  • Metrics (most common issues, resolution time)
  • Export to shareable format (community knowledge sharing)
  • Import community solutions
不在第7阶段范围内，但有潜力的功能：
  • 按日期范围搜索
  • 按严重性筛选
  • 基于标签的搜索界面
  • 指标（最常见问题、解决时间）
  • 导出为可分享格式（社区知识共享）
  • 导入社区解决方案