mcpField
A
apidog-workflow-api-lifecycle

apidog-workflow-api-lifecycle

github.com/apidog开发352 次安装16 周前更新
代码仓库

关于 apidog-workflow-api-lifecycle

用于在 Apidog 中管理 API 变更的工作流技能，覆盖需求、测试、报告和分支交付。它强调查阅当前 CLI 架构，并逐步验证已保存资源。

主要功能

  1. 01设计 API 端点和架构
  2. 02配置环境与变量
  3. 03添加测试用例和 Mock
  4. 04运行测试并检查报告
  5. 05准备分支变更以供交付

适用场景

  1. 01将需求或 API 定义转为 Apidog 资源
  2. 02添加测试并验证 API 变更
  3. 03在分支上准备 API 变更以供合并

安装

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

$npx skills add https://github.com/apidog/apidog-cli-skills --skill apidog-workflow-api-lifecycle

安装后在 Claude Code 中输入/apidog-workflow-api-lifecycle确认已加载。

详细介绍

API 生命周期工作流

开始前，请阅读 ../apidog-cli/SKILL.md。如果稳定版入口技能与此工作流冲突，请以当前 CLI 帮助和此工作流为准。按需阅读 apidog-branch、apidog-import-export 和 apidog-test-case。对于复杂的测试流程，请阅读 apidog-test-scenario；对于执行和 CI，请阅读 apidog-test-automation。

使用当前 CLI 帮助查看端点、架构、环境、测试报告及相关命令。此工作流涵盖从需求到 API 资源、测试、报告和分支合并的端到端交付。重点关注资源顺序、质量门禁和交付验证。Agent 应构建 help/schema -> get -> validate -> write -> run/report 循环，而不是根据旧文档或记忆编写内容。

适用场景

  • 根据需求创建或更新一组 API。
  • 导入 OpenAPI/Postman，然后整理 API、架构、文件夹和测试。
  • 根据代码、PRD、需求文档、测试文档或讨论生成 API 规范，并将其导入 Apidog。
  • 为 API 添加 Mock、测试用例、文档和发布设置。
  • 在 AI 分支上完成 API 更改并准备合并。

工作流

Confirm project/branch
  -> if importing from code/docs, generate spec and run quality gates
  -> design endpoints and schemas
  -> configure environments and variables
  -> configure mocks
  -> create API test cases
  -> run tests and inspect reports
  -> export/publish docs
  -> merge or create MR

第 1 步：确认上下文

使用当前 CLI 帮助确认身份、项目、目标分支，以及是否需要 AI 分支。

  • 如果用户希望直接编辑 main 或 sprint 分支，请确认 AI 写入权限，或使用 AI 分支。
  • 如果要通过 AI 分支编辑现有资源，请先使用 branch pick-to 导入源资源。

第 2 步：设计 API 资源

使用当前 CLI 帮助查看端点、架构、响应组件、安全方案、文件夹及相关 API 设计命令。

最低边界：endpoint 是 API 定义；test-case 是端点下的测试用例。不要将两者混为一谈。应先创建架构、响应组件和安全方案等可复用资源，再由端点引用。不要将环境变量写入公共参数。

如果任务是根据代码、PRD 或文档生成并导入 API 规范，请先阅读 ../apidog-import-export/SKILL.md。完成生成器搜索、OpenAPI 指标、标签分组和临时项目验证后，再开始 API 设计或添加测试。

  • 在引用可复用的 schema、response-component、security-scheme 等资源之前，先创建它们。
  • 创建后，务必运行 endpoint get，验证实际保存的结构。

第 3 步：配置环境

使用当前 CLI 帮助查看环境、变量、数据库连接、保险库及相关运行时上下文命令。

  • 如果没有合适的环境，请创建或更新一个。
  • 最终回复中不要暴露敏感变量。
  • 对于测试运行和 CI 交付，请显式传入 --environment，以避免默认环境更改导致结果不可复现。

第 4 步：添加测试用例

阅读 ../apidog-test-case/SKILL.md。

  • 不要创建空壳用例。
  • 创建后，运行 test-case get，验证步骤、断言和提取器均已保存。

第 5 步：验证并交付

  • 对于报告问题，先区分本地报告、云端上传和已下载的摘要；必要时切换到 apidog-cli-checkup。
  • 对于客户端显示问题，切换到 apidog-cli-checkup。
  • 如果需要合并，切换到 apidog-branch。
  • 如果新 API 的测试返回 404 或断言失败，请先检查 Mock/环境配置。Mock 配置问题不等同于 API 设计资源未保存。

不得违反的规则

  1. 不要跳过项目/分支确认。
  2. 不要直接写入受保护的 main 分支。
  3. 创建端点后，必须验证其已保存的结构。
  4. 不要创建空测试用例。
  5. 不要将测试失败视为 API 创建失败；应分别诊断 API 定义、环境、测试用例和执行报告。

评论

支持 Markdown