@gabrywu/knowledge-bank 0.1.2-alpha.252 → 0.1.2-alpha.276
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/claude-marketplace/.claude-plugin/marketplace.json +2 -2
- package/dist/claude-marketplace/core/.claude-plugin/plugin.json +1 -1
- package/dist/claude-marketplace/core/skills/KNOWLEDGE-DEFINITION.zh.md +79 -0
- package/dist/claude-marketplace/core/skills/knowledge.add/{skill.md → SKILL.md} +8 -10
- package/dist/claude-marketplace/core/skills/knowledge.add/skill.zh.md +47 -0
- package/dist/claude-marketplace/core/skills/knowledge.collect/SKILL.md +53 -14
- package/dist/claude-marketplace/core/skills/knowledge.collect/SKILL.zh.md +185 -0
- package/dist/claude-marketplace/core/skills/knowledge.delete/skill.zh.md +22 -0
- package/dist/claude-marketplace/core/skills/knowledge.detect/SKILL.md +115 -0
- package/dist/claude-marketplace/core/skills/knowledge.detect/skill.zh.md +117 -0
- package/dist/claude-marketplace/core/skills/knowledge.enhance/SKILL.md +55 -34
- package/dist/claude-marketplace/core/skills/knowledge.enhance/SKILL.zh.md +157 -0
- package/dist/claude-marketplace/core/skills/knowledge.import/{skill.md → SKILL.md} +9 -8
- package/dist/claude-marketplace/core/skills/knowledge.import/skill.zh.md +35 -0
- package/dist/claude-marketplace/core/skills/knowledge.init/{skill.md → SKILL.md} +8 -7
- package/dist/claude-marketplace/core/skills/knowledge.init/skill.zh.md +38 -0
- package/dist/claude-marketplace/core/skills/knowledge.save/SKILL.md +82 -0
- package/dist/claude-marketplace/core/skills/knowledge.save/skill.zh.md +82 -0
- package/dist/claude-marketplace/core/skills/knowledge.status/skill.zh.md +19 -0
- package/dist/claude-marketplace/core/skills/knowledge.update/SKILL.md +77 -0
- package/dist/claude-marketplace/core/skills/knowledge.update/skill.zh.md +77 -0
- package/dist/cli.js +2 -2
- package/dist/mcp-server.js +1 -1
- package/dist/web/public/css/style.css +243 -41
- package/dist/web/public/js/main.js +264 -31
- package/dist/web/views/layout.ejs +9 -5
- package/dist/web/views/partials/row-details.ejs +32 -1
- package/dist/web/views/table.ejs +154 -6
- package/package.json +3 -4
- package/dist/claude-marketplace/core/skills/knowledge.save/skill.md +0 -39
- package/dist/claude-marketplace/core/skills/knowledge.update/skill.md +0 -34
- /package/dist/claude-marketplace/core/skills/knowledge.delete/{skill.md → SKILL.md} +0 -0
- /package/dist/claude-marketplace/core/skills/knowledge.status/{skill.md → SKILL.md} +0 -0
|
@@ -9,7 +9,7 @@
|
|
|
9
9
|
"name": "core",
|
|
10
10
|
"source": "./core",
|
|
11
11
|
"description": "Core plugins for knowledge bank",
|
|
12
|
-
"version": "0.1.2-alpha.
|
|
12
|
+
"version": "0.1.2-alpha.276",
|
|
13
13
|
"author": {
|
|
14
14
|
"name": "garbywu",
|
|
15
15
|
"email": "gabrywu@apache.org"
|
|
@@ -18,6 +18,6 @@
|
|
|
18
18
|
],
|
|
19
19
|
"metadata": {
|
|
20
20
|
"description": "A marketplace for knowledge bank plugins by gabrywu",
|
|
21
|
-
"version": "0.1.2-alpha.
|
|
21
|
+
"version": "0.1.2-alpha.276"
|
|
22
22
|
}
|
|
23
23
|
}
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
# 知识定义和收集标准
|
|
2
|
+
|
|
3
|
+
本文档定义了什么构成知识库中的"知识",并概述了检测和收集的标准。
|
|
4
|
+
|
|
5
|
+
## 知识定义
|
|
6
|
+
|
|
7
|
+
知识代表**可操作的技术洞察**,能显著提升代码库理解和开发效率。
|
|
8
|
+
|
|
9
|
+
### 核心知识要素
|
|
10
|
+
|
|
11
|
+
每个知识项目必须包含这些基本要素:
|
|
12
|
+
|
|
13
|
+
1. **什么** - 核心洞察、模式或解决方案
|
|
14
|
+
2. **在哪** - 具体文件位置、行号或系统组件
|
|
15
|
+
3. **为什么** - 理由、上下文或要解决的问题
|
|
16
|
+
4. **如何** - 实现方法、使用示例或过程步骤
|
|
17
|
+
|
|
18
|
+
### 知识资格标准
|
|
19
|
+
|
|
20
|
+
知识必须满足以下所有要求:
|
|
21
|
+
- **相关性**:与这个项目的具体文件/模式相关,或适用于个人开发原则
|
|
22
|
+
- **价值性**:为未来的开发工作节省大量时间/精力
|
|
23
|
+
- **非显而易见性**:不能仅仅通过阅读代码就能立即看出来
|
|
24
|
+
- **可操作性**:为开发人员提供明确的指导
|
|
25
|
+
|
|
26
|
+
## 知识范围
|
|
27
|
+
|
|
28
|
+
知识项目根据其适用性进行范围划分:
|
|
29
|
+
|
|
30
|
+
- **项目范围** (`project`):特定于当前代码库、其架构、独特模式和项目特定配置的知识。
|
|
31
|
+
- **个人范围** (`personal`):包括以下知识:
|
|
32
|
+
- **通用/普遍性**:广泛的技术洞察或最佳实践。
|
|
33
|
+
- **个人偏好**:个人开发风格、编码原则或偏爱的模式。
|
|
34
|
+
- **跨项目**:可在不同项目中重用的逻辑或工作流程。
|
|
35
|
+
- **哲学性**:高级开发原则和决策制定框架。
|
|
36
|
+
|
|
37
|
+
## 知识类别
|
|
38
|
+
|
|
39
|
+
知识项目分为以下类别:
|
|
40
|
+
|
|
41
|
+
1. **架构** (`architecture`) - 系统设计、组件结构、架构模式
|
|
42
|
+
2. **代码模式** (`code_pattern`) - 在整个代码库中使用的可重用模式和约定
|
|
43
|
+
3. **问题解决** (`pitfall`) - 调试过程、根本原因和解决策略
|
|
44
|
+
4. **工具使用** (`tool_usage`) - 项目特定配置、命令和工作流程
|
|
45
|
+
5. **领域知识** (`api_usage`) - 业务逻辑和特定领域理解
|
|
46
|
+
6. **探索** (`exploration`) - 代码库结构、依赖关系和约定
|
|
47
|
+
|
|
48
|
+
## 检测和收集标准
|
|
49
|
+
|
|
50
|
+
### 检测策略
|
|
51
|
+
|
|
52
|
+
自动检测并标记重要的技术洞察作为知识:
|
|
53
|
+
- 专注于实质性的技术发现和问题解决
|
|
54
|
+
- 捕获具有明确开发价值的洞察
|
|
55
|
+
- 平衡质量和全面性
|
|
56
|
+
- 优先考虑项目特定或普遍有价值的个人知识
|
|
57
|
+
|
|
58
|
+
### 正面触发器 - 在以下情况下检测知识:
|
|
59
|
+
- **问题解决**:解决需要调查的错误/问题
|
|
60
|
+
- **实现**:实现具有架构理由的功能
|
|
61
|
+
- **技术发现**:发现系统/功能如何工作
|
|
62
|
+
- **模式发现**:在代码库中找到重复模式
|
|
63
|
+
- **配置**:使用项目特定设置配置工具
|
|
64
|
+
- **决策**:制定或记录设计选择
|
|
65
|
+
|
|
66
|
+
### 负面触发器 - 在以下情况下不要检测:
|
|
67
|
+
- 没有代码/项目上下文的纯对话交流
|
|
68
|
+
- 微小操作(拼写错误、格式化、简单重命名)
|
|
69
|
+
- 没有项目特定应用的通用解释
|
|
70
|
+
- 知识库中已经捕获的重复信息
|
|
71
|
+
|
|
72
|
+
### 检测决策框架
|
|
73
|
+
对每个潜在的知识项目应用此评估:
|
|
74
|
+
1. **努力评估**:这需要有意义的调查或问题解决吗?
|
|
75
|
+
2. **未来影响**:这个知识会帮助未来的开发工作吗?
|
|
76
|
+
3. **适用性**:这与这个项目的独特特征相关,或者是有价值的个人原则吗?
|
|
77
|
+
4. **非显而易见性**:这个洞察很难仅从代码中得出吗?
|
|
78
|
+
|
|
79
|
+
**结果**:如果3个以上的检查通过 → 标记为知识捕获。
|
|
@@ -3,23 +3,21 @@ name: knowledge.add
|
|
|
3
3
|
description: Add a new knowledge item to the knowledge base with automatic content generation from user instruction
|
|
4
4
|
disable-model-invocation: false
|
|
5
5
|
user-invocable: true
|
|
6
|
-
allowed-tools: knowledge_create, knowledge_search, knowledge_list, Write, Read, Bash
|
|
7
|
-
context: fork
|
|
8
|
-
agent: general-purpose
|
|
6
|
+
allowed-tools: knowledge_create, knowledge_search, knowledge_list, Write, Read, Bash, Skill
|
|
9
7
|
---
|
|
10
8
|
|
|
11
9
|
# Knowledge Addition
|
|
12
10
|
|
|
13
11
|
Add a new knowledge item to the knowledge base with automatic content generation from user instruction. This skill uses the `knowledge-bank-management` MCP server to interact with the knowledge base.
|
|
14
12
|
|
|
15
|
-
## Knowledge
|
|
13
|
+
## Knowledge Detection Integration
|
|
16
14
|
|
|
17
|
-
**IMPORTANT:**
|
|
18
|
-
- Knowledge categories and types
|
|
19
|
-
- Quality standards and criteria
|
|
20
|
-
- Content structure requirements
|
|
15
|
+
**IMPORTANT:** Use the `knowledge.detect` skill to analyze whether the user instruction contains detectable knowledge points before proceeding with knowledge creation. This ensures alignment with established knowledge standards and prevents creation of low-value entries.
|
|
21
16
|
|
|
22
|
-
|
|
17
|
+
To use knowledge detection:
|
|
18
|
+
1. Call `knowledge.detect` with the user instruction as input
|
|
19
|
+
2. If knowledge points are detected, proceed with creation using the detected categories and structure
|
|
20
|
+
3. If no knowledge points are detected, inform the user and provide guidance on knowledge-worthy content
|
|
23
21
|
|
|
24
22
|
## Workflow
|
|
25
23
|
|
|
@@ -39,7 +37,7 @@ This reference document is essential for creating well-structured, valuable know
|
|
|
39
37
|
|
|
40
38
|
## Content Generation Guidelines
|
|
41
39
|
|
|
42
|
-
|
|
40
|
+
Use the knowledge detection results from `knowledge.detect` to guide content generation, ensuring adherence to established knowledge categories, quality standards, and structure requirements.
|
|
43
41
|
|
|
44
42
|
## Usage Example
|
|
45
43
|
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: knowledge.add
|
|
3
|
+
description: 根据用户指令自动生成内容并添加新的知识项目到知识库
|
|
4
|
+
disable-model-invocation: false
|
|
5
|
+
user-invocable: true
|
|
6
|
+
allowed-tools: knowledge_create, knowledge_search, knowledge_list, Write, Read, Bash, Skill
|
|
7
|
+
context: fork
|
|
8
|
+
agent: general-purpose
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# 知识添加
|
|
12
|
+
|
|
13
|
+
根据用户指令自动生成内容并添加新的知识项目到知识库。该技能使用 `knowledge-bank-management` MCP 服务器与知识库进行交互。
|
|
14
|
+
|
|
15
|
+
## 知识检测集成
|
|
16
|
+
|
|
17
|
+
**重要提示:** 在进行知识创建之前,使用 `knowledge.detect` 技能分析用户指令是否包含可检测的知识点。这确保与既定知识标准的一致性,并防止创建低价值条目。
|
|
18
|
+
|
|
19
|
+
使用知识检测:
|
|
20
|
+
1. 使用用户指令作为输入调用 `knowledge.detect`
|
|
21
|
+
2. 如果检测到知识点,使用检测到的类别和结构继续创建
|
|
22
|
+
3. 如果未检测到知识点,通知用户并提供关于值得知识内容的指导
|
|
23
|
+
|
|
24
|
+
## 工作流程
|
|
25
|
+
|
|
26
|
+
1. **指令分析**:分析用户的指令(`$ARGUMENTS`)以理解要捕获的核心知识。
|
|
27
|
+
2. **上下文发现**:搜索代码库中与指令相关的相关文件、实现详情和示例。
|
|
28
|
+
3. **知识生成**:基于分析生成全面的知识内容:
|
|
29
|
+
- **标题**:清晰、描述性的标题。
|
|
30
|
+
- **类型**:`architecture`、`code_pattern`、`pitfall`、`tool_usage`、`api_usage`、`exploration` 中的一种。
|
|
31
|
+
- **摘要**:简洁的一句描述。
|
|
32
|
+
- **内容**:详细解释、实现详情和代码示例。
|
|
33
|
+
- **文件**:相关文件路径。
|
|
34
|
+
- **标签**:可搜索的关键词。
|
|
35
|
+
4. **知识创建**:
|
|
36
|
+
- 将生成的知识数据写入 !`npx knowledge-bank config -t` 目录中的临时 JSON 文件。
|
|
37
|
+
- 使用带有 `from` 参数(仅文件名)和当前会话 ID 的 `knowledge_create` MCP 工具。
|
|
38
|
+
5. **确认**:报告成功并提供创建的知识项目的详情。
|
|
39
|
+
|
|
40
|
+
## 内容生成指南
|
|
41
|
+
|
|
42
|
+
使用来自 `knowledge.detect` 的知识检测结果来指导内容生成,确保遵循既定的知识类别、质量标准和结构要求。
|
|
43
|
+
|
|
44
|
+
## 使用示例
|
|
45
|
+
|
|
46
|
+
- 用户:`/knowledge-add "记录我们如何在这个项目中处理错误日志"`
|
|
47
|
+
- 结果:分析日志实现,扫描 `logger.ts`,并创建新的 `code_pattern` 知识项目。
|
|
@@ -3,7 +3,7 @@ name: knowledge.collect
|
|
|
3
3
|
description: Intelligent knowledge management with CRUD operations and lifecycle management
|
|
4
4
|
disable-model-invocation: false
|
|
5
5
|
user-invocable: true
|
|
6
|
-
allowed-tools: knowledge_create, knowledge_get, knowledge_update, knowledge_delete, knowledge_list, knowledge_search, knowledge_update_status, knowledge_stats, Write, Read, Bash
|
|
6
|
+
allowed-tools: knowledge_create, knowledge_get, knowledge_update, knowledge_delete, knowledge_list, knowledge_search, knowledge_update_status, knowledge_stats, Write, Read, Bash, Skill
|
|
7
7
|
context: fork
|
|
8
8
|
agent: general-purpose
|
|
9
9
|
---
|
|
@@ -25,14 +25,14 @@ The MCP tools support file operations through `to` and `from` parameters:
|
|
|
25
25
|
- **Filename Only**: Both `to` and `from` parameters accept only filenames (e.g., `knowledge-data.json`)
|
|
26
26
|
- **Path Resolution**: The MCP tools automatically resolve the complete file paths and return them in responses
|
|
27
27
|
|
|
28
|
-
## Knowledge
|
|
28
|
+
## Knowledge Detection Integration
|
|
29
29
|
|
|
30
|
-
**IMPORTANT:**
|
|
31
|
-
- Knowledge categories and types
|
|
32
|
-
- Detection criteria and quality standards
|
|
33
|
-
- Core knowledge elements and qualification criteria
|
|
30
|
+
**IMPORTANT:** Use the `knowledge.detect` skill to analyze the current conversation session for detectable knowledge points before proceeding with collection operations. This ensures only valuable, well-structured knowledge is captured and prevents low-quality entries.
|
|
34
31
|
|
|
35
|
-
|
|
32
|
+
To use knowledge detection:
|
|
33
|
+
1. Call `knowledge.detect` with the conversation content as input
|
|
34
|
+
2. Use the detection results to guide collection, categorization, and prioritization
|
|
35
|
+
3. If no significant knowledge is detected, skip collection and provide feedback to the user
|
|
36
36
|
|
|
37
37
|
# Knowledge Management Workflow
|
|
38
38
|
|
|
@@ -48,7 +48,7 @@ $ARGUMENTS
|
|
|
48
48
|
|
|
49
49
|
## Knowledge Detection Criteria
|
|
50
50
|
|
|
51
|
-
|
|
51
|
+
Use the `knowledge.detect` skill results to identify valuable knowledge items based on established detection criteria and quality standards.
|
|
52
52
|
|
|
53
53
|
## Knowledge Output Format
|
|
54
54
|
|
|
@@ -79,13 +79,52 @@ Reason: [Brief explanation - e.g., "Routine operations without project-specific
|
|
|
79
79
|
|
|
80
80
|
## 2. Duplicate Detection & Conflict Resolution
|
|
81
81
|
|
|
82
|
-
|
|
82
|
+
**IMPORTANT CHANGE**: MCP search now returns only essential fields (id, title, summary, knowledge_type, status, source_file) for performance optimization.
|
|
83
83
|
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
84
|
+
### New Duplicate Detection Workflow:
|
|
85
|
+
|
|
86
|
+
#### Step 1: Search for Essential Fields
|
|
87
|
+
Use `knowledge_search` to get potential duplicates:
|
|
88
|
+
```
|
|
89
|
+
knowledge_search({
|
|
90
|
+
query: ["extracted", "keywords", "from", "new", "knowledge"],
|
|
91
|
+
to: "duplicate-search.json"
|
|
92
|
+
})
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
#### Step 2: Analyze Similarity and Calculate Relevance
|
|
96
|
+
After reading the search results file, you MUST analyze each existing knowledge item's similarity to the new knowledge:
|
|
97
|
+
|
|
98
|
+
**Similarity Scoring Criteria:**
|
|
99
|
+
- **Title Similarity (40% weight)**: Exact word matches and semantic similarity
|
|
100
|
+
- **Knowledge Type Match (30% weight)**: Same knowledge_type indicates potential duplication
|
|
101
|
+
- **Source File Overlap (20% weight)**: Same or related source files
|
|
102
|
+
- **Summary Similarity (10% weight)**: Conceptual overlap in descriptions
|
|
103
|
+
|
|
104
|
+
**Similarity Algorithm:**
|
|
105
|
+
1. Extract keywords from new knowledge (lowercase, remove stopwords)
|
|
106
|
+
2. For each existing knowledge item, calculate similarity score (0.0 to 1.0)
|
|
107
|
+
3. Filter items with similarity > 0.6 (high similarity threshold for duplicates)
|
|
108
|
+
4. Sort by similarity score descending
|
|
109
|
+
|
|
110
|
+
#### Step 3: Retrieve Full Content for High-Similarity Items Only
|
|
111
|
+
Only for high-similarity items (score > 0.6), use `knowledge_get` to retrieve full content:
|
|
112
|
+
```
|
|
113
|
+
knowledge_get({
|
|
114
|
+
id: similarId,
|
|
115
|
+
to: "existing-{id}.md"
|
|
116
|
+
})
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
#### Step 4: Decision Logic Based on Similarity
|
|
120
|
+
- **SIMILARITY > 0.8**: Very likely duplicate - Update existing knowledge
|
|
121
|
+
- **SIMILARITY 0.6-0.8**: Possible duplicate - Merge insights into existing knowledge
|
|
122
|
+
- **SIMILARITY < 0.6**: Unique insight - Create new knowledge item
|
|
123
|
+
|
|
124
|
+
**Critical Requirements:**
|
|
125
|
+
- NEVER call `knowledge_get` for low-similarity items (score ≤ 0.6)
|
|
126
|
+
- Limit duplicate detection to maximum 3 knowledge retrievals
|
|
127
|
+
- Always explain similarity reasoning before making decisions
|
|
89
128
|
|
|
90
129
|
## 3. Execution via File Passing
|
|
91
130
|
|
|
@@ -0,0 +1,185 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: knowledge.collect
|
|
3
|
+
description: 具有 CRUD 操作和生命周期管理的智能知识管理
|
|
4
|
+
disable-model-invocation: false
|
|
5
|
+
user-invocable: true
|
|
6
|
+
allowed-tools: knowledge_create, knowledge_get, knowledge_update, knowledge_delete, knowledge_list, knowledge_search, knowledge_update_status, knowledge_stats, Write, Read, Bash, Skill
|
|
7
|
+
context: fork
|
|
8
|
+
agent: general-purpose
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# 知识收集与管理
|
|
12
|
+
|
|
13
|
+
智能知识生命周期管理系统,通过创建/更新/删除操作处理检测到的知识项目,具有智能去重和质量控制功能。
|
|
14
|
+
|
|
15
|
+
**重要提示:** 您可以访问 `knowledge-bank-management` MCP 服务器,该服务器提供所有必要的知识管理操作工具。使用这些 MCP 工具与知识库交互,而不是 CLI 命令。
|
|
16
|
+
**系统环境变量:**
|
|
17
|
+
- CLAUDE_SESSION_ID=!`echo $CLAUDE_SESSION_ID`
|
|
18
|
+
- CLAUDE_SESSION_SOURCE=!`echo $CLAUDE_SESSION_SOURCE`
|
|
19
|
+
- CLAUDE_SESSION_MODE=!`echo $CLAUDE_SESSION_MODE`
|
|
20
|
+
- CLAUDE_SESSION_REPOSITORYID=!`echo $CLAUDE_SESSION_REPOSITORYID`
|
|
21
|
+
|
|
22
|
+
## 文件参数配置
|
|
23
|
+
|
|
24
|
+
MCP 工具通过 `to` 和 `from` 参数支持文件操作:
|
|
25
|
+
- **仅文件名**:`to` 和 `from` 参数都只接受文件名(例如:`knowledge-data.json`)
|
|
26
|
+
- **路径解析**:MCP 工具自动解析完整文件路径并在响应中返回
|
|
27
|
+
|
|
28
|
+
## 知识检测集成
|
|
29
|
+
|
|
30
|
+
**重要提示:** 使用 `knowledge.detect` 技能分析当前对话会话,在进行收集操作之前识别可检测的知识点。这确保只捕获有价值的、结构良好的知识,并防止低质量条目。
|
|
31
|
+
|
|
32
|
+
使用知识检测进行收集:
|
|
33
|
+
1. 使用对话内容作为输入调用 `knowledge.detect` 以识别潜在的知识点
|
|
34
|
+
2. 使用检测结果指导收集、分类和优先级排序
|
|
35
|
+
3. 如果未检测到重要知识,跳过收集并向用户提供反馈
|
|
36
|
+
|
|
37
|
+
# 知识管理工作流程
|
|
38
|
+
|
|
39
|
+
## 1. 知识检测分析
|
|
40
|
+
使用下面统一的知识检测标准收集知识项目,考虑用户的输入:
|
|
41
|
+
|
|
42
|
+
**注意**
|
|
43
|
+
-- 您必须在后台运行,不与用户交互,或提示用户提供更多信息。
|
|
44
|
+
|
|
45
|
+
<user_input>
|
|
46
|
+
$ARGUMENTS
|
|
47
|
+
</user_input>
|
|
48
|
+
|
|
49
|
+
## 知识检测标准
|
|
50
|
+
|
|
51
|
+
使用来自 `knowledge.detect` 技能的知识检测结果根据既定的检测标准和质量标准识别有价值的知识项目。
|
|
52
|
+
|
|
53
|
+
## 知识输出格式
|
|
54
|
+
|
|
55
|
+
当检测到有价值的知识时,以此结构化格式输出:
|
|
56
|
+
|
|
57
|
+
### 输出模板
|
|
58
|
+
|
|
59
|
+
```
|
|
60
|
+
🧠 发现知识
|
|
61
|
+
|
|
62
|
+
标题:[清晰、描述性的标题]
|
|
63
|
+
类型:[architecture|code_pattern|pitfall|tool_usage|api_usage|exploration]
|
|
64
|
+
摘要:[洞察的一句话描述]
|
|
65
|
+
|
|
66
|
+
文件:[相关文件路径的逗号分隔列表]
|
|
67
|
+
标签:[用于未来参考的可搜索关键词]
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### 未发现知识输出
|
|
71
|
+
|
|
72
|
+
当未检测到有价值的知识时:
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
📝 未检测到重要知识
|
|
76
|
+
|
|
77
|
+
原因:[简短解释 - 例如:"常规操作,无项目特定洞察"]
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
## 2. 重复检测与冲突解决
|
|
81
|
+
|
|
82
|
+
**重要更改**:为了优化性能,MCP 搜索现在仅返回基本字段(id、title、summary、knowledge_type、status、source_file)。
|
|
83
|
+
|
|
84
|
+
### 具有智能重复检测的新重复检测流程:
|
|
85
|
+
|
|
86
|
+
#### 第 1 步:搜索基本字段
|
|
87
|
+
使用 `knowledge_search` 获取潜在的重复项:
|
|
88
|
+
```
|
|
89
|
+
knowledge_search({
|
|
90
|
+
query: ["extracted", "keywords", "from", "new", "knowledge"],
|
|
91
|
+
to: "duplicate-search.json"
|
|
92
|
+
})
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
#### 第 2 步:分析相似性并计算相关性
|
|
96
|
+
读取搜索结果文件后,您必须分析每个现有知识项目与新知识的相似性:
|
|
97
|
+
|
|
98
|
+
**相似度评分标准:**
|
|
99
|
+
- **标题相似度 (40% 权重)**:精确词匹配和语义相似度
|
|
100
|
+
- **知识类型匹配 (30% 权重)**:相同的 knowledge_type 暗示潜在重复
|
|
101
|
+
- **源文件重叠 (20% 权重)**:相同或相关的源文件
|
|
102
|
+
- **摘要相似度 (10% 权重)**:描述中的概念重叠
|
|
103
|
+
|
|
104
|
+
**相似度算法:**
|
|
105
|
+
1. 从新知识中提取关键词(小写,去除停用词)
|
|
106
|
+
2. 为每个现有知识项目计算相似度评分(0.0 到 1.0)
|
|
107
|
+
3. 过滤相似度 > 0.6 的项目(重复项的高相似度阈值)
|
|
108
|
+
4. 按相似度评分降序排序
|
|
109
|
+
|
|
110
|
+
#### 第 3 步:仅为高相似度项目检索完整内容
|
|
111
|
+
仅对于高相似度项目(评分 > 0.6),使用 `knowledge_get` 检索完整内容:
|
|
112
|
+
```
|
|
113
|
+
knowledge_get({
|
|
114
|
+
id: similarId,
|
|
115
|
+
to: "existing-{id}.md"
|
|
116
|
+
})
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
#### 第 4 步:基于相似度的决策逻辑
|
|
120
|
+
- **相似度 > 0.8**:极可能是重复项 - 更新现有知识
|
|
121
|
+
- **相似度 0.6-0.8**:可能是重复项 - 将洞察合并到现有知识中
|
|
122
|
+
- **相似度 < 0.6**:独特洞察 - 创建新知识项目
|
|
123
|
+
|
|
124
|
+
**关键要求:**
|
|
125
|
+
- 绝不为低相似度项目(评分 ≤ 0.6)调用 `knowledge_get`
|
|
126
|
+
- 重复检测限制为最多 3 个知识检索
|
|
127
|
+
- 在做出决策之前始终解释相似性理由
|
|
128
|
+
|
|
129
|
+
## 3. 通过文件传递执行
|
|
130
|
+
|
|
131
|
+
为确保可靠性并处理大量内容,始终使用基于文件的操作:
|
|
132
|
+
1. 将知识数据(用于创建或更新)写入 !`npx knowledge-bank config -t` 目录中的本地 JSON 文件。
|
|
133
|
+
2. 在 `knowledge_create` 或 `knowledge_update` 中使用 `from` 参数提供文件名(例如:`{knowledge title}.json`)。注意:`from` 参数只包含文件名,不包含完整路径。MCP 工具将自动处理完整文件路径(在 !`npx knowledge-bank config -t` 中查找)并在响应中返回。
|
|
134
|
+
|
|
135
|
+
## 智能管理策略
|
|
136
|
+
|
|
137
|
+
### 去重策略
|
|
138
|
+
- **语义搜索**:使用 `knowledge_search` 查找具有相似标题/内容的知识
|
|
139
|
+
- **基于文件的分组**:按受影响的文件对知识进行分组
|
|
140
|
+
- **类型整合**:使用 `knowledge_update` 合并相同类型的相关洞察
|
|
141
|
+
- **时间相关性**:更新最近的知识而不是创建重复项
|
|
142
|
+
|
|
143
|
+
### 内容增强策略
|
|
144
|
+
- **合并互补洞察**:使用 `knowledge_update` 组合相关发现
|
|
145
|
+
- **添加缺失上下文**:用新详情增强现有知识
|
|
146
|
+
- **更新代码引用**:刷新文件路径和行号
|
|
147
|
+
- **提高可搜索性**:添加相关标签和关键词
|
|
148
|
+
|
|
149
|
+
### 生命周期管理
|
|
150
|
+
- **草稿 → 已验证**:使用 `knowledge_update_status` 提升高质量知识
|
|
151
|
+
- **已验证 → 已归档**:使用 `knowledge_update_status` 管理生命周期
|
|
152
|
+
- **删除重复项**:使用 `knowledge_delete` 移除冗余条目
|
|
153
|
+
- **定期清理**:识别并移除低价值条目
|
|
154
|
+
|
|
155
|
+
---
|
|
156
|
+
|
|
157
|
+
# 工作流程示例
|
|
158
|
+
|
|
159
|
+
## 创建新知识
|
|
160
|
+
1. 使用带有 `to` 参数(仅文件名,例如:`search-results.json`)的 `knowledge_search` 检查重复项并将结果保存到 !`npx knowledge-bank config -t` 目录。
|
|
161
|
+
2. 如果未找到重复项:
|
|
162
|
+
- 将新知识数据写入 !`npx knowledge-bank config -t` 中的本地 JSON 文件。
|
|
163
|
+
- 使用带有 `from` 参数(仅文件名,例如:`new-knowledge.json`)和 `session_id`(即 ${CLAUDE_SESSION_ID})以及 `repository_id`(即 !`echo $CLAUDE_SESSION_REPOSITORYID`)的 `knowledge_create`。
|
|
164
|
+
3. 如果存在重复项:
|
|
165
|
+
- 将合并的知识数据写入 !`npx knowledge-bank config -t` 中的本地 JSON 文件。
|
|
166
|
+
- 使用带有 `from` 参数(仅文件名,例如:`merged-knowledge.json`)的 `knowledge_update`。
|
|
167
|
+
|
|
168
|
+
## 更新现有知识
|
|
169
|
+
1. 使用带有 `to` 参数(仅文件名,例如:`existing-knowledge.json`)的 `knowledge_get` 将当前数据检索到 !`npx knowledge-bank config -t` 中的 markdown/JSON 文件。
|
|
170
|
+
2. 将新洞察与检索到的内容合并。
|
|
171
|
+
3. 将合并的数据写入 !`npx knowledge-bank config -t` 中的本地 JSON 文件。
|
|
172
|
+
4. 使用带有 `from` 参数(仅文件名,例如:`updated-knowledge.json`)的 `knowledge_update`。
|
|
173
|
+
|
|
174
|
+
## 提升知识质量
|
|
175
|
+
1. 使用 `knowledge_list` 查找草稿项目
|
|
176
|
+
2. 审查和验证内容
|
|
177
|
+
3. 使用 `knowledge_update_status` 提升为已验证
|
|
178
|
+
|
|
179
|
+
## 搜索和检索
|
|
180
|
+
1. 使用相关术语的 `knowledge_search`
|
|
181
|
+
2. 使用 `knowledge_get` 检索完整详情
|
|
182
|
+
3. 使用返回的知识增强当前上下文
|
|
183
|
+
|
|
184
|
+
## 获取统计信息
|
|
185
|
+
使用 `knowledge_stats` 了解知识库状态。
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: knowledge.delete
|
|
3
|
+
description: 从知识库中删除特定的知识项目
|
|
4
|
+
disable-model-invocation: false
|
|
5
|
+
user-invocable: true
|
|
6
|
+
allowed-tools: knowledge_delete, knowledge_get, knowledge_search, Write, Read, Bash
|
|
7
|
+
context: fork
|
|
8
|
+
agent: general-purpose
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# 知识删除
|
|
12
|
+
|
|
13
|
+
使用知识项目的 ID 从知识库中删除特定的知识项目。
|
|
14
|
+
|
|
15
|
+
## 工作流程
|
|
16
|
+
|
|
17
|
+
1. **识别**:使用 `$ARGUMENTS` 中提供的 ID 识别要删除的知识项目。如果 ID 不明确,请使用 `knowledge_search` 查找。
|
|
18
|
+
2. **验证**:使用 `knowledge_get` 工具检索该项目的详细信息,以确保其存在,并向用户展示将要删除的内容。
|
|
19
|
+
3. **执行**:使用带有指定 ID 的 `knowledge_delete` MCP 工具。
|
|
20
|
+
4. **报告**:确认删除成功或报告任何错误。
|
|
21
|
+
|
|
22
|
+
⚠️ **警告**:删除是永久性的,无法撤销。
|
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: knowledge.detect
|
|
3
|
+
description: Define and collect technical knowledge points from the current conversation
|
|
4
|
+
disable-model-invocation: false
|
|
5
|
+
user-invocable: true
|
|
6
|
+
allowed-tools: Read, Write, Bash
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# In-Session Knowledge Detection & Collection
|
|
10
|
+
|
|
11
|
+
This skill is EXCLUSIVELY responsible for identifying and extracting high-value technical knowledge points from the **current conversation session**. It does NOT manage, search, or represent the persistent knowledge base; it only defines and captures insights emerged during this specific interaction.
|
|
12
|
+
|
|
13
|
+
## 1. Scope of Detection
|
|
14
|
+
|
|
15
|
+
- **Context**: Analyze the entire conversation history of the current session.
|
|
16
|
+
- **Guidance (ARGUMENTS)**: The `ARGUMENTS` parameter acts as a **guidance** or **theme** for knowledge collection. It may specify particular topics to focus on or provide instructions on how to collect.
|
|
17
|
+
- If `ARGUMENTS` is provided: Prioritize detecting knowledge related to the specified theme.
|
|
18
|
+
- If `ARGUMENTS` is **null** or empty: Autonomously detect all high-value technical knowledge emerged in the conversation history.
|
|
19
|
+
- **Focus**: Capture spontaneous insights, problem-solving paths, and technical decisions emerged during this conversation.
|
|
20
|
+
|
|
21
|
+
## 2. Core Knowledge Elements
|
|
22
|
+
|
|
23
|
+
Every knowledge item MUST contain these four essential elements:
|
|
24
|
+
|
|
25
|
+
1. **What**: The core insight, pattern, or solution discovered.
|
|
26
|
+
2. **Where**: Specific file locations, line numbers, or system components involved.
|
|
27
|
+
3. **Why**: The rationale, context, or problem being addressed.
|
|
28
|
+
4. **How**: The implementation approach, usage examples, or process steps.
|
|
29
|
+
|
|
30
|
+
## 3. Qualification Criteria
|
|
31
|
+
|
|
32
|
+
Knowledge MUST meet ALL of the following requirements:
|
|
33
|
+
- **Relevant**: Tied to concrete files/patterns in this project or applicable to personal development principles.
|
|
34
|
+
- **Valuable**: Saves significant time/effort for future development work.
|
|
35
|
+
- **Non-obvious**: Not immediately apparent from reading code alone.
|
|
36
|
+
- **Actionable**: Provides clear guidance for developers.
|
|
37
|
+
|
|
38
|
+
## 4. Knowledge Scope
|
|
39
|
+
|
|
40
|
+
- **Project Scope** (`project`): Specific to the current codebase, architecture, unique patterns, and configurations.
|
|
41
|
+
- **Personal Scope** (`personal`): General technical insights, personal preferences, coding principles, or reusable cross-project workflows. It includes:
|
|
42
|
+
- **Universal/General**: Broad technical insights or best practices applicable across various contexts.
|
|
43
|
+
- **Personal Preferences**: Individual development style, coding principles, or favored patterns.
|
|
44
|
+
- **Cross-project**: Logic, workflows, or solutions that can be reused in different projects.
|
|
45
|
+
- **Philosophical**: High-level development principles and decision-making frameworks.
|
|
46
|
+
|
|
47
|
+
## 5. Knowledge Categories
|
|
48
|
+
|
|
49
|
+
Common categories include:
|
|
50
|
+
1. **Architecture** (`architecture`): System design, component structure, and architectural patterns.
|
|
51
|
+
2. **Code Patterns** (`code_pattern`): Reusable patterns and conventions.
|
|
52
|
+
3. **Problem-Solving** (`pitfall`): Debugging processes, root causes, and resolution strategies.
|
|
53
|
+
4. **Tool Usage** (`tool_usage`): Project-specific configurations, commands, and workflows.
|
|
54
|
+
5. **Domain Knowledge** (`api_usage`): Business logic and domain-specific understanding.
|
|
55
|
+
6. **Exploration** (`exploration`): Codebase structure, dependencies, and conventions.
|
|
56
|
+
|
|
57
|
+
**Extensibility**: You are encouraged to create new categories if the technical insight does not fit into the existing ones. Ensure the new category name is concise (lowercase snake_case).
|
|
58
|
+
|
|
59
|
+
## 6. Detection Policy & Framework
|
|
60
|
+
|
|
61
|
+
### Detection Policy
|
|
62
|
+
Automatically detect and flag knowledge for SIGNIFICANT technical insights. Focus on substantial discoveries, problem-solving, and architectural rationale.
|
|
63
|
+
|
|
64
|
+
### Detection Decision Framework
|
|
65
|
+
Evaluate every potential insight against these four checks:
|
|
66
|
+
1. **Effort**: Did it involve meaningful investigation or problem-solving?
|
|
67
|
+
2. **Impact**: Will it significantly help future development?
|
|
68
|
+
3. **Applicability**: Is it project-specific or a valuable personal principle?
|
|
69
|
+
4. **Non-obviousness**: Is it hard to derive from code alone?
|
|
70
|
+
|
|
71
|
+
**Threshold**: An insight must pass at least **3 out of 4** checks to be collected.
|
|
72
|
+
|
|
73
|
+
## 7. Workflow
|
|
74
|
+
|
|
75
|
+
### 1. Analysis and Guidance
|
|
76
|
+
|
|
77
|
+
The `ARGUMENTS` parameter provides the guidance or theme for knowledge collection:
|
|
78
|
+
|
|
79
|
+
<ARGUMENTS>
|
|
80
|
+
$ARGUMENTS
|
|
81
|
+
</ARGUMENTS>
|
|
82
|
+
|
|
83
|
+
You must analyze the entire conversation history based on this guidance to detect and extract high-value technical knowledge.
|
|
84
|
+
|
|
85
|
+
### 2. Extraction
|
|
86
|
+
For each qualified insight, extract:
|
|
87
|
+
- **Title**: Concise and descriptive.
|
|
88
|
+
- **Category & Scope**: As defined above.
|
|
89
|
+
- **Content**: The four core elements (What, Where, Why, How).
|
|
90
|
+
|
|
91
|
+
## 8. Collection Results Output
|
|
92
|
+
|
|
93
|
+
### When Knowledge Points Are Detected
|
|
94
|
+
|
|
95
|
+
```
|
|
96
|
+
🧠 Knowledge Detected
|
|
97
|
+
|
|
98
|
+
**Total:** [Number] point(s)
|
|
99
|
+
|
|
100
|
+
1. **[Knowledge Title]**
|
|
101
|
+
- Category: [category] | Scope: [scope]
|
|
102
|
+
- Location: [relevant files/components]
|
|
103
|
+
- Elements:
|
|
104
|
+
- **What**: [insight]
|
|
105
|
+
- **Why**: [rationale]
|
|
106
|
+
- **How**: [implementation]
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
### When No Knowledge Points Are Detected
|
|
110
|
+
|
|
111
|
+
```
|
|
112
|
+
❌ No Knowledge Detected
|
|
113
|
+
|
|
114
|
+
**Reason:** [Brief explanation based on qualification criteria]
|
|
115
|
+
```
|