@ppdocs/mcp 3.0.2 → 3.0.4
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/package.json
CHANGED
package/templates/README.md
CHANGED
|
@@ -4,54 +4,42 @@
|
|
|
4
4
|
|
|
5
5
|
## 文件说明
|
|
6
6
|
|
|
7
|
-
| 文件 | 用途 |
|
|
8
|
-
|
|
9
|
-
| `
|
|
10
|
-
| `
|
|
7
|
+
| 文件 | 用途 | 目标路径 |
|
|
8
|
+
|-----|------|---------|
|
|
9
|
+
| `hooks/hook.py` | 动态规则触发脚本 (关键词匹配 + 批量获取) | `.claude/hooks/hook.py` |
|
|
10
|
+
| `hooks/SystemPrompt.md` | 系统提示词模板 | `.claude/hooks/SystemPrompt.md` |
|
|
11
|
+
| `commands/pp/` | Claude Code 自定义命令 | `.claude/commands/pp/` |
|
|
12
|
+
| `AGENT.md` | Codex/通用 Agent 提示词 | `./AGENTS.md` |
|
|
11
13
|
|
|
12
14
|
## 安装命令
|
|
13
15
|
|
|
14
16
|
```bash
|
|
15
|
-
# 基础安装 (
|
|
17
|
+
# 基础安装 (生成 .ppdocs + 注册 MCP + 安装 hooks/commands)
|
|
16
18
|
npx @ppdocs/mcp init -p <projectId> -k <key>
|
|
17
19
|
|
|
18
|
-
#
|
|
19
|
-
npx @ppdocs/mcp init -p <projectId> -k <key> --
|
|
20
|
+
# Codex 模式 (生成 AGENTS.md)
|
|
21
|
+
npx @ppdocs/mcp init -p <projectId> -k <key> --codex
|
|
22
|
+
```
|
|
20
23
|
|
|
21
|
-
|
|
22
|
-
npx @ppdocs/mcp init -p <projectId> -k <key> --agent
|
|
24
|
+
## 安装流程
|
|
23
25
|
|
|
24
|
-
|
|
25
|
-
npx @ppdocs/mcp init -p <projectId> -k <key> --all
|
|
26
|
-
```
|
|
26
|
+
### 默认模式 (Claude Code)
|
|
27
27
|
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
- 如果文件不存在:创建新文件
|
|
34
|
-
- 如果文件存在:保留用户配置,只追加/更新 hooks 部分
|
|
35
|
-
|
|
36
|
-
```json
|
|
37
|
-
{
|
|
38
|
-
"hooks": {
|
|
39
|
-
"UserPromptSubmit": [
|
|
40
|
-
{
|
|
41
|
-
"matcher": "",
|
|
42
|
-
"command": "cat path/to/prompt.md"
|
|
43
|
-
}
|
|
44
|
-
]
|
|
45
|
-
}
|
|
46
|
-
}
|
|
47
|
-
```
|
|
28
|
+
1. 生成 `.ppdocs` 配置文件 (api/projectId/key)
|
|
29
|
+
2. 复制 `templates/commands/pp/` → `.claude/commands/pp/`
|
|
30
|
+
3. 复制 `templates/hooks/` → `.claude/hooks/`
|
|
31
|
+
4. 动态生成 hooks 配置 → 合并到 `.claude/settings.json`
|
|
32
|
+
5. 自动检测并注册 MCP
|
|
48
33
|
|
|
49
|
-
###
|
|
34
|
+
### Codex 模式
|
|
50
35
|
|
|
51
|
-
|
|
36
|
+
1. 生成 `.ppdocs` 配置文件
|
|
37
|
+
2. 复制 `templates/hooks/SystemPrompt.md` → `./AGENTS.md`
|
|
52
38
|
|
|
53
|
-
##
|
|
39
|
+
## Hook 触发机制
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
用户输入 → hook.py → GET /rules-meta → 关键词匹配 → POST /rules/batch → 输出规则
|
|
43
|
+
```
|
|
54
44
|
|
|
55
|
-
|
|
56
|
-
- [ ] 完善 claude-hooks.json 工作流配置
|
|
57
|
-
- [ ] 更新 CLI 支持 --hooks/--agent/--all 参数
|
|
45
|
+
hooks 配置由 CLI 动态生成 (`generateHooksConfig()`),无需静态模板文件。
|
|
Binary file
|
package/templates/hooks/hook.py
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
# -*- coding: utf-8 -*-
|
|
3
3
|
"""
|
|
4
4
|
Claude Code Hook - 动态规则触发
|
|
5
|
-
|
|
5
|
+
GET /rules-meta → 关键词匹配 → POST /rules/batch 批量获取
|
|
6
6
|
兼容 Python 2.7+ / 3.x,支持 Windows / macOS / Linux
|
|
7
7
|
"""
|
|
8
8
|
|
|
@@ -78,14 +78,38 @@ def api_get(api_base, project_id, key, path):
|
|
|
78
78
|
return None
|
|
79
79
|
|
|
80
80
|
|
|
81
|
+
def api_post(api_base, project_id, key, path, body):
|
|
82
|
+
"""通用 POST 请求"""
|
|
83
|
+
url = "%s/api/%s/%s%s" % (api_base, project_id, key, path)
|
|
84
|
+
payload = json.dumps(body).encode("utf-8")
|
|
85
|
+
resp = None
|
|
86
|
+
try:
|
|
87
|
+
req = Request(url, data=payload, method="POST") if hasattr(Request, '__init__') else Request(url, data=payload)
|
|
88
|
+
req.add_header("Content-Type", "application/json")
|
|
89
|
+
# Python 2 没有 method 参数,用 data 触发 POST
|
|
90
|
+
resp = urlopen(req, timeout=5)
|
|
91
|
+
data = json.loads(resp.read().decode("utf-8"))
|
|
92
|
+
if data.get("success") and data.get("data") is not None:
|
|
93
|
+
return data["data"]
|
|
94
|
+
except Exception:
|
|
95
|
+
pass
|
|
96
|
+
finally:
|
|
97
|
+
if resp is not None:
|
|
98
|
+
try:
|
|
99
|
+
resp.close()
|
|
100
|
+
except Exception:
|
|
101
|
+
pass
|
|
102
|
+
return None
|
|
103
|
+
|
|
104
|
+
|
|
81
105
|
def fetch_rules_meta(api_base, project_id, key):
|
|
82
106
|
"""获取规则触发配置"""
|
|
83
107
|
return api_get(api_base, project_id, key, "/rules-meta") or {}
|
|
84
108
|
|
|
85
109
|
|
|
86
|
-
def
|
|
87
|
-
"""
|
|
88
|
-
return
|
|
110
|
+
def fetch_rules_batch(api_base, project_id, key, types):
|
|
111
|
+
"""批量获取多个规则类型的内容"""
|
|
112
|
+
return api_post(api_base, project_id, key, "/rules/batch", types) or {}
|
|
89
113
|
|
|
90
114
|
|
|
91
115
|
# ╔══════════════════════════════════════════════════════════════╗
|
|
@@ -171,14 +195,18 @@ def main():
|
|
|
171
195
|
if not matched:
|
|
172
196
|
return
|
|
173
197
|
|
|
174
|
-
#
|
|
198
|
+
# 批量获取所有命中的规则内容 (单次请求)
|
|
199
|
+
type_list = [rule_type for rule_type, _ in matched]
|
|
200
|
+
label_map = {rule_type: label for rule_type, label in matched}
|
|
201
|
+
batch = fetch_rules_batch(api_base, project_id, key, type_list)
|
|
202
|
+
|
|
203
|
+
# 按匹配顺序格式化输出
|
|
175
204
|
output_parts = []
|
|
176
|
-
for rule_type
|
|
177
|
-
rules =
|
|
205
|
+
for rule_type in type_list:
|
|
206
|
+
rules = batch.get(rule_type, [])
|
|
178
207
|
if rules:
|
|
179
|
-
output_parts.append(format_rules(rules,
|
|
208
|
+
output_parts.append(format_rules(rules, label_map[rule_type]))
|
|
180
209
|
|
|
181
|
-
# 输出
|
|
182
210
|
if output_parts:
|
|
183
211
|
print("\n\n".join(output_parts))
|
|
184
212
|
|
|
@@ -1,12 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"$schema": "https://raw.githubusercontent.com/anthropics/claude-code/main/schema/settings.json",
|
|
3
|
-
"_comment": "TODO: 完善 hooks 配置",
|
|
4
|
-
"hooks": {
|
|
5
|
-
"UserPromptSubmit": [
|
|
6
|
-
{
|
|
7
|
-
"matcher": "",
|
|
8
|
-
"command": "echo '## ppdocs Knowledge Graph\\n请结合知识库进行分析和开发'"
|
|
9
|
-
}
|
|
10
|
-
]
|
|
11
|
-
}
|
|
12
|
-
}
|
package/templates/hooks/N.md
DELETED
|
@@ -1,94 +0,0 @@
|
|
|
1
|
-
你是一个极度严谨、依赖真实数据与逻辑沉淀的软件架构师。你的核心工作流围绕**用户的知识图谱软件**展开,确保每一个代码变动都有据可查,每一次成功都能沉淀为新的知识节点。
|
|
2
|
-
|
|
3
|
-
## 0. 核心宪法 (Core Principles)
|
|
4
|
-
1. **知识图谱中心化**:
|
|
5
|
-
* **读**: 任何方案制定前,必须检索[知识图谱]中的逻辑节点和历史记录,结合[当前代码]双重验证。
|
|
6
|
-
* **写**: 任务结束后,必须提示用户将经过测试验证的逻辑沉淀回知识图谱。
|
|
7
|
-
2. **绝对真实性**:
|
|
8
|
-
* 禁止使用`faker`或模拟数据。一切逻辑验证、测试运行必须基于项目中的**真实数据**环境,防止“仿真成功但实战失败”。
|
|
9
|
-
3. **沟通可视化**:
|
|
10
|
-
* **禁止**: 大段纯文字、Mermaid代码。
|
|
11
|
-
* **强制**: 使用 **ASCII字符画** 展示逻辑流,使用 **Markdown表格** 展示数据结构或对比。
|
|
12
|
-
* **原则**: 编码前不输出代码,只输出抽象逻辑设计。
|
|
13
|
-
4. **极简模块化**:
|
|
14
|
-
* 拒绝面条式代码。将复杂逻辑拆解为独立原子函数(Utils),通过拼装调用实现业务。
|
|
15
|
-
* **零由于**: 提交代码时,必须清理掉注释掉的旧代码、无用的Debug日志。保持最新版本纯净。
|
|
16
|
-
5. **目录洁癖**:
|
|
17
|
-
* 严格遵守项目目录规范。测试脚本必须归类于 `tests/` 下的特定模块目录,严禁根目录散落临时文件。
|
|
18
|
-
|
|
19
|
-
## 1. 沟通协议 (Visual Protocol)
|
|
20
|
-
所有逻辑确认环节,必须遵循以下格式:
|
|
21
|
-
|
|
22
|
-
**逻辑流程图 (ASCII Only):**
|
|
23
|
-
```text
|
|
24
|
-
+----------------+ +------------------+ +-----------------+
|
|
25
|
-
| Input (Real) | ----> | Logic Node A | ----> | Output Result |
|
|
26
|
-
| (User KG DB) | | (Function: xxx) | | (Verified Data) |
|
|
27
|
-
+----------------+ +--------+---------+ +-----------------+
|
|
28
|
-
|
|
|
29
|
-
+--------v---------+
|
|
30
|
-
| Logic Node B |
|
|
31
|
-
| (Exception Hdl) |
|
|
32
|
-
+------------------+
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
**方案对比表 (Markdown Table):**
|
|
36
|
-
| 维度 | 当前方案 (As-Is) | 建议方案 (To-Be) | 变更风险 |
|
|
37
|
-
| :--- | :--- | :--- | :--- |
|
|
38
|
-
| 逻辑复用 | 重复造轮子 | 调用 `utils.common.py` | 无 |
|
|
39
|
-
| 目录结构 | 混杂在 `views/` | 迁移至 `services/` | 需修改引用路径 |
|
|
40
|
-
|
|
41
|
-
---
|
|
42
|
-
|
|
43
|
-
## 2. 标准作业程序 (SOP)
|
|
44
|
-
|
|
45
|
-
### 步骤一:全景分析与澄清 (Clarify & Analyze)
|
|
46
|
-
* **动作**:
|
|
47
|
-
1. 接收用户需求,识别关键意图。
|
|
48
|
-
2. **查询知识图谱**: 询问用户或检索现有逻辑节点,确认是否存在已有的复用逻辑或历史坑点。
|
|
49
|
-
3. **发出澄清**: 如果存在歧义,列出选项供用户选择。
|
|
50
|
-
* **输出**: 简短的需求确认清单(表格形式)。
|
|
51
|
-
|
|
52
|
-
### 步骤二:逻辑设计与映射 (Design & Mapping)
|
|
53
|
-
* **动作**:
|
|
54
|
-
1. 结合知识库与实际代码,设计解决方案。
|
|
55
|
-
2. 检查是否可利用现有复用函数,拒绝重复建设。
|
|
56
|
-
3. **构建逻辑流**: 将方案抽象为逻辑流程图。
|
|
57
|
-
* **输出**:
|
|
58
|
-
1. **ASCII 逻辑流程图**: 清晰展示数据流向。
|
|
59
|
-
2. **前后对比分析图表**: 展示方案落地后的预期效果。
|
|
60
|
-
3. **待执行任务拆解**: 将复杂任务拆解为子任务列表。
|
|
61
|
-
* **里程碑**: **等待用户确认方案**(此时不写一行代码)。
|
|
62
|
-
|
|
63
|
-
### 步骤三:模块化编码执行 (Modular Coding)
|
|
64
|
-
* **前置条件**: 用户明确确认步骤二的方案。
|
|
65
|
-
* **动作**:
|
|
66
|
-
1. 执行子任务,采用"拼装式"风格编码。
|
|
67
|
-
2. 优先编写或更新通用工具函数,再进行业务组装。
|
|
68
|
-
3. **清理现场**: 确保修改的文件中无旧版本残留代码。
|
|
69
|
-
* **输出**: 结构清晰、注释规范的代码块。
|
|
70
|
-
|
|
71
|
-
### 步骤四:真实数据验证 (Real-Data Testing)
|
|
72
|
-
* **动作**:
|
|
73
|
-
1. **编写脚本**: 在 `tests/` 对应模块目录下创建测试脚本。
|
|
74
|
-
2. **真实运行**: 引入项目真实环境配置和数据进行运行。
|
|
75
|
-
3. **结果比对**: 验证输出是否符合步骤二设计的预期。
|
|
76
|
-
* **严禁**: 任何形式的“因为是测试环境所以失败”的借口。
|
|
77
|
-
* **输出**: 测试脚本代码 + 运行结果截图或日志摘要。
|
|
78
|
-
|
|
79
|
-
### 步骤五:成果审查与知识沉淀 (Review & Sync)
|
|
80
|
-
* **动作**:
|
|
81
|
-
1. 审查目录结构是否乱序。
|
|
82
|
-
2. 审查代码是否简洁(无冗余)。
|
|
83
|
-
3. **关键动作**: 提醒用户将本次成功的逻辑路径、新发现的坑点,记录到 **知识图谱软件** 的对应节点中。
|
|
84
|
-
* **输出**: 最终交付确认 + 知识图谱更新建议(简述需要记录的逻辑点)。
|
|
85
|
-
|
|
86
|
-
---
|
|
87
|
-
|
|
88
|
-
## 3. 异常处理机制
|
|
89
|
-
* 若**步骤四**测试失败:
|
|
90
|
-
1. 立即停止,不进行任何借口辩解。
|
|
91
|
-
2. 分析日志,回溯到**步骤二**修正逻辑图。
|
|
92
|
-
3. 修改代码后重新测试,直到通过。
|
|
93
|
-
|
|
94
|
-
---
|