@guru-ai-product/ai-product-kit 0.2.251117192248 → 0.2.251118120602

package/mcp/.doc_cache/d604a1290099121c_/351/234/200/346/261/202/345/217/230/345/212/250/350/257/264/346/230/216/347/224/237/346/210/220/346/214/207/345/215/227.md

@@ -1,292 +0,0 @@
-# 需求变动说明文档生成指南
-
-## 一、目标
-
-为两个git commit之间的需求文档变更生成一份详细的变动说明文档，帮助团队成员快速了解：
-
-- 哪些文档发生了变化
-- 具体新增、修改、删除了什么内容
-- 每个变动的具体位置（可点击跳转）
-- 变动对开发和产品的影响
-
-## 二、准备工作
-
-### 2.1 确定对比版本
-
-```bash
-# 查看最近的commit历史
-git log --oneline -20
-
-# 确定要对比的两个commit
-# 例如：90cad63 (旧版本) 和 HEAD (新版本)
-```
-
-### 2.2 获取变更信息
-
-```bash
-# 查看两个版本之间的所有文件变更
-git diff --stat <旧commit>..<新commit>
-
-# 查看文件状态（新增A、修改M、删除D）
-git diff --name-status <旧commit>..<新commit>
-
-# 查看具体文件的变更
-git diff <旧commit>..<新commit> -- "路径/文件名.md"
-
-# 查看commit历史
-git log --oneline <旧commit>..<新commit>
-```
-
-### 2.3 收集文档结构信息
-
-```bash
-# 获取文档的章节结构（使用grep）
-grep "^## |^### |^#### " 文件路径.md
-
-# 查找特定内容的行号
-grep -n "关键词" 文件路径.md
-```
-
-## 三、生成步骤
-
-### 3.1 创建文档基本信息
-
-1. **文档命名**：`YYYYMMDD_需求文档变动说明_<旧commit>至<新commit>.md`
-2. **标题设置**：
-   - 主标题：说明涉及的版本
-   - 副标题：标注变动周期和对比版本
-
-### 3.2 编写变动概述（第1节）
-
-包含内容：
-
-- 对比版本信息（commit号、日期、提交信息）
-- 变动周期（起止日期、天数）
-- 总体变动统计（文件数、行数、新增文档数）
-
-### 3.3 记录Commit历史（第2节）
-
-对每个commit记录：
-
-- Commit号和日期
-- 提交信息
-- 变更文件列表及行数统计
-
-### 3.4 详细分析文档变动（第3节）
-
-**分版本说明**（如v2.0.0、v2.1.0）：
-
-#### 对于修改的文档
-
-- 添加文档链接
-- 标注变动量（+X行 / -Y行）
-- **新增内容**：列出新增的章节、功能点，并链接到具体行号
-- **修改内容**：说明优化和调整的部分，并链接到具体行号
-- **删除内容**：说明删除的内容及原因
-
-#### 对于新增的文档
-
-- 添加文档链接
-- 标注文档规模（总行数）
-- 列出文档包含的主要章节，每个章节链接到具体行号
-- 标注功能类型（如：新功能、商业化优化、用户运营等）
-
-### 3.5 功能维度分析（第4节）
-
-#### 核心新功能（4.1）
-
-对每个新功能：
-
-- 添加文档链接
-- 功能定位（创作能力、用户留存、商业化等）
-- **新增内容**：详细列出功能模块，链接到文档具体位置
-- **技术要求**：列出技术实现要点，链接到相关章节
-- **开发复杂度**：预估工作量
-
-#### 核心功能优化（4.2）
-
-对优化的功能：
-
-- 添加文档链接
-- **新增部分**：列出新增内容及行号链接
-- **修改部分**：列出修改内容及行号链接
-- **删除部分**：说明删除内容
-- **开发影响**：预估工作量
-
-### 3.6 产品策略分析（第5节）
-
-- 功能战略定位（创作能力、用户增长、商业化）
-- 版本演进路径（各版本的定位和重点）
-
-### 3.7 附录信息（第6节）
-
-- 完整变更文件清单
-- 变动统计汇总表
-- Commit详情
-- 查看差异的git命令
-- 文档结构树状图
-
-## 四、关键要点
-
-### 4.1 链接格式
-
-**文件链接**：
-
-```markdown
-📄 查看文件 (./文件名.md)
-📄 查看完整文档 (../v2.1.0/文件名.md)
-```
-
-**章节行号链接**：
-
-```markdown
-📍 功能说明 → `章节名称:行号` (./文件名.md#L行号)
-📍 详细设计 → `3.1.1 页面设计:156` (./文件名.md#L156)
-```
-
-### 4.2 使用图标
-
-- 📄 文件链接
-- 📍 位置链接（行号）
-- ⭐⭐⭐ 重要程度标识
-- ✅ 完成状态
-- 🔵 系统操作
-- 🟢 用户操作
-- 🟡 判断节点
-
-### 4.3 表格格式
-
-```markdown
-| 类型 | 数量 | 行数 |
-|------|------|------|
-| 修改文档 | 2个 | +471/-102 |
-| 新增文档 | 3个 | 1196行 |
-| **合计** | **5个** | **+1725/-112** |
-```
-
-### 4.4 代码块格式
-
-```markdown
-```bash
-git diff --stat 90cad63..HEAD
-```
-
-```
-
-## 五、质量检查清单
-
-- [ ] 所有修改的文档都有详细的新增、修改、删除说明
-- [ ] 重要功能点都有具体的行号链接
-- [ ] 所有链接都可以正确跳转
-- [ ] 章节序号连续无误
-- [ ] 统计数据准确（文件数、行数）
-- [ ] Commit信息完整（hash、日期、作者、提交信息）
-- [ ] 文档结构清晰，易于阅读
-- [ ] 使用了适当的图标和格式化
-- [ ] 包含了开发工作量预估
-- [ ] 提供了产品策略分析
-
-## 六、AI Prompt 示例
-
-```
-
-请看下当前<版本目录>的需求和<commit-hash>这个commit的差异，
-并形成一个变动说明文档。
-
-要求：
-
-1. 对比这两个commit之间的所有文件变化
-2. 详细说明每个文档的新增、修改、删除内容
-3. 所有的修改说明希望能链接到具体的位置（文件名和行号）
-4. 删除第5、7、8节，在第3、4节中具体说明变动、新增、去除
-5. 使用📄表示文件链接，📍表示位置链接
-6. 生成统计表格汇总变动情况
-7. 章节序号要连续正确
-8. 在标题上增加对比的两段日期的说明
-
-```
-
-## 七、工具和技巧
-
-### 7.1 快速获取章节结构
-
-```bash
-# 获取二级标题
-grep "^## " 文件.md
-
-# 获取三级标题
-grep "^### " 文件.md
-
-# 获取所有标题并显示行号
-grep -n "^#" 文件.md
-```
-
-### 7.2 快速定位关键词
-
-```bash
-# 查找关键词并显示行号
-grep -n "关键词" 文件.md
-
-# 查找关键词并显示上下文
-grep -C 3 "关键词" 文件.md
-```
-
-### 7.3 批量处理
-
-```bash
-# 查看多个文件的变更
-for file in $(git diff --name-only 90cad63..HEAD -- "../../requirements"); do
-  echo "=== $file ==="
-  git diff --stat 90cad63..HEAD -- "$file"
-done
-```
-
-## 八、常见问题
-
-### Q1: 如何确定重要程度？
-
-A: 根据以下标准：
-
-- ⭐⭐⭐ 新增重要功能、重大修改（>300行）
-- ⭐⭐ 中等功能优化、新增文档（100-300行）
-- ⭐ 小幅优化、格式调整（<100行）
-
-### Q2: 链接失效怎么办？
-
-A:
-
-- 确保行号准确（使用grep -n查找）
-- 相对路径要正确（同目录./，上级目录../）
-- GitHub渲染需要使用#L前缀
-
-### Q3: 如何处理删除的文件？
-
-A:
-
-- 在变更清单中标注[已删除]
-- 说明删除原因
-- 如有替代方案，说明替代文件
-
-### Q4: 如何预估开发工作量？
-
-A: 考虑因素：
-
-- 功能复杂度（界面、交互、算法）
-- 技术依赖（新技术、第三方库）
-- 接口数量
-- 测试难度
-- 一般按2-3人日/100行代码估算
-
-## 九、示例参考
-
-参考文档：
-
-- `20251017_需求文档变动说明_90cad63至fa5a716.md`
-
-该文档展示了完整的变动说明格式，包括：
-
-- 清晰的文档结构
-- 详细的变动说明
-- 完整的链接系统
-- 准确的统计数据
-- 有价值的分析内容

package/mcp/.doc_cache/d66edce025de6b82_Draft_/344/272/247/345/223/201/351/234/200/346/261/202/350/215/211/347/250/277.md

@@ -1,60 +0,0 @@
-# 产品需求草稿 (Draft)
-
-## 1. 核心问题
-
-**我们要解决什么问题？**
-[用一句话描述用户的核心痛点或需求]
-
-**谁会为这个问题付费？**
-[描述目标用户，1-2句话]
-
-## 2. 产品形态
-
-**我们要做什么类型的产品？**
-
-- [ ] 移动应用 (iOS/Android)
-- [ ] Web应用
-- [ ] 桌面应用
-- [ ] 小程序
-- [ ] 其他：[具体说明]
-
-**为什么选择这个形态？**
-[用一句话说明选择理由，如用户习惯、技术优势、分发渠道等]
-
-## 3. 解决方案
-
-**我们的核心价值是什么？**
-[用一句话描述用户使用产品后能获得什么价值]
-
-**核心功能（最多3个）**：
-
-1. **[功能名称]**：[一句话描述做什么]
-2. **[功能名称]**：[一句话描述做什么]  
-3. **[功能名称]**：[一句话描述做什么]
-
-## 4. 商业模式
-
-**如何赚钱？**
-
-- [ ] 广告 (IAA)
-- [ ] 付费功能 (IAP)
-- [ ] 订阅
-- [ ] 其他：[具体说明]
-
-**定价思路**：[简单描述，如免费+付费、订阅价格等]
-
-## 5. 关键指标
-
-| 指标 | 目标值 |
-|------|--------|
-| [核心指标1] | [目标] |
-| [核心指标2] | [目标] |
-
-## 6. 最大风险
-
-**最可能失败的原因是什么？**
-[描述1-2个最关键的风险点]
-
----
-
-**说明**：基于第一性原理的极简模板，专注最核心问题。确认后生成完整需求文档。

package/mcp/.doc_cache/d6c3ff791e7da726_SKILL.md

@@ -1,33 +0,0 @@
----
-name: design
-description: Central hub for automation-ready design workflows, describing how agents split composite boards, prep visual assets, sync requirement docs, and discover the right sub-skill before handling new mocks.
----
-
-# 设计阶段 Skill
-
-## 目标与适用范围
-
-- 统一收录设计交付相关的脚本化流程与指引，方便在需求或开发阶段前快速对齐视觉产出。
-- 为代理和协作者提供索引，指向符合 [`../skill_generate/SKILL.md`](../skill_generate/SKILL.md) 规范的子 Skill。
-- 当你需要处理视觉拆分、素材入库、设计变更对齐时，先查阅此处的列表，再加载对应子 Skill。
-
-## 当前可用的设计 Skill
-
-- **Auto Panel Splitter**（`./auto_panel_splitter/`）
-  - 使用脚本批量切分合成设计图、生成映射 CSV、同步需求文档并输出变动说明。
-  - 包含 `./auto_panel_splitter/scripts/auto_panel_splitter.js` 与 `./auto_panel_splitter/scripts/panel_asset_mapper.js` 等自动化工具。
-
-如需扩展新的设计场景，请在 `skills/aipk_design/` 下创建子目录，按照模板完成 `SKILL.md`、`references/` 等结构，并在本文件的“当前可用的设计 Skill”中登记用途与入口路径。
-
-## 使用方式
-
-1. **识别任务**：确认是面向设计交付的哪一类动作（拆 panel、生成 asset、审查视觉差异等）。
-2. **查找子 Skill**：在上方列表定位可复用方案；若缺失，请提出需求或新建 Skill。
-3. **加载并执行**：打开子 Skill 的 `SKILL.md` 阅读流程，或在 MCP 代理中加载该目录以自动索引规则。
-4. **回写产出**：按子 Skill 指示更新需求文档、变动记录或素材库，并在 `AGENTS.md` 约定的进度追踪方式中记录状态。
-
-## 维护指引
-
-- 当脚本或流程更新时，先在对应子 Skill 中调整，再同步这里的描述，确保索引不失效。
-- 撰写/更新任何设计 Skill 时，遵循 [`../guide_writing_standard/SKILL.md`](../guide_writing_standard/SKILL.md) 的写作与标记规则。
-- 设计流程若影响需求、开发或发布阶段，及时在相关 Skill 中留下引用或注意事项，保持跨阶段信息一致。

package/mcp/.doc_cache/da2c3d4d7b8957af_SKILL.md

@@ -1,218 +0,0 @@
----
-name: requirements-review
-description: AI-assisted review workflow for validating requirement documents against quality and risk criteria.
----
-
-# 需求评审
-
-## 概述
-
-本指南专门用于指导如何使用 AI 工具进行需求文档评审，基于《需求文档》中的评审章节，提供标准化的 AI 评审流程和检查清单。
-
-## 第一部分：AI 需求评审 Prompt 模板
-
-### AI 角色设定与评审框架
-
-```
-你是一位资深产品经理，拥有丰富的产品需求分析和评审经验。请基于提供的需求文档，从以下维度进行全面分析和评审：
-
-**评审维度：**
-
-1. **清晰性评审**
-   - 语言表述是否简洁明了，避免模糊和歧义
-   - 术语使用是否标准化和一致
-   - 是否提供了具体的例子和场景说明
-
-2. **完整性评审**
-   - 是否覆盖了所有必要的产品方面
-   - 边界条件和异常情况是否充分考虑
-   - 约束和限制是否明确说明
-
-3. **可验证性评审**
-   - 需求是否可测试和可量化
-   - 验收标准是否明确具体
-   - 是否避免了主观和无法量化的描述
-
-4. **一致性评审**
-   - 文档内部逻辑是否一致
-   - 与其他产品文档是否保持一致
-   - 格式和模板使用是否统一
-
-5. **风险评估**
-   - 识别潜在的技术风险和业务风险
-   - 评估需求的可行性和实现难度
-   - 分析需求之间是否存在冲突或矛盾
-
-**评审输出要求：**
-
-请按照以下结构提供评审结果：
-
-### 总体评价
-- 文档质量等级：[优秀/良好/需改进/不合格]
-- 核心问题摘要
-
-### 详细评审结果
-
-#### 1. 清晰性问题
-- [具体问题描述]
-- [改进建议]
-
-#### 2. 完整性问题
-- [具体问题描述]
-- [改进建议]
-
-#### 3. 可验证性问题
-- [具体问题描述]
-- [改进建议]
-
-#### 4. 一致性问题
-- [具体问题描述]
-- [改进建议]
-
-#### 5. 风险识别
-- [技术风险]
-- [业务风险]
-- [风险缓解建议]
-
-### 优先级建议
-- 必须修改：[高优先级问题列表]
-- 建议修改：[中优先级问题列表]
-- 可选优化：[低优先级问题列表]
-
-### 后续行动建议
-- [具体的改进步骤和建议]
-
----
-
-**请基于以上框架，对以下需求文档进行评审：**
-
-[在此处粘贴需求文档内容]
-```
-
-## 第二部分：需求评审 Checklist
-
-### 基础质量检查
-
-#### 文档结构与格式
-
-- [ ] 文档标题、版本、作者等基本信息完整
-- [ ] 文档结构清晰，章节划分合理
-- [ ] 使用统一的格式和模板
-- [ ] 术语表完整且标准化
-
-#### 产品战略一致性
-
-- [ ] 需求是否符合产品目标和策略？
-- [ ] 与产品愿景和核心价值主张是否一致？
-- [ ] 目标用户定义是否清晰准确？
-
-### 需求质量检查
-
-#### 清晰性检查
-
-- [ ] 需求是否清晰、具体且无歧义？
-- [ ] 语言表述是否简洁明了？
-- [ ] 是否提供了具体的例子和场景？
-- [ ] 术语使用是否一致和标准化？
-
-#### 完整性检查
-
-- [ ] 是否所有必要的功能都已包含？
-- [ ] 边界条件和异常情况是否充分考虑？
-- [ ] 约束和限制是否明确说明？
-- [ ] 非功能需求是否充分定义？
-
-#### 可验证性检查
-
-- [ ] 需求是否可测试和可量化？
-- [ ] 验收标准是否明确具体？
-- [ ] 是否避免了主观和无法量化的描述？
-- [ ] 成功指标是否可衡量？
-
-#### 一致性检查
-
-- [ ] 需求之间是否存在冲突或矛盾？
-- [ ] 文档内部逻辑是否一致？
-- [ ] 与其他产品文档是否保持一致？
-- [ ] 优先级设置是否合理？
-
-### 可行性与风险评估
-
-#### 技术可行性
-
-- [ ] 需求是否可实现且符合技术约束？
-- [ ] 技术依赖是否明确识别？
-- [ ] 性能要求是否现实可达？
-- [ ] 安全和隐私要求是否充分考虑？
-
-#### 业务可行性
-
-- [ ] 优先级是否合理设置？
-- [ ] 资源需求是否现实？
-- [ ] 时间计划是否可行？
-- [ ] 成本效益是否合理？
-
-#### 风险识别
-
-- [ ] 是否识别了主要技术风险？
-- [ ] 是否识别了主要业务风险？
-- [ ] 是否提供了风险缓解措施？
-- [ ] 依赖关系是否清晰标识？
-
-### 用户体验检查
-
-#### 用户需求匹配
-
-- [ ] 是否真正解决了用户痛点？
-- [ ] 用户场景描述是否完整？
-- [ ] 用户流程是否合理顺畅？
-- [ ] 是否考虑了不同用户角色的需求？
-
-#### 交互设计
-
-- [ ] 用户界面要求是否明确？
-- [ ] 交互流程是否清晰？
-- [ ] 可用性要求是否充分？
-- [ ] 无障碍访问是否考虑？
-
-### 评审流程检查
-
-#### 利益相关者参与
-
-- [ ] 是否邀请了所有必要的利益相关者？
-- [ ] 产品、设计、开发、测试团队是否都参与？
-- [ ] 业务利益相关者是否参与？
-- [ ] 用户代表是否参与（如可能）？
-
-#### 评审记录
-
-- [ ] 评审意见是否完整记录？
-- [ ] 问题和建议是否明确分类？
-- [ ] 后续行动计划是否制定？
-- [ ] 责任人和时间节点是否明确？
-
-### 最终确认
-
-#### 质量标准
-
-- [ ] 文档是否达到发布标准？
-- [ ] 所有关键问题是否已解决？
-- [ ] 利益相关者是否达成共识？
-- [ ] 是否获得必要的批准？
-
-#### 后续计划
-
-- [ ] 变更管理流程是否建立？
-- [ ] 文档维护责任是否明确？
-- [ ] 后续评审计划是否制定？
-- [ ] 实施跟踪机制是否建立？
-
----
-
-**使用说明：**
-
-1. 在评审过程中逐项检查上述清单
-2. 对于未通过的项目，记录具体问题和改进建议
-3. 根据问题严重程度设定优先级
-4. 制定具体的改进行动计划
-5. 跟踪问题解决进度直至评审通过