数据分析
- 作者仓库星标 1,187
- 叉子 185
- 作者更新于 2026年6月14日 10:01
- 作者仓库 claude-code-skills
- 领域
- 通用
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @daymade · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS · Linux · Windows
- 底层运行要求
- Node.js · Python
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: competitors-analysis
description: Analyze competitor repositories with evidence-based approach. Use when tracking competitors, cre…
category: 通用
runtime: Node.js / Python
---
# competitors-analysis 输出预览
## PART A: 任务判断
- 适用问题:通用任务拆解、检查和交付。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“CRITICAL: Evidence-Based Analysis Only / Pre-Analysis Checklist / Forbidden Patterns (禁止的表述)”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于通用任务拆解、检查和交付,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“CRITICAL: Evidence-Based Analysis Only / Pre-Analysis Checklist / Forbidden Patterns (禁止的表述)”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件。
先用一个小任务确认它会围绕“CRITICAL: Evidence-Based Analysis Only / Pre-Analysis Checklist / Forbidden Patterns (禁止的表述)”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: competitors-analysis
description: Analyze competitor repositories with evidence-based approach. Use when tracking competitors, cre…
category: 通用
source: daymade/claude-code-skills
---
# competitors-analysis
## 什么时候使用
- 避免竞品研究靠猜测,强制用真实代码取证分析 适合产品、研发、投研团队跟踪开源竞品,按克隆、读配置、查结构、摘证据的流程输出结论 要求每个技术细节附文件行号,禁止无来源判断 本地运行,依赖 Node 适合处理通用任务拆解、检查、交付和复盘…
- 面向通用任务拆解、检查和交付,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「CRITICAL: Evidence-Based Analysis Only / Pre-Analysis Checklist / Forbidden Patterns (禁止的表述)」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "competitors-analysis" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> CRITICAL: Evidence-Based Analysis Only / Pre-Analysis Checklist / Forbidden Patterns (禁止的表述)
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Node.js / Python | 读取文件、写入/修改文件 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Competitors Analysis
Evidence-based competitor tracking and analysis. All analysis must be based on actual code, never assumptions.
CRITICAL: Evidence-Based Analysis Only
在开始分析之前,必须完成以下检查:
Pre-Analysis Checklist
- 仓库已克隆到本地
~/Workspace/competitors/{product}/ - 可以
ls查看目录结构 - 可以
cat package.json(或等效配置文件) 读取版本信息 - 可以
git log -1确认代码是最新的
如果以上任何一项未完成,停止分析,先完成克隆操作。
Forbidden Patterns (禁止的表述)
| 禁止 | 原因 |
|---|---|
| "推测..."、"可能..."、"应该..." | 没有证据支持 |
| "架构图(推测版)" | 必须基于实际代码 |
| "未公开"、"未披露" | 如果不知道就不要写 |
| 不带来源的技术细节 | 无法验证 |
Required Patterns (必须的表述)
| 正确格式 | 示例 |
|---|---|
| 技术细节 + (来源: 文件:行号) | "使用 better-sqlite3 (来源: package.json:88)" |
| 直接引用 + 来源 | > "description text" (README.md:3) |
| 版本号 + 来源 | "版本 1.3.3 (package.json:2)" |
Analysis Workflow
Step 1: Clone Repository (必须)
# 创建产品竞品目录
mkdir -p ~/Workspace/competitors/{product-name}
# 克隆竞品仓库 (SSH,失败则重试)
cd ~/Workspace/competitors/{product-name}
git clone git@github.com:org/repo.git
网络问题处理: 中国网络环境可能需要多次重试。
Step 2: Gather Facts (收集事实)
按顺序读取以下文件,记录关键信息:
2.1 项目元数据
# Node.js 项目
cat package.json | head -20 # name, version, description
cat package.json | grep -A50 dependencies
# Python 项目
cat pyproject.toml # 或 setup.py, requirements.txt
# Rust 项目
cat Cargo.toml
2.2 项目结构
ls -la # 根目录结构
ls src/ # 源码目录
find . -name "*.md" -maxdepth 2 # 文档文件
2.3 核心模块
# 找到入口文件
cat main.js | head -50 # 或 index.js, app.py, main.rs
# 找到核心 helpers/utils
ls src/helpers/ 2>/dev/null || ls src/utils/ 2>/dev/null
2.4 README 和文档
cat README.md | head -100 # 官方描述
cat CHANGELOG.md | head -50 # 版本历史
Step 3: Deep Dive (深入分析)
针对关键技术点,读取具体实现文件:
# 示例:分析 ASR 实现
cat src/helpers/whisper.js # 读取完整文件
grep -n "class.*Manager" src/helpers/*.js # 找到核心类
记录格式:
| 文件 | 行号 | 发现 |
|------|------|------|
| whisper.js | 33-35 | 使用 WhisperServerManager |
Step 4: Write Profile (撰写分析)
使用 references/profile_template.md 模板,确保每个技术细节都有来源标注。
Step 5: Post-Analysis Verification (分析后验证)
自检清单:
- 所有版本号都有来源标注?
- 所有技术栈都来自 package.json/Cargo.toml?
- 架构描述基于实际代码结构?
- 没有"推测"、"可能"等词汇?
- 对比表中的竞品数据都有来源?
Directory Structure
~/Workspace/competitors/
├── flowzero/ # Flowzero 的竞品
│ ├── openwhispr/ # git clone 的仓库
│ └── ...
└── {product-name}/ # 其他产品
{project}/docs/competitors/
├── README.md # 索引(标注分析状态)
├── profiles/
│ └── {competitor}.md # 基于代码的分析
├── landscape/
├── insights/
└── updates/2026/
Templates and Checklists
| 文档 | 用途 |
|---|---|
| references/profile_template.md | 竞品分析报告模板 |
| references/analysis_checklist.md | 分析前/中/后检查清单 |
关键要求:
- 顶部必须标注数据来源路径和 commit hash
- 每个技术细节必须有 (来源: 文件:行号)
- 引用 README 内容必须标注行号
- 无法验证的标记为"待验证"并说明原因
- 分析完成后运行检查清单中的验证命令
Tech Stack Analysis Guide
Node.js / JavaScript
| 信息 | 来源文件 | 关键字段 |
|---|---|---|
| 版本 | package.json | version |
| 依赖 | package.json | dependencies, devDependencies |
| 入口 | package.json | main, scripts.start |
| 框架 | package.json | electron, react, vite 等 |
Python
| 信息 | 来源文件 | 关键字段 |
|---|---|---|
| 版本 | pyproject.toml | [project].version |
| 依赖 | pyproject.toml / requirements.txt | dependencies |
| 入口 | pyproject.toml | [project.scripts] |
Rust
| 信息 | 来源文件 | 关键字段 |
|---|---|---|
| 版本 | Cargo.toml | [package].version |
| 依赖 | Cargo.toml | [dependencies] |
Common Mistakes to Avoid
1. 跳过克隆直接分析
❌ 错误: 从 GitHub 网页或 WebFetch 获取信息后直接写分析
✅ 正确: 必须 git clone 到本地,用 Read 工具读取文件
2. 混合事实和推测
❌ 错误:
## 技术栈
- Electron (推测基于桌面应用特征)
- 可能使用了 React
✅ 正确:
## 技术栈 (来源: package.json)
| 依赖 | 版本 | 来源 |
|------|------|------|
| electron | 36.9.5 | package.json:68 |
| react | 19.1.0 | package.json:96 |
3. 使用过时信息
❌ 错误: 分析时不检查 git log,使用过时的代码
✅ 正确: 分析前运行 git pull,记录分析时的 commit hash
4. 对比表中竞品数据无来源
❌ 错误:
| 维度 | 竞品 | 我们 |
|------|------|------|
| 支持语言 | 25种 | 58种 |
✅ 正确:
| 维度 | 竞品 | 来源 | 我们 |
|------|------|------|------|
| 支持语言 | 25种 | modelRegistryData.json:9-35 | 58种 (FunASR 官方文档) |
Scripts
See scripts/update-competitors.sh for repository management.
./scripts/update-competitors.sh clone # 克隆所有竞品
./scripts/update-competitors.sh pull # 更新所有竞品
./scripts/update-competitors.sh status # 检查状态
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核