architecture-design
系统架构设计方法论,包含架构模式选择、系统分层、目录结构设计
竞品调研和分析方法,通过系统性分析竞品的功能、体验和策略,发现差异化机会
$ npx -y skills add echoVic/boss-skill --skill competitive-analysis --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/competitive-analysisContext preview
The summary Claude sees to decide when to auto-load this skill.
竞品调研和分析方法,通过系统性分析竞品的功能、体验和策略,发现差异化机会
name: pm/competitive-analysis description: 竞品调研和分析方法,通过系统性分析竞品的功能、体验和策略,发现差异化机会 version: 1.0.0 agent: pm type: methodology user-invocable: false agent-invocable: true dependencies: [] triggers: - 需要了解市场竞争格局时 - 寻找产品差异化机会时 - 验证需求假设时
在产品设计前或迭代时,需要了解市场上已有的解决方案,学习竞品的优点,发现竞品的不足,找到差异化机会。
**直接竞品**:解决相同问题、服务相同用户的产品 **间接竞品**:解决相似问题或服务相似用户的产品 **潜在竞品**:未来可能进入该领域的产品
**识别方法**:
对每个竞品,从以下5个维度进行分析:
| 分析点 | 问题 | |--------|------| | 核心功能 | 主要解决什么问题? | | 功能广度 | 覆盖了哪些场景? | | 功能深度 | 每个功能做到什么程度? | | 功能缺失 | 用户期望但没有的功能? |
| 分析点 | 问题 | |--------|------| | 易用性 | 新用户能快速上手吗? | | 流畅度 | 完成任务的步骤多吗? | | 视觉设计 | 界面美观吗?符合用户审美吗? | | 交互设计 | 交互符合直觉吗?有惊喜吗? | | 性能表现 | 加载快吗?响应及时吗? |
| 分析点 | 问题 | |--------|------| | 目标用户 | 主要服务哪类用户? | | 用户评价 | 用户喜欢什么?抱怨什么? | | 用户规模 | 有多少用户?增长如何? | | 用户粘性 | 用户活跃度如何?留存如何? |
| 分析点 | 问题 | |--------|------| | 商业模式 | 如何赚钱? | | 定价策略 | 价格如何?用户接受度如何? | | 市场定位 | 高端还是大众? | | 竞争优势 | 核心壁垒是什么? |
| 分析点 | 问题 | |--------|------| | 技术架构 | 使用什么技术栈? | | 技术创新 | 有技术上的创新吗? | | 技术限制 | 技术上有什么局限? |
使用 `WebFetch` 深入分析竞品后,整理为对比表格:
| 竞品 | 核心功能 | 用户体验亮点 | 用户痛点 | 我们的机会 | |------|----------|--------------|----------|------------| | [竞品 1] | [功能] | [亮点] | [痛点] | [机会] | | [竞品 2] | [功能] | [亮点] | [痛点] | [机会] | | [竞品 3] | [功能] | [亮点] | [痛点] | [机会] |
**关键要点**:
基于竞品分析,制定差异化策略:
| 维度 | 竞品做法 | 我们的做法 | 差异化价值 | |------|----------|------------|------------| | [维度 1] | [做法] | [做法] | [价值] | | [维度 2] | [做法] | [做法] | [价值] |
**差异化维度示例**:
**搜索竞品**:
"{功能} tools"
"best {功能} software 2026"
"{竞品名} alternatives"
"{竞品名} vs {竞品名}"**搜索用户评价**:
"{竞品名} review"
"{竞品名} pros and cons"
"{竞品名} reddit" (Reddit上的真实讨论)**搜索行业趋势**:
"{行业} trends 2026"
"{行业} market report"**深度分析竞品**: 1. 访问竞品官网,了解产品定位和核心功能 2. 访问竞品定价页面,了解商业模式 3. 访问用户评价网站(如 G2, Capterra),了解用户反馈 4. 访问竞品博客,了解产品演进方向
**提示词示例**:
"总结这个产品的核心功能、目标用户和主要优势" "提取用户评价中的主要痛点和亮点" "分析这个产品的差异化策略"
完成竞品调研后,应输出以下内容(通常作为PRD的第3章):
| 竞品 | 核心功能 | 用户体验亮点 | 用户痛点 | 我们的机会 | |------|----------|--------------|----------|------------| | [竞品 1] | [功能] | [亮点] | [痛点] | [机会] | | [竞品 2] | [功能] | [亮点] | [痛点] | [机会] | | [竞品 3] | [功能] | [亮点] | [痛点] | [机会] |
| 维度 | 竞品做法 | 我们的做法 | 差异化价值 | |------|----------|------------|------------| | [维度 1] | [做法] | [做法] | [价值] | | [维度 2] | [做法] | [做法] | [价值] |
1. **不只看功能,更看体验**:功能相同,体验可以差很多 2. **不只看产品,更看用户**:用户怎么说比产品怎么说更重要 3. **不只看现在,更看趋势**:理解竞品的演进方向 4. **不只学习,更要超越**:学习亮点,避免痛点,创造惊喜
❌ **只看功能列表**:功能多不代表体验好 ❌ **只看官网宣传**:要看真实用户评价 ❌ **只看头部竞品**:小而美的产品也有值得学习的地方 ❌ **照搬竞品**:要理解背后的逻辑,而不是简单模仿
Languages / 语言 / 言語 / 언어 / Idiomas / Langues: English · 中文 · 日本語 · 한국어 · Español · Français · Português Boss is an auditable agent-team workflow for coding agents.
Repo: echoVic/boss-skill
系统架构设计方法论,包含架构模式选择、系统分层、目录结构设计
数据模型和API设计方法论,包含ERD设计、数据字典、RESTful API规范
后端API开发方法论,包括RESTful/GraphQL设计、请求验证、错误处理和安全实现
后端测试编写指南,包括单元测试、集成测试和E2E测试的编写方法和最佳实践
需求澄清 Skill。当用户只给了模糊描述时自动触发,通过业务提问把一句话翻译成完整需求,交给 Boss 流水线执行。 Triggers: '我想做一个', '帮我做', '有个想法', 'brainstorm', '帮我规划一下', '做个XX', 'I want to build' Does NOT…