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 readapifox-branch、apifox-import-export、apifox-test-case; when complex test flows are involved, readapifox-test-scenario; when execution and CI are involved, readapifox-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-toto 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 getverify 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 getverify 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
- Do not skip project/branch confirmation.
- Do not write directly to a protected main branch.
- Do not only create the interface without verifying the saved structure.
- Do not only create empty test cases.
- Do not treat test failures as interface creation failures; locate the API definition, environment, test cases, and execution report separately.