ADP Multimodal Generation

Problem

In Chinese business workflows, users may ask for image, video, or 3D model generation, while the backend may expose several ADP ability modules and model versions. If callers use raw identifiers or silently downgrade, requests can hit parameter mismatches, misclassified platform limits, or cross-modality substitutions. This skill normalizes Chinese intent into verified ADP multimodal abilities and executes them as asynchronous jobs.

How It Works

The supported modules are image.hy and image.gi for image generation, video.kling and video.vidu for video generation, and 3d.hy for 3D generation. Routing chooses the default ability: images default to image.hy, switch to image.gi when Gemini, nano banana, or another image model is requested; videos default to video.kling, switch to video.vidu when VIDU or another video model is requested; 3D remains 3d.hy. Only module aliases are accepted, not raw backend identifiers.

The flow has four steps: select the ability from user intent, choose a mode such as text2image, image2image, text2video, image2video, text23d, or image23d, execute the job through paired submit/query calls, and report the final ability, whether it was the default or keyword-triggered fallback, the failure stage if any, and platform limitations. It requires ADP_API_KEY and depends on requests.

Boundaries

This skill targets ADP platform multimodal abilities, not Tencent Cloud open APIs. Only fields verified in references/ability-catalog.md should be treated as confirmed facts. If an ability cannot be executed, report the blocker directly instead of silently downgrading across modalities, guessing internal interfaces, or swapping models without approval.