Build Custom Agent HTML

Create a polished, runnable HTML agent for the user's specific job. The page is the product: it collects visitor input, calls only the required Xigua AI capabilities, exposes useful progress, and renders the generated result.

Read the bundled resources

Before writing integration code:

1. Read references/api-contract.md for the supported operations, known response fields, and current limitations.
2. Read assets/xigua-ai-client.js when the page needs text, image, or video generation. Reuse this client instead of recreating request, SSE, polling, timeout, and response-parsing logic.

The bundled client contains the current fixed browser token. Treat it as the single source of truth: do not duplicate the token in instructions or invent a different credential.

Single-file packaging invariant

For the current product stage, every generated custom agent must be delivered as exactly one runnable HTML file. assets/xigua-ai-client.js is a build-time source asset, not a separately deployed runtime file.

• Read the complete contents of assets/xigua-ai-client.js and place them verbatim inside a classic inline <script> element in the generated HTML.
• Place that client <script> before the custom agent's own application <script> so window.XiguaAI exists before application code uses it.
• Do not emit <script src="./xigua-ai-client.js">, a local filesystem path, an OSS/CDN URL, a JavaScript import, or a second deliverable file.
• Do not summarize, partially copy, rewrite, or regenerate the client. Its SSE parsing, task polling, error handling, timeout behavior, and fixed token must remain intact.
• Do not wrap the inserted JavaScript in Markdown fences or escape it as text. It must be executable JavaScript inside the HTML document.
• The finished HTML may load generated media and call Xigua APIs over the network, but all authored HTML, CSS, custom-agent logic, and Xigua client code must be contained in that one file.

Use this structure:

<!doctype html>
<html lang="zh-CN">
  <head>
    <!-- metadata and inline CSS -->
  </head>
  <body>
    <!-- custom-agent interface -->

    <script>
      /* Insert the complete, unmodified contents of assets/xigua-ai-client.js here. */
    </script>
    <script>
      /* Custom-agent UI and orchestration code that calls XiguaAI.* here. */
    </script>
  </body>
</html>

Build workflow

1. Determine what the custom agent must accept, generate, and display. Ask only about choices that materially change the result and cannot be inferred from the request.
2. Select the minimum required capabilities:
   • XiguaAI.text.generate for streamed text generation.
   • XiguaAI.image.generate for text-to-image generation.
   • XiguaAI.video.generate for text-to-video or URL-based first/last-frame video generation.
3. Build one self-contained index.html and follow the single-file packaging invariant above. Inline the complete client before the page-specific application code; do not produce or reference a separate JavaScript file.
4. Design the UI around the requested job, not around the APIs. For example, a poetry-video agent should expose poem, style, aspect ratio, and generation progress—not generic JSON inputs.
5. Connect form values to the selected client methods. Keep generated text in variables and pass it to downstream image/video calls when the workflow requires multiple stages.
6. Verify the generated files locally for HTML/JavaScript syntax. Do not make paid or state-changing generation calls unless the user explicitly asks to test generation.

Required interaction behavior

• Disable duplicate submissions while a request is active.
• Show distinct states for preparing, generating, polling, success, failure, cancellation, and timeout.
• Use AbortController so visitors can cancel long image or video operations.
• Pass an onDelta callback for text and an onProgress callback for image/video so the UI updates during work.
• Render model text with textContent, not innerHTML. Validate generated media URLs as https:, http:, or blob: before assigning them to src.
• Preserve the visitor's input after failure and provide a deliberate retry action.
• Make the layout responsive and keyboard accessible. Every input needs a label; progress and errors should use suitable live regions.
• Do not display raw response objects, the fixed token, internal endpoint details, or stack traces in the visitor-facing UI.

API invariants

• All three capabilities are browser-side calls to https://study-ai-qa.xiguacity.cn; they do not run inside an agent-run backend.
• The current fixed token is intentionally shipped to every generated public page. Do not claim that it is secret. Future authorization should replace the private getToken() implementation inside the bundled client without changing page-level XiguaAI.text/image/video calls.
• Text responses use OpenAI-style SSE. Preserve streaming rather than waiting for the entire answer.
• Image generation is asynchronous: submit once, then poll by task ID until success, failure, cancellation, or timeout.
• Video generation is asynchronous: submit once, then poll by batchId. Omit conversationId; the current API does not require it.
• Never poll without a delay or without a finite timeout. Use the defaults in the bundled client unless the task justifies a different timeout.
• A successful HTTP status does not by itself mean generation succeeded. Inspect the API envelope and task status through the bundled client.
• Do not invent undocumented endpoints, response fields, model names, ratios, upload behavior, or asset storage.

Current boundary: local file uploads

No file-upload or document-parsing API is included in this skill. The provided video API accepts firstFrameImage and lastFrameImage as strings, but only existing browser-accessible URLs are confirmed. If a requested agent must upload a local product image, resume, or other file and send it to a generation API:

• use an upload capability only if the user supplies its documented endpoint; or
• change the UI to accept an existing public image URL when that meets the user's intent; or
• state that the upload-dependent part is blocked.

Do not silently convert a local file to base64 and assume the generation API accepts it.

Hosting and CORS

Direct browser calls require the API gateway to allow the deployed page's origin, request methods, Content-Type, and the custom token header in CORS preflight responses. When a page works from a server-side client but fails in the browser with a CORS error, report the gateway requirement; do not work around it with an unapproved public proxy.

Delivery

Return the single generated HTML file, identify which of the three capabilities it uses, and mention any unresolved external requirement such as CORS, hosting, public image URLs, or a missing upload API. Before delivery, verify that the HTML contains the full inline client, contains no xigua-ai-client.js src/import reference, and can initialize window.XiguaAI without any local companion file. Keep implementation details out of the visitor-facing page unless the product itself calls for them.