Optional context
Add context when it helps
This prompt works as-is. Add any available details for more precision; the agent will infer context and use safe defaults when details are missing.
- Real API documentation or response samples
- The target page and existing request client
- Safe authentication and environment configuration
- Retry pagination and error-display policies
Ready-to-use prompt
Complete coding prompt
Copy and run it as-is. It reads the current project and conversation, while keeping implementation boundaries and verification requirements explicit.
Act as a coding agent responsible for integration quality. Use the current API documentation to integrate data into the current target page with the current authentication method, following the current data mapping and the current failure policy. Inspect the existing request client, types, caching approach, error handling, environment variables, and mocks first. Identify which response fields, status codes, and pagination rules have real evidence. Do not guess private endpoints, print credentials, or treat every HTTP 200 response as business success.
Start with the current conversation, attachments, and accessible materials. Treat available information as the input. When details are missing, choose safe, sensible, easy-to-edit defaults and state them. Ask the minimum number of concise questions first only when missing facts would create a high-risk action or fundamentally change the result.
Create a concise state table for initial loading, refresh, background update with existing data, empty results, retryable errors, non-retryable errors, timeout, cancellation, partial data, unauthenticated, and forbidden states. Define the trigger, visible message, available action, and whether previous data remains for each state. Reuse the existing client to implement a typed request and mapping. Prevent duplicate submissions, stale responses overwriting newer data, and updates after unmount. Give retries a clear limit and respect idempotency; never create an infinite loop. Make errors actionable without exposing stack traces, tokens, or sensitive response data.
Trigger the important states with real or contract-approved responses, distinguishing transport success, HTTP success, and business success. Add automated tests for mapping, errors, and races. Run formatting, type, test, and build checks, then inspect live-page keyboard and screen-reader feedback. Report the contract evidence, state table, changed scope, observed request and page behavior, server cases that could not be simulated, and monitoring suggestions. Mark unsupported fields or behavior as assumptions instead of presenting them as a verified contract.
After it finishes
Do not rely on a claim of completion
Check the real page, runtime behavior, and test evidence item by item.
- Every critical state can be triggered for real
- Transport HTTP and business success are distinct
- Races duplicate submissions and retry limits are handled
- Tests build results and unsimulated server cases are recorded
Inspiration source
This prompt is an original adaptation. The source link is provided for attribution; load the post only if you want to inspect the reference.
The X embed stays off until you choose to load it. Loading it may share your IP address and browser information with X.