qubership-apihub-backend

Build the APIHub backend, start it locally with local_config, author or extend a Postman/Newman E2E collection under tests/api covering the change, run it, and analyze and fix failures. Use after implementing a non-trivial backend change, before finishing the task, to verify it end-to-end against a real running instance.

Implements and modifies the APIHub Go backend (qubership-apihub-service): controllers, services, repositories, entities, migrations, Service.go wiring, ErrorCodes, and OpenAPI specs. Use when adding or changing backend features, REST endpoints, SQL migrations, repository queries, or Go code in qubership-apihub-backend.

Reviews APIHub backend code changes against project standards (AGENTS.md, rules, development guide). Use when the user asks for self-review, code review of a diff, or post-implementation check before commit or PR in qubership-apihub-backend. Invoke explicitly after another agent or model wrote the code.

Implements and modifies the APIHub Go backend (qubership-apihub-service): controllers, services, repositories, entities, migrations, Service.go wiring, ErrorCodes, and OpenAPI specs. Use when adding or changing backend features, REST endpoints, SQL migrations, repository queries, or Go code in qubership-apihub-backend.

Implements and modifies Go backend services in the APIHub ecosystem (controllers, services, repositories, entities, migrations, wiring, and OpenAPI). Use when adding or changing backend features, REST endpoints, SQL migrations, repository queries, or Go code in APIHub Go repositories.

Reviews Go backend code changes against project standards (AGENTS.md, rules, development guide). Use when the user asks for self-review, code review of a diff, or post-implementation check before commit or PR. Invoke explicitly after another agent or model wrote the code.

Plan implementation from a GitHub ticket by clarifying missing requirements, asking explicit questions for ambiguities, analyzing the codebase, and producing a concrete execution plan. After manual approval, publish the approved plan as a comment on the GitHub issue. Use when the user asks to plan work from a GitHub issue, ticket, or task description.

Decide whether a backend change requires follow-up in qubership-apihub-postman-collections (Newman E2E) and remind the developer with concrete actions. Use after REST or OpenAPI contract changes in the backend — not when authoring collections inside the Postman repo itself.