About this skill

Problem

Cross-border organ VA integrations often break down in signing, field documentation, callback verification, and production-like evidence. Interface tables contain many fields with scattered Chinese semantics, so hand-written DTOs can miss fields, mishandle enums, or serialize null keys into request bodies. If outbound tests mock the HTTP client, they may prove a service method was called without proving the real TLS, signing, serialization, and gateway response path works.

How It Works

The skill treats embedded-organ-va-chapter2-6-spec.md as the sole specification source and generates Chapter 2 through Chapter 6 integration code when the gcp-api-quick-integration signing base is available:
- DTOs / request and response models: every field carries Chinese documentation derived from the spec table’s “Chinese name” and “remarks” columns, without inventing fields.
- Business services and notify handlers: verification happens before parsing, and signing logic is reused rather than reimplemented.
- Real HTTP integration tests: outbound partner-to-provider interfaces get @SpringBootTest tests that must not mock the HTTP client.
- Naming and package isolation: code uses business-domain names instead of chapter2-style identifiers in classes, packages, or files.

Scope and Caveats

It is intended for Java/Spring-centric integrations where deliverable code must be ready for live debugging. Generated Java files should be UTF-8 without BOM, expose proper accessors or Lombok annotations, and avoid Java 8-incompatible APIs. If the signing base is missing, it must be established first; if only a subset of interfaces is requested, the omitted scope should be confirmed.

Screenshots

Use Cases

Add Chapter 2-6 organ VA DTOs, services, and notify handlers in a Java/Spring project.
Generate real HTTP integration tests for outbound provider calls without mocking the client.
Attach spec-based Chinese field comments and prevent null keys in outbound payloads.

Best For

Java backend engineers integrating payment channels who need code that can call the provider gateway for real.
Cross-border VA integration teams who need fields, comments, and tests placed under one clean package.
QA engineers verifying outbound payment links who need evidence of TLS, signing, and real HTTP responses.
Architects familiar with Allinpay GCP who want to reuse signing and callback verification.