SuperAPI AI Directory

apifox-workflow-api-lifecycle

Coding & development

View repository

Updated 10-15 12:24

About this skill

API lifecycle workflow

Before starting, you must read ../apifox-cli/SKILL.md. If the old main entry point conflicts with the domain rules of this workflow, the current CLI help and this workflow take precedence. Follow the steps to then read apifox-branch、apifox-import-export、apifox-test-case; when complex test flows are involved, read apifox-test-scenario; when execution and CI are involved, read apifox-test-automation。

For specific endpoint, schema, environment, and test-report commands, the current CLI help takes precedence. This process is used for end-to-end delivery from requirements to API assets, tests, reports, and branch merging, with a focus on resource order, quality gates, and delivery verification. When executing, the Agent should first form a help/schema -> get -> validate -> write -> run/report closed loop, and must not write based only on old documentation or memory.

Applicable scenarios

  • Create or update a set of interfaces based on requirements.
  • After importing OpenAPI/Postman, organize interfaces, Schema, directories, and tests.
  • Generate an API spec from a codebase, PRD, requirements document, test document, or discussion content, then import it into Apifox.
  • Add Mock, test cases, documentation, and publish settings to interfaces.
  • Complete API changes on an AI branch and prepare to merge.

Workflow

确认项目/分支
  -> 如需从代码/文档导入,先做 spec 生成和质量门禁
  -> 设计接口和 Schema
  -> 配置环境和变量
  -> 配置 Mock
  -> 创建接口测试用例
  -> 运行测试并查看报告
  -> 导出/发布文档
  -> 合并或创建 MR

Step 1: Confirm context

Confirm identity, project, target branch, and whether an AI branch is needed according to the current CLI help.

  • When the user wants to directly modify the main branch/iteration branch, confirm AI write permissions or use an AI branch.
  • If modifying existing resources through an AI branch, first use branch pick-to to import the source resources.

Step 2: Design API resources

According to the current CLI help, use API design resource commands such as endpoint, schema, response-component, security-scheme, and folder.

Minimum boundaries: an endpoint is an interface definition, and a test-case is a test case under an interface; do not mix them. Reusable resources such as schema, response-component, and security-scheme should be created first and then referenced by endpoint; environment variables should not be written into common-parameter.

If the task is to generate and import an API spec from a codebase, PRD, or document, first read ../apifox-import-export/SKILL.md, complete generator search, OpenAPI metric validation, tags grouping, and temporary project import verification, then proceed to interface design or test supplementation.

  • First create reusable resources such as schema、response-component、security-scheme , then reference them in endpoint.
  • After creation, you must endpoint get verify the actual saved structure.

Step 3: Configure environment

According to the current CLI help, use environment and runtime context commands such as environment, variables, database-connection, and vault.

  • If there is no suitable environment, create or update an environment.
  • Sensitive variables must not appear in the final reply.
  • When running tests and CI delivery commands, it is recommended to explicitly include --environment, to avoid non-reproducibility caused by default environment changes.

Step 4: Supplement test cases

Read ../apifox-test-case/SKILL.md。

  • Do not create empty shell cases.
  • After creation, test-case get verify that steps, assertions, and extractors are saved.

Step 5: Verify and deliver

  • For test report anomalies, first distinguish between local reports, cloud uploads, and download summaries; if necessary, switch to apifox-cli-checkup。
  • For frontend display anomalies, switch to apifox-cli-checkup。
  • When merging is needed, switch to apifox-branch。
  • If a test run of a newly created API returns 404 or an assertion failure, first check whether the Mock/environment is configured; do not directly conclude that endpoint or test-case creation failed. A run failure caused by an unconfigured Mock is an execution environment issue and does not mean the design assets were not saved.

Non-violable rules

  1. Do not skip project/branch confirmation.
  2. Do not write directly to a protected main branch.
  3. Do not only create the interface without verifying the saved structure.
  4. Do not only create empty test cases.
  5. Do not treat test failures as interface creation failures; locate the API definition, environment, test cases, and execution report separately.