Menu
从PRD文档体系中提取功能点矩阵。当用户想要提取功能点、识别功能需求或分析业务功能时调用此Skill。支持中文触发：提取功能点、功能点提取、PRD分析、需求拆解。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | pdd-extract-features |
| description | 从PRD文档体系中提取功能点矩阵。当用户想要提取功能点、识别功能需求或分析业务功能时调用此Skill。支持中文触发：提取功能点、功能点提取、PRD分析、需求拆解。 |
从业务分析结果和PRD文档中提取功能点,生成标准化的功能点矩阵。
输入: 业务分析报告/PRD文档 | 输出: feature-matrix.md(功能点矩阵) | 不负责: 规格编写/代码实现
Extract feature points from business analysis results and PRD documents, generating a standardized feature matrix.
Input: Business Analysis Report/PRD Document | Output: feature-matrix.md (Feature Matrix) | Not Responsible For: Specification writing/Code implementation
| 复杂度 | 代码 | 说明 | 开发时间 | 人工参与 |
|---|---|---|---|---|
| 核心业务 | P0 | 核心业务流程,涉及多方审批 | 3-5天 | 高 |
| 重要功能 | P1 | 重要业务功能,有替代方案 | 1-2天 | 中 |
| 辅助功能 | P2 | 辅助性功能,易于实现 | 0.5天 | 低 |
| Complexity | Code | Description | Dev Time | Human Involvement |
|---|---|---|---|---|
| Core Business | P0 | Core business process, multi-party approval | 3-5 days | High |
| Important Feature | P1 | Important business function, has alternatives | 1-2 days | Medium |
| Auxiliary Function | P2 | Auxiliary feature, easy to implement | 0.5 day | Low |
C(Create新增) | R(Read查询/详情) | U(Update修改) | D(Delete删除) | B(Batch批量操作) | A(Approve审批流程) | E(Export数据导出) | F(Flow状态流转)
C (Create) | R (Read/Detail) | U (Update) | D (Delete) | B (Batch Operations) | A (Approval Process) | E (Data Export) | F (Status Flow/Transition)
AI-L(AI主导/低参与度) | AI-C(AI与人工协作/中参与度) | AI-R(AI辅助审核/高参与度)
AI-L (AI-led/Low human involvement) | AI-C (AI collaboration/Medium involvement) | AI-R (AI-assisted review/High involvement)
从业务分析报告中提取: 主要参与者 | 用例名称 | 基本流程 | 扩展流程
Extract from business analysis report: Main Actors | Use Case Name | Basic Flow | Alternative Flows
对每个用例识别操作(用例/操作/操作类型/复杂度/AI角色)
Identify operations for each use case (Use Case/Operation/Operation Type/Complexity/AI Role)
功能点/页面路径/API路径/方法
Feature Point/Page Path/API Path/Method
# [模块名称] 功能点矩阵
## 功能点汇总
| 功能点ID | 功能名称 | 页面/接口 | 操作类型 | 复杂度 | AI角色 | 依赖功能 | 前端组件类型 | 关联数据源 |
|---------|---------|----------|---------|--------|--------|---------|------------|-----------|
| FP-001 | 发起转让申请 | form.vue | C | P0 | AI-C | - | Form+Select+DatePicker | /departments/options, /assets/options |
| FP-002 | 查看转让申请 | detail.vue | R | P1 | AI-L | FP-001 | Detail+StatusTag | - |
前端组件类型说明:
关联数据源说明:
/{module}/options[?filter=params]# [Module Name] Feature Matrix
## Feature Summary
| Feature ID | Feature Name | Page/API | Operation Type | Complexity | AI Role | Dependencies | Frontend Component | Related Data Source |
|-----------|-------------|----------|---------------|------------|---------|--------------|-------------------|---------------------|
| FP-001 | Initiate Transfer Request | form.vue | C | P0 | AI-C | - | Form+Select+DatePicker | /departments/options, /assets/options |
| FP-002 | View Transfer Request | detail.vue | R | P1 | AI-L | FP-001 | Detail+StatusTag | - |
Frontend Component Types:
Related Data Source:
/{module}/options[?filter=params]对每个P0功能点生成详情:
Generate details for each P0 feature point:
# [模块名称] 功能点矩阵
## 矩阵信息
| 模块编号 | 模块名称 | 生成日期 | 版本 |
## 功能点汇总表
### 按复杂度统计: P0(N个) | P1(N个) | P2(N个)
### 按操作类型统计: C/R/U/D/A/E/F 各N个
## 详细功能点列表
| 功能点ID | 功能名称 | 页面/接口 | 操作 | 复杂度 | AI角色 | 依赖 | 测试策略 | 前端组件 | 关联数据源 |
# [Module Name] Feature Matrix
## Matrix Information
| Module ID | Module Name | Generated Date | Version |
## Feature Summary Table
### By Complexity: P0 (N) | P1 (N) | P2 (N)
### By Operation Type: C/R/U/D/A/E/F each N items
## Detailed Feature List
| Feature ID | Feature Name | Page/API | Operation | Complexity | AI Role | Dependencies | Test Strategy | Frontend Component | Related Data Source |
必须遵守: 功能点ID全局唯一 | 每个功能点必须有明确的操作类型 | 必须标注功能点依赖关系 | P0功能点必须有详细描述
避免事项: ❌ 功能点遗漏关键业务操作 | ❌ 依赖关系形成循环 | ❌ 复杂度评估与实际不符
Must Follow: Feature IDs must be globally unique | Each feature point must have a clear operation type | Feature dependencies must be explicitly declared | P0 features must have detailed descriptions
Avoid: ❌ Missing key business operations in feature points ❌ Circular dependencies ❌ Complexity assessment does not match reality
| 协作技能 | 协作方式 | 传入数据 | 期望输出 |
|---|---|---|---|
| pdd-ba | Sequential | 业务分析报告 | 用例和流程 |
| pdd-generate-spec | Sequential | 功能点矩阵 | spec.md |
| Collaborating Skill | Collaboration Mode | Input Data | Expected Output |
|---|---|---|---|
| pdd-ba | Sequential | Business Analysis Report | Use cases and flows |
| pdd-generate-spec | Sequential | Feature Matrix | spec.md |
审核节点: 功能点矩阵生成完成后需要进行人工审核
审核内容: 功能点完整性(是否覆盖所有业务功能) | 复杂度评估(P0/P1/P2是否合理) | 测试策略(是否完整) | 依赖关系(是否正确)
审核粒度:
输出文件: review-features.md | 结果类型: passed / rejected / conditional
Review Point: Human review is required after feature matrix generation
Review Content: Feature completeness (covers all business functions) | Complexity assessment (P0/P1/P2 reasonableness) | Test strategy completeness | Dependency correctness
Review Granularity:
Output File: review-features.md | Result Types: passed / rejected / conditional
来源可追溯: 每个功能点必须能追溯到业务分析报告中的具体用例或PRD文档的明确章节,不得凭空创造功能点。
粒度适中: 功能点粒度应保持在"单个可验收的工作单元"级别,过粗(一个FP包含多个独立功能)或过细(将一个操作的步骤拆分为多个FP)都是违规的。
依赖关系显式化: 功能点之间的依赖关系必须明确声明,不得隐含依赖;循环依赖是绝对禁止的。
复杂度评估有据可依: P0/P1/P2的评估必须有明确的判断标准(如涉及审批流程、外部系统集成、核心业务规则等),不得凭感觉随意定级。
完整性通过MECE验证: 提取完成后必须使用MECE原则检验:所有用例的操作是否都被覆盖?是否有遗漏的辅助功能(如导入导出、批量操作)?
违规示例: ❌ 创建了无法追溯到任何用例的功能点 | ❌ 将"用户管理"作为一个功能点(粒度过粗) | ❌ 将"填写表单第一步/第二步"拆分为两个FP(粒度过细) | ❌ 循环依赖(A→B→A) | ❌ 全部标为P0或全部标为P2
合规示例: ✅ 每个功能点都标注了"源自UC-xxx" | ✅ FP-001对应"发起申请"这一完整操作 | ✅ 明确标注FP-005(审批)依赖于FP-001(申请) | ✅ P0判定理由:"涉及多级审批工作流和状态机转换" | ✅ 使用MECE清单检验后确认覆盖全部CRUD操作
Traceable Source: Every feature point must be traceable to a specific use case in the business analysis report or a clear section in the PRD document. Feature points must not be created out of thin air.
Appropriate Granularity: Feature point granularity should be maintained at the "single acceptable work unit" level. Both too coarse (one FP containing multiple independent functions) and too fine (splitting steps of one operation into multiple FPs) are violations.
Explicit Dependencies: Dependencies between feature points must be explicitly declared. Implicit dependencies are not allowed. Circular dependencies are absolutely prohibited.
Evidence-Based Complexity Assessment: P0/P1/P2 assessments must have clear judgment criteria (e.g., involving approval processes, external system integration, core business rules, etc.). Arbitrary classification based on feeling is not allowed.
Completeness Verified via MECE: After extraction, MECE principle must be used for verification: Are all use case operations covered? Are there missing auxiliary functions (such as import/export, batch operations)?
Violation Examples: ❌ Created feature points that cannot be traced to any use case | ❌ Treated "User Management" as a single feature point (too coarse granularity) | ❌ Split "Fill Form Step 1/Step 2" into two FPs (too fine granularity) | ❌ Circular dependency (A→B→A) | ❌ Marked everything as P0 or everything as P2
Compliance Examples: ✅ Each feature point is labeled "Source: UC-xxx" | ✅ FP-001 corresponds to "Initiate Request" as a complete operation | ✅ Clearly marked FP-005 (Approval) depends on FP-001 (Request) | ✅ P0 justification: "Involves multi-level approval workflow and state machine transitions" | ✅ Confirmed full CRUD coverage after MECE checklist verification
| # | 陷阱 | 请问自己 | 应该怎么做 |
|---|---|---|---|
| 1 | "这个功能太小了,不值得单独列为FP" / "This feature is too small to be a separate FP" | 即使小的功能也是独立的交付单元,遗漏会导致验收盲区 | 保持统一粒度标准,只要是独立可验收的操作就应列为FP |
| 2 | "PRD里没写但我觉得应该有这个功能" / "The PRD doesn't mention this but I think it should exist" | 需求外推是有风险的,可能引入不必要的工作量 | 标记为"建议功能"并单独列出,请用户确认是否纳入 |
| 3 | "依赖关系太复杂了,先不管吧" / "Dependencies are too complex, let's ignore them for now" | 缺失依赖关系会导致实施顺序错误和集成问题 | 至少标注直接依赖,复杂的传递依赖可在实施阶段细化 |
| 4 | "全部标为P0吧,这样比较保险" / "Let's mark everything as P0, just to be safe" | P0泛滥会让真正重要的功能失去优先级标识的意义 | 严格按评估标准分级,确保P0数量合理(通常不超过总数的30%) |
| 5 | "测试策略后面再想" / "We'll figure out test strategy later" | 测试策略是功能点定义的重要组成部分,影响后续验证工作 | 为每个P0功能点至少定义正向和异常两个测试场景 |
常见陷阱:
| # | Trap | Ask Yourself | Action |
|---|---|---|---|
| 1 | "This feature is too small to be a separate FP" | Even small features are independent delivery units; omission leads to acceptance blind spots | Maintain consistent granularity; any independently acceptable operation should be listed as an FP |
| 2 | "The PRD doesn't mention this but I think it should exist" | Requirement extrapolation is risky and may introduce unnecessary workload | Mark as "suggested feature" and list separately; ask user to confirm inclusion |
| 3 | "Dependencies are too complex, let's ignore them for now" | Missing dependencies cause implementation sequence errors and integration issues | At least mark direct dependencies; complex transitive dependencies can be refined during implementation |
| 4 | "Let's mark everything as P0, just to be safe" | P0 inflation makes truly important features lose priority significance | Strictly classify by assessment criteria; ensure reasonable P0 count (typically ≤30% of total) |
| 5 | "We'll figure out test strategy later" | Test strategy is an integral part of feature definition, affecting subsequent verification work | Define at least positive and exception test scenarios for each P0 feature |
Common Traps:
🔴 CRITICAL → 立即停止,报告问题详情,等待指示 | 🟡 WARN → 记录警告到提取日志,尝试自动修复,在最终报告中标注 | 🔵 INFO → 记录信息,正常继续
🔴 CRITICAL → Stop immediately, report problem details, await instructions | 🟡 WARN → Log warning to extraction log, attempt auto-fix, note in final report | 🔵 INFO → Record information, continue normally
"PDD框架下的业务分析Skill，运用专业方法论进行需求分析和业务建模。当用户输入/analyze、/audit、/doc等命令，或需要对业务流程、管理制度、Excel表单进行专业分析时触发。支持中文触发：业务分析、需求分析、需求建模、5W1H分析、MECE、流程分析。"
"PDD熵减智能体，持续监控和偿还技术债务，防止系统腐化。当用户需要代码清理、文档更新、技术债务管理、架构对齐、熵减、垃圾回收、清理技术债务时自动触发。即使用户只说'熵减'、'清理技术债务'或'垃圾回收'，也应触发此Skill。支持中文触发：熵减、技术债务、代码清理、文档更新、架构对齐、垃圾回收。"
根据开发规格实现功能点代码的核心Skill。当用户想要开始编码实现、根据规格文档生成代码、实现功能点时调用此Skill。此Skill会自动调用pdd-template-engine生成基础代码框架，然后由software-engineer补充业务逻辑。即使只有规格文档没有明确说'实现'，只要涉及代码生成、功能开发，都应触发此Skill。支持中文触发：实现功能点、编码实现、开始编码、功能开发、代码实现、PDD实现。
PRD驱动开发的主入口Skill，协调整个开发流程。当用户想要基于PRD文档进行功能开发、从需求文档生成代码、执行PDD方法论流程、开发业务模块、实现完整功能、'搞个功能'、'资产转让'、'国有产权转让'、'帮我搞个资产转让的功能'时必须调用此Skill。即使用户没有明确说'使用PDD'，只要涉及PRD文档、需求文档、功能点开发、规格文档、模块开发、根据文档开发、业务功能实现、'开发ZCCZ'、'我想开发'、'搞个功能'等场景，都应触发此Skill。此Skill会自动协调pdd-ba、pdd-extract-features、pdd-generate-spec、pdd-implement-feature等子Skill完成从需求分析到代码交付的完整流程。注意：单一接口设计、调试问题、文档查询等场景不应触发此Skill。支持中文触发：PRD驱动开发、PDD开发、功能开发、启动PDD。
"交通事故责任评估与判定专业技能。当用户需要交通事故责任分析、事故现场照片评估、交通法规咨询、事故责任划分、法律依据查询时触发此技能。适用于车辆碰撞事故、行人事故、非机动车事故等各类道路交通事故的责任认定场景。无论用户使用'交通事故'、'车祸'、'责任判定'、'交通法规'、'事故定责'等何种表述，只要涉及交通事故评估或责任认定，均应调用此技能。支持中文触发：交通事故、车祸、责任判定、交通法规、事故定责、责任划分、事故评估、追尾、碰撞、违章、赔偿。"
自动化重构专家技能，将收集到的质量改进任务转化为具体的代码操作。当用户需要代码重构、消除重复、简化复杂度时自动触发。即使用户只说'重构代码'、'消除重复'或'简化代码'，也应触发此Skill。支持中文触发：重构代码、消除重复、简化复杂度、自动重构、代码重构、PDD重构。