mcp-probe-kit 1.8.0 → 1.8.1

package/docs/specs/add-feature/requirements.md

@@ -1,175 +0,0 @@
-# 需求文档：add_feature
-
-## 功能概述
-
-`add_feature` 是一个 MCP 工具，用于在已有项目中添加新功能的规格文档。该工具会生成标准化的需求文档、设计文档和任务清单，遵循 Spec-Driven Development 方法论。
-
-## 术语定义
-
-- **Feature_Spec**: 功能规格，包含需求、设计和任务三个文档
-- **Requirements_Document**: 需求文档，使用 EARS 格式描述功能需求
-- **Design_Document**: 设计文档，描述技术方案和架构设计
-- **Tasks_Document**: 任务文档，将设计分解为可执行的任务清单
-- **EARS_Format**: Easy Approach to Requirements Syntax，一种结构化的需求描述格式
-- **Project_Context**: 项目上下文，由 init_project_context 工具生成的项目信息
-
----
-
-## 需求列表
-
-### 需求 1: 生成功能规格文档
-
-**用户故事:** 作为开发者，我想要自动生成功能规格文档，以便按照标准化流程开发新功能。
-
-#### 验收标准
-
-1. WHEN 用户调用 add_feature 工具并提供功能名称和描述 THEN 系统 SHALL 返回详细的文档生成指南
-2. THE 指南 SHALL 指导 AI 生成以下三个文件：
-   - `docs/specs/{feature_name}/requirements.md`
-   - `docs/specs/{feature_name}/design.md`
-   - `docs/specs/{feature_name}/tasks.md`
-3. THE 指南 SHALL 包含每个文档的标准化模板
-4. THE 指南 SHALL 包含质量检查清单
-
----
-
-### 需求 2: 读取项目上下文
-
-**用户故事:** 作为开发者，我想要生成的文档能够参考项目上下文，以便设计符合项目架构的方案。
-
-#### 验收标准
-
-1. THE 指南 SHALL 指导 AI 首先读取 `docs/project-context.md`
-2. IF 项目上下文文件不存在 THEN 指南 SHALL 提示用户先运行 `init_project_context`
-3. THE 指南 SHALL 说明如何利用项目上下文信息生成更准确的文档
-
----
-
-### 需求 3: 使用 EARS 格式编写需求
-
-**用户故事:** 作为开发者，我想要需求文档使用标准化的 EARS 格式，以便需求清晰、可测试。
-
-#### 验收标准
-
-1. THE requirements.md 模板 SHALL 使用 EARS 格式
-2. THE 模板 SHALL 包含以下 EARS 模式的说明和示例：
-   - Ubiquitous: THE [system] SHALL [response]
-   - Event-driven: WHEN [trigger], THE [system] SHALL [response]
-   - State-driven: WHILE [condition], THE [system] SHALL [response]
-   - Unwanted: IF [condition], THEN THE [system] SHALL [response]
-   - Optional: WHERE [option], THE [system] SHALL [response]
-3. THE 模板 SHALL 包含用户故事格式说明
-
----
-
-### 需求 4: 生成设计文档
-
-**用户故事:** 作为开发者，我想要设计文档包含技术方案，以便实现时有明确的指导。
-
-#### 验收标准
-
-1. THE design.md 模板 SHALL 包含以下章节：
-   - 技术方案概述
-   - 架构设计（基于项目上下文）
-   - 数据模型（如需要）
-   - API 设计（如需要）
-   - 文件结构
-   - 依赖关系
-2. THE 模板 SHALL 指导 AI 参考项目现有架构
-3. THE 模板 SHALL 包含设计决策记录
-
----
-
-### 需求 5: 生成任务清单
-
-**用户故事:** 作为开发者，我想要任务清单将设计分解为可执行的步骤，以便按计划实施。
-
-#### 验收标准
-
-1. THE tasks.md 模板 SHALL 包含以下内容：
-   - 任务分阶段组织
-   - 每个任务有明确的目标和操作
-   - 任务之间的依赖关系
-   - 检查点
-2. THE 模板 SHALL 使用 Markdown 复选框格式
-3. THE 模板 SHALL 包含文件变更清单
-
----
-
-### 需求 6: 支持自定义参数
-
-**用户故事:** 作为开发者，我想要自定义文档目录，以便适应不同项目的结构。
-
-#### 验收标准
-
-1. WHEN 用户提供 docs_dir 参数 THEN 系统 SHALL 在指南中使用该目录路径
-2. WHEN 用户未提供 docs_dir 参数 THEN 系统 SHALL 使用默认值 "docs"
-3. THE feature_name 参数 SHALL 使用 kebab-case 格式
-4. THE description 参数 SHALL 用于生成用户故事和功能描述
-
----
-
-### 需求 7: 兼容多种 AI 模型
-
-**用户故事:** 作为工具开发者，我想要提示词能被多种 AI 模型正确理解，以便工具具有广泛的兼容性。
-
-#### 验收标准
-
-1. THE 指南 SHALL 使用清晰、无歧义的语言
-2. THE 指南 SHALL 使用结构化的 Markdown 格式
-3. THE 指南 SHALL 避免使用特定 AI 模型的术语
-4. THE 指南 SHALL 每个步骤都有明确的输入和输出
-5. THE 指南 SHALL 使用编号列表表示顺序步骤
-6. THE 指南 SHALL 使用代码块展示文件内容
-
----
-
-## 非功能需求
-
-### 性能要求
-- 工具响应时间应小于 100ms（仅返回指南文本）
-
-### 兼容性要求
-- 支持 Cursor、Gemini、Codex、Claude、GLM4.7 等主流 AI 模型
-- 支持 Windows、macOS、Linux 操作系统
-
-### 可维护性要求
-- 提示词模板应易于更新和维护
-- 文档模板应与 Spec-Driven Development 最佳实践保持同步
-
----
-
-## 输入输出规格
-
-### 输入参数
-
-| 参数名 | 类型 | 必填 | 默认值 | 描述 |
-|--------|------|------|--------|------|
-| feature_name | string | 是 | - | 功能名称（kebab-case 格式） |
-| description | string | 是 | - | 功能描述 |
-| docs_dir | string | 否 | "docs" | 文档存放目录 |
-
-### 输出格式
-
-```typescript
-{
-  content: [
-    {
-      type: "text",
-      text: "详细的文档生成指南（Markdown 格式）"
-    }
-  ]
-}
-```
-
----
-
-## 依赖关系
-
-- 建议先运行 `init_project_context` 生成项目上下文
-- 不强制依赖，但有上下文时生成的文档更准确
-
----
-
-*文档版本: 1.0.0*
-*创建时间: 2025-01-14*

package/docs/specs/add-feature/tasks.md

@@ -1,111 +0,0 @@
-# 任务清单：add_feature
-
-## 概述
-
-实现 `add_feature` MCP 工具，用于在已有项目中添加新功能的规格文档。
-
----
-
-## 任务列表
-
-### 阶段 1: 创建工具文件
-
-- [ ] 1.1 创建 `src/tools/add_feature.ts` 文件
-  - 创建文件结构
-  - 定义接口类型
-  - 实现参数验证
-  - 实现主函数框架
-  - _需求: 1.1, 6.1-6.4_
-
-- [ ] 1.2 编写提示词模板
-  - 实现完整的 PROMPT_TEMPLATE 常量
-  - 包含前置检查、三个文档模板、检查清单
-  - 包含 EARS 格式说明
-  - 确保兼容多种 AI 模型
-  - _需求: 1.2-1.4, 2.1-2.3, 3.1-3.3, 4.1-4.3, 5.1-5.3, 7.1-7.6_
-
----
-
-### 阶段 2: 注册工具
-
-- [ ] 2.1 在 `src/tools/index.ts` 中导出工具
-  - 添加 export 语句
-  - _需求: 1.1_
-
-- [ ] 2.2 在 `src/index.ts` 中注册工具
-  - 添加工具定义（name, description, inputSchema）
-  - 添加工具处理逻辑（switch case）
-  - 更新资源状态
-  - _需求: 1.1, 6.1-6.4_
-
----
-
-### 阶段 3: 更新文档
-
-- [ ] 3.1 更新 README.md
-  - 添加工具说明
-  - 添加使用示例
-  - 更新工具数量
-  - 添加工作流示例
-  - _需求: 1.1_
-
-- [ ] 3.2 更新 package.json
-  - 更新版本号
-  - 更新描述中的工具数量
-  - _需求: 1.1_
-
----
-
-### 阶段 4: 测试验证
-
-- [ ] 4.1 编译项目
-  - 运行 `npm run build`
-  - 确保无编译错误
-  - _需求: 1.1_
-
-- [ ] 4.2 功能测试
-  - 测试正常调用（提供所有参数）
-  - 测试自定义 docs_dir 参数
-  - 测试缺少必填参数的错误处理
-  - 验证返回的指南内容完整
-  - _需求: 1.1, 6.1-6.4_
-
-- [ ] 4.3 集成测试
-  - 在实际项目中测试完整流程
-  - 先运行 init_project_context
-  - 再运行 add_feature
-  - 验证生成的文档质量
-  - _需求: 2.1-2.3_
-
----
-
-## 检查点
-
-- [ ] 阶段 1 完成后：工具文件创建完成，提示词模板完整
-- [ ] 阶段 2 完成后：工具已注册，可以被调用
-- [ ] 阶段 3 完成后：文档已更新
-- [ ] 阶段 4 完成后：编译通过，功能正常，集成测试通过
-
----
-
-## 文件变更清单
-
-| 文件 | 操作 | 说明 |
-|------|------|------|
-| src/tools/add_feature.ts | 新建 | 工具实现 |
-| src/tools/index.ts | 修改 | 添加导出 |
-| src/index.ts | 修改 | 注册工具 |
-| README.md | 修改 | 添加文档 |
-| package.json | 修改 | 更新描述和版本 |
-
----
-
-## 依赖任务
-
-- 建议先完成 `init_project_context` 工具
-- 两个工具可以独立使用，但配合使用效果更好
-
----
-
-*任务版本: 1.0.0*
-*创建时间: 2025-01-14*

package/docs/specs/estimate/design.md

@@ -1,209 +0,0 @@
-# 设计文档：estimate
-
-## 概述
-
-`estimate` 采用"提示词生成器"模式，返回工作量估算指南，由 AI 根据任务描述和上下文进行分析估算。
-
----
-
-## 技术方案
-
-### 估算模型
-
-采用三点估算法（PERT）：
-- 乐观时间 (O): 最理想情况
-- 正常时间 (M): 最可能情况
-- 悲观时间 (P): 最坏情况
-- 期望时间 = (O + 4M + P) / 6
-
-### 复杂度评估维度
-
-```typescript
-const COMPLEXITY_FACTORS = {
-  code_volume: {
-    description: "代码量",
-    levels: {
-      1: "< 50 行",
-      2: "50-200 行",
-      3: "200-500 行",
-      4: "500-1000 行",
-      5: "> 1000 行"
-    }
-  },
-  technical_difficulty: {
-    description: "技术难度",
-    levels: {
-      1: "简单 CRUD",
-      2: "常规业务逻辑",
-      3: "复杂算法/集成",
-      4: "新技术/架构变更",
-      5: "核心系统重构"
-    }
-  },
-  dependency: {
-    description: "依赖复杂度",
-    levels: {
-      1: "无外部依赖",
-      2: "1-2 个模块",
-      3: "3-5 个模块",
-      4: "跨团队协作",
-      5: "外部系统集成"
-    }
-  },
-  testing: {
-    description: "测试复杂度",
-    levels: {
-      1: "简单单测",
-      2: "常规测试",
-      3: "集成测试",
-      4: "E2E 测试",
-      5: "性能/安全测试"
-    }
-  }
-};
-```
-
-### 故事点映射
-
-```typescript
-const STORY_POINTS = {
-  1: { hours: "1-2h", description: "微小改动" },
-  2: { hours: "2-4h", description: "小改动" },
-  3: { hours: "4-8h", description: "中等任务" },
-  5: { hours: "1-2d", description: "较大任务" },
-  8: { hours: "2-3d", description: "大任务" },
-  13: { hours: "3-5d", description: "需要拆分" }
-};
-```
-
----
-
-## 架构设计
-
-### 工具结构
-
-```
-src/tools/estimate.ts
-├── estimate(args)               # 主函数
-│   ├── 验证参数
-│   ├── 构建估算指南
-│   └── 返回结果
-└── 常量定义
-    ├── COMPLEXITY_FACTORS       # 复杂度因子
-    ├── STORY_POINTS             # 故事点映射
-    └── PROMPT_TEMPLATE          # 提示词模板
-```
-
----
-
-## 提示词模板设计
-
-```markdown
-# 工作量估算指南
-
-## 🎯 估算目标
-
-**任务描述**: {task_description}
-
-**上下文信息**:
-- 团队规模: {team_size}
-- 经验水平: {experience_level}
-
-## 📋 估算步骤
-
-### 步骤 1: 任务分解
-
-将任务分解为以下活动：
-1. 需求理解和设计
-2. 编码实现
-3. 单元测试
-4. 代码审查
-5. 集成测试
-6. 文档更新
-
-### 步骤 2: 复杂度评估
-
-对每个维度打分（1-5）：
-
-| 维度 | 评分 | 说明 |
-|------|------|------|
-| 代码量 | ? | 预估新增/修改行数 |
-| 技术难度 | ? | 涉及的技术复杂程度 |
-| 依赖复杂度 | ? | 涉及的模块和系统 |
-| 测试复杂度 | ? | 需要的测试类型和覆盖 |
-
-### 步骤 3: 时间估算
-
-使用三点估算法：
-
-| 场景 | 时间 | 说明 |
-|------|------|------|
-| 乐观 (O) | ?h | 一切顺利 |
-| 正常 (M) | ?h | 预期情况 |
-| 悲观 (P) | ?h | 遇到问题 |
-
-**期望时间** = (O + 4M + P) / 6 = ?h
-
-### 步骤 4: 故事点
-
-根据估算时间选择故事点：
-- 1 点: 1-2 小时
-- 2 点: 2-4 小时
-- 3 点: 4-8 小时
-- 5 点: 1-2 天
-- 8 点: 2-3 天
-- 13 点: 3-5 天（建议拆分）
-
-### 步骤 5: 风险识别
-
-识别可能影响估算的风险：
-- [ ] 技术风险
-- [ ] 依赖风险
-- [ ] 需求风险
-- [ ] 资源风险
-
-## 📊 输出模板
-
-### 估算结果
-
-**故事点**: X 点
-**预估时间**: X-X 小时/天
-**置信度**: 高/中/低
-
-### 复杂度分析
-[复杂度评分表]
-
-### 时间分解
-| 活动 | 时间 |
-|------|------|
-| 设计 | Xh |
-| 编码 | Xh |
-| 测试 | Xh |
-| 审查 | Xh |
-
-### 风险因素
-[风险列表和缓解措施]
-
-### 建议
-[任务拆分建议或其他建议]
-```
-
----
-
-## 接口设计
-
-```typescript
-interface EstimateArgs {
-  task_description: string;   // 必填
-  code_context?: string;      // 可选
-  team_size?: number;         // 可选，默认 1
-  experience_level?: string;  // 可选，默认 mid
-}
-
-async function estimate(args: EstimateArgs): Promise<MCPResponse>
-```
-
----
-
-*设计版本: 1.0.0*
-*创建时间: 2025-01-14*

package/docs/specs/estimate/requirements.md

@@ -1,140 +0,0 @@
-# 需求文档：estimate
-
-## 功能概述
-
-`estimate` 是一个 MCP 工具，用于评估开发任务的工作量。基于任务描述、代码复杂度和历史数据，提供时间估算和风险评估。
-
-## 术语定义
-
-- **Story_Point**: 故事点，敏捷开发中衡量工作量的单位
-- **Complexity**: 复杂度，任务的技术难度
-- **Risk_Factor**: 风险因子，可能导致延期的因素
-- **Confidence_Level**: 置信度，估算的可靠程度
-
----
-
-## 需求列表
-
-### 需求 1: 接收任务描述
-
-**用户故事:** 作为项目经理，我想要输入任务描述获得工作量估算，以便进行项目规划。
-
-#### 验收标准
-
-1. THE 工具 SHALL 接受以下输入参数：
-   - task_description: 任务描述（必填）
-   - code_context: 相关代码（可选）
-   - team_size: 团队规模（可选）
-   - experience_level: 经验水平（可选）
-2. WHEN 用户只提供 task_description THEN 工具 SHALL 给出基础估算
-3. WHEN 用户提供更多上下文 THEN 工具 SHALL 给出更精准的估算
-
----
-
-### 需求 2: 分析任务复杂度
-
-**用户故事:** 作为开发者，我想要了解任务的复杂度分解，以便更好地理解工作内容。
-
-#### 验收标准
-
-1. THE 工具 SHALL 从以下维度分析复杂度：
-   - 代码量估算（新增/修改行数）
-   - 技术难度（1-5 级）
-   - 依赖复杂度（涉及的模块数）
-   - 测试复杂度
-   - 文档需求
-2. THE 工具 SHALL 给出复杂度评分和说明
-
----
-
-### 需求 3: 提供时间估算
-
-**用户故事:** 作为项目经理，我想要获得时间估算，以便安排项目进度。
-
-#### 验收标准
-
-1. THE 工具 SHALL 提供以下时间估算：
-   - 乐观估算（最快完成时间）
-   - 正常估算（预期完成时间）
-   - 悲观估算（最慢完成时间）
-2. THE 工具 SHALL 提供故事点估算（1/2/3/5/8/13）
-3. THE 工具 SHALL 说明估算依据
-
----
-
-### 需求 4: 识别风险因素
-
-**用户故事:** 作为项目经理，我想要了解潜在风险，以便提前制定应对措施。
-
-#### 验收标准
-
-1. THE 工具 SHALL 识别以下风险类型：
-   - 技术风险（新技术、复杂算法）
-   - 依赖风险（外部依赖、团队协作）
-   - 需求风险（需求不明确、可能变更）
-   - 测试风险（难以测试、边界情况多）
-2. THE 工具 SHALL 为每个风险提供缓解建议
-
----
-
-### 需求 5: 任务分解建议
-
-**用户故事:** 作为开发者，我想要获得任务分解建议，以便更好地规划工作。
-
-#### 验收标准
-
-1. WHEN 估算时间超过 8 小时 THEN 工具 SHALL 建议任务分解
-2. THE 工具 SHALL 提供子任务列表
-3. THE 工具 SHALL 为每个子任务提供单独估算
-
----
-
-### 需求 6: 提供置信度评估
-
-**用户故事:** 作为项目经理，我想要了解估算的可靠程度，以便决定是否需要更多信息。
-
-#### 验收标准
-
-1. THE 工具 SHALL 提供置信度评分（高/中/低）
-2. THE 工具 SHALL 说明影响置信度的因素
-3. WHEN 置信度为低 THEN 工具 SHALL 建议需要补充的信息
-
----
-
-## 非功能需求
-
-### 性能要求
-- 工具响应时间应小于 100ms
-
-### 准确性要求
-- 估算应基于行业最佳实践
-- 应考虑常见的开发活动（编码、测试、代码审查、文档）
-
----
-
-## 输入输出规格
-
-### 输入参数
-
-| 参数名 | 类型 | 必填 | 默认值 | 描述 |
-|--------|------|------|--------|------|
-| task_description | string | 是 | - | 任务描述 |
-| code_context | string | 否 | - | 相关代码或文件 |
-| team_size | number | 否 | 1 | 团队规模 |
-| experience_level | string | 否 | mid | 经验水平（junior/mid/senior） |
-
-### 输出格式
-
-```typescript
-{
-  content: [{
-    type: "text",
-    text: "工作量估算报告（Markdown 格式）"
-  }]
-}
-```
-
----
-
-*文档版本: 1.0.0*
-*创建时间: 2025-01-14*

package/docs/specs/estimate/tasks.md

@@ -1,66 +0,0 @@
-# 任务清单：estimate
-
-## 概述
-
-实现 `estimate` MCP 工具，用于开发任务工作量估算。
-
----
-
-## 任务列表
-
-### 阶段 1: 创建工具文件
-
-- [x] 1.1 创建 `src/tools/estimate.ts` 文件
-  - 创建文件结构
-  - 定义接口类型
-  - 实现参数验证
-  - 实现主函数框架
-  - _需求: 1.1-1.3_
-
-- [x] 1.2 编写提示词模板
-  - 实现 PROMPT_TEMPLATE 常量
-  - 包含任务分解指南
-  - 包含复杂度评估维度
-  - 包含三点估算法说明
-  - 包含故事点映射表
-  - 包含风险识别清单
-  - _需求: 2.1-6.3_
-
----
-
-### 阶段 2: 注册工具
-
-- [x] 2.1 在 `src/tools/index.ts` 中导出工具
-  - 添加 export 语句
-
-- [x] 2.2 在 `src/index.ts` 中注册工具
-  - 添加工具定义（name, description, inputSchema）
-  - 添加工具处理逻辑（switch case）
-
----
-
-### 阶段 3: 测试验证
-
-- [x] 3.1 编译项目
-  - 运行 `npm run build`
-  - 确保无编译错误
-
-- [ ] 3.2 功能测试
-  - 测试简单任务估算
-  - 测试复杂任务估算
-  - 测试任务分解建议
-
----
-
-## 文件变更清单
-
-| 文件 | 操作 | 说明 |
-|------|------|------|
-| src/tools/estimate.ts | 新建 | 工具实现 |
-| src/tools/index.ts | 修改 | 添加导出 |
-| src/index.ts | 修改 | 注册工具 |
-
----
-
-*任务版本: 1.0.0*
-*创建时间: 2025-01-14*