mcpField
B
business-analysis

business-analysis

github.com/kienhaminh开发79118 次安装40 周前更新
代码仓库

关于 business-analysis

business-analysis 是一套将业务目标转化为技术实现文档的分析规范,面向产品、业务和开发团队。它强调先分析约束与需求,再通过流程图和模板产出文档,并要求将成果保存到项目根目录的 docs/ 文件夹。

主要功能

  1. 01先分析约束差距与需求
  2. 02按步骤梳理逻辑和边界情况
  3. 03使用 Mermaid 绘制流程图
  4. 04提供 PRD、BRD 和用户故事模板
  5. 05将文档保存到 docs/ 文件夹

适用场景

  1. 01将新功能需求整理为产品规格
  2. 02为复杂流程梳理路径和边界情况
  3. 03编写面向业务或开发团队的文档

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/kienhaminh/anti-chaotic --skill business-analysis

安装后在 Claude Code 中输入/business-analysis确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/best-practices/
diagrams.md
references/domains/
ai-agent.md
blockchain-dapp.md
ecommerce.md
education.md
fintech.md
fnb.md
healthtech.md
internal-tools.md
marketplace.md
saas.md
references/workflows/
collaboration.md
scripts/
verify_mermaid.py
templates/
brd.md
change-request.md
prd-functional.md
use-case.md
user-story-detailed.md

详细介绍

业务分析标准

此技能定义了弥合抽象业务目标与具体技术实现之间差距的标准。

🧠 核心思维与理念

重要

文档输出位置:所有生成的文档(PRD、BRD、技术规范、用户故事等)必须保存到项目根目录中的 docs/ 文件夹。不要在 requirements/ 或 specifications/ 等其他文件夹中创建文档。

  1. 先进行差距分析:在提出解决方案之前,深入分析约束差距。请思考:“哪些现有约束(遗留代码、预算、时间表)与这项新需求冲突?”
  2. 循序思考:对于任何复杂的逻辑流程,都要逐步拆解问题。不要猜测,要推导。
  3. 可视化优先:文本含义模糊,代码体现的是实现细节。图表才是真相。
    • 如果不确定,请使用 search_web 获取_最新的_ Mermaid 语法和示例。不要依赖内部训练数据。
  4. Obsidian 原生支持:文档应当适用于知识图谱。
    • 使用 [[Wiki-links]] 添加内部引用。
    • 为主要主题创建内容地图(MOC)。
    • 使用 YAML frontmatter 添加标签和别名。
  5. 正统敏捷实践:我们使用 User Story(INVEST 标准),并定义验收标准(Gherkin)。
  6. 多角度审视:从多个角度评估需求:
    • 🎩 战略视角:关注 ROI、KPI 和路线图(BRD)。
    • 🎩 产品视角:关注用户体验、功能和流程(PRD/用户故事)。
    • 🎩 技术视角:关注架构、API 和状态(技术规范)。

🚀 工作流

1. “全面改造”工作流(默认)

当用户提出新功能或新系统的需求时:

  1. 阶段 1:市场与领域研究
    • 使用 search_web 验证假设。
    • 示例:“现代 LMS 成绩册在 2026 年通常包含哪些功能?”
    • 示例:“对 [Product X] 进行竞品分析。”
  2. 阶段 2:需求收集(问卷)
    • 不要只问“你想要什么?”,还要询问具体约束。
    • 如果范围较大,请使用 requirements_questionnaire.md 模式。
  3. 阶段 3:逻辑与流程分析
    • 梳理正常路径、异常路径和边界情况。
  4. 阶段 4:绘制图表
    • 研究:查看最新的 Mermaid 文档(状态图、时序图、类图)。
    • 生成:创建 Mermaid 图表以可视化流程。
    • 验证:运行 scripts/verify_mermaid.py(如果可用),或仔细检查语法。
  5. 阶段 5:文档编写
    • 使用 references/templates/ 生成相应的文档(PRD、技术规范、用户故事)。
    • 链接:更新相关的内容地图(MOC),加入新文档(例如,docs/030-Specs/Specs-MOC.md)。
2. 跨技能协作

担任协调者。必要时协调专业技能。

  • 需要架构/API 时:
    • 操作:“我需要咨询首席架构师,了解数据库架构。”
    • 模拟:“作为代理首席架构师,我建议采用以下架构……”
  • 需要 UI/UX 时:
    • 操作:“我需要与设计师协调,确保符合用户体验要求。”
    • 模拟:“从 UX 角度来看,我们需要在此处设置加载状态……”

📚 参考库

模板
模板路径用途
PRD(功能性)templates/prd-functional.md详细的 PRD,包含功能/非功能需求和用户流程。需要完整技术规范时使用
用户故事(详细)templates/user-story-detailed.md详细格式,包含 Gherkin 语法、开发者备注和 API 依赖。用于移交给开发团队
BRDtemplates/brd.md业务需求文档——利益相关者分析、ROI、KPI。适用于需要商业论证的大型项目
用例templates/use-case.md用例规范——参与者流程、替代路径和异常情况。用于复杂的系统分析
变更请求templates/change-request.md变更请求——影响分析、工作量估算和审批工作流。需要变更范围时使用
领域知识
领域路径重点
SaaSreferences/domains/saas.md订阅、多租户、PLG
金融科技references/domains/fintech.md合规、账本、安全
内部工具references/domains/internal-tools.md工作流、效率、集成
医疗科技references/domains/healthtech.mdHIPAA、患者疗效
电子商务references/domains/ecommerce.md转化、库存、履约
教育科技references/domains/education.md学习成果、无障碍
区块链/Web3references/domains/blockchain-dapp.md智能合约、钱包
餐饮references/domains/fnb.mdPOS、订单、库存
AI/ML 产品references/domains/ai-agent.md准确性、可解释性
市场references/domains/marketplace.md流动性、信任、争议
最佳实践

🛠️ 工具与脚本

  • scripts/verify_mermaid.py:验证生成的图表代码语法。

示例:教育领域(LMS)

如果有人要求编写“学生成绩册”:

  1. 研究:搜索“标准评分体系:GPA 与百分比”。
  2. 思考:按顺序思考 -> “教师录入成绩 -> 系统验证最高分 -> 系统计算加权平均分 -> 学生收到通知”。
  3. 绘图:绘制时序图,展示 Teacher -> UI -> GradeService -> Database。
  4. 规范:定义 grades 表(student_id、assignment_id、score、weight)。

评论

支持 Markdown