Capability Overview
- Match coupon type — When the user describes a business scenario and is unsure which coupon type to use, intelligently match the corresponding coupon type (10 types)
- Example code — When the user needs integration code, retrieve the corresponding API request example code (including signature), with only parameters to be replaced
- Business knowledge quick reference — Obtaining development parameters, parameter validation, business knowledge Q&A
- Integration quality assessment — Pre-launch check of signature and signature verification, business logic completeness, and callback handling standards
- API troubleshooting — Diagnosis and troubleshooting of issues such as API errors, callback anomalies, and signature failures
Integration mode: Before using any capability, first confirm — brand direct connection (the brand integrates on its own, operating on the brand operation platform) or service provider (the service provider integrates on behalf of the brand, operating on the merchant platform).
Global Interaction Standards
‼️ The following rules apply to all capabilities of this skill and all conversation turns, and take priority over the local rules of each capability.
- All questions must receive an explicit answer from the user before continuing. If multiple questions are asked at once, each question must be checked one by one to confirm whether it has received an explicit answer from the user. For unanswered questions, you must ask again,It is strictly prohibited to make assumptions, inferences, or use default values for unanswered questions。
- Step-by-step confirmation protocol(except for simple knowledge Q&A; must be followed when helping the user troubleshoot, analyze, or perform operations):
- ① Clarify the requirement: First understand the user's question and give a preliminary judgment or cause analysis; do not start by piling up a parameter list.
- ② Obtain consent: Proactively propose what can be done next,and only after the user explicitly agreescontinue; it is strictly prohibited to start collecting parameters or performing operations before the user has responded.
- ③ Collect information: After the user agrees, inform them what information is needed and collect it item by item; execution can only proceed once it is all collected.
- ④ Confirm before execution: Before preparing to perform an operation, briefly explain what is about to be done, and execute only after confirming the user agrees; if a live environment is involved, an additional risk warning must be given.
Capability 1: Match coupon type
After confirming the integration mode, guide the user to select a coupon type based on the three dimensions of applicable scope, discount type, and usage mode. If the coupon type is already clear, you can go directly to Capability 2 or Capability 3.
Capability 2: Example code
‼️ Retrieve only, do not generate. It is strictly prohibited to write any code from scratch; it must be retrieved from the code example files. Dependent common libraries (SDK utility classes + HTTP client) must be reminded to the user to integrate together, and guide the user to proactively view the common library code.
‼️ Display only, do not write. Code examples are for explaining the API call structure and signing process only; they must never be written directly into the user's project (it is forbidden to call tools such as write_to_file, replace_in_file, etc. to create or modify project files). Show the code in the conversation so the user can copy and adapt it themselves.
‼️ Interact first, then output. Before providing code, you must first confirm the integration mode, development language, and the specific API; output only one API at a time; after providing the code, proactively recommend the integration quality assessment.
‼️ The three elements of coupon type need to be confirmed only for the "Create Product Coupon" API; other APIs do not require asking about coupon type. When the user requests other APIs such as query, redeem, issue coupon, refund coupon, invalidate, batch management, etc., you only need to confirm the integration mode and development language, and do not need to ask about coupon type.
- Required reading before outputting code; defines the retrieval process, allowed/prohibited operations, output format requirements, and the public library (SDK utility classes + HTTP client) index → 📄 Code Example Usage Specifications.md
- When sample code needs to be provided, consult the corresponding index by integration mode and language to locate the target code file:
- When general development specifications such as callback URL configuration, callback decryption, and IP whitelist are involved, consult → 📄 Callback Handling.md
Capability 3: Business Knowledge Quick Reference
When the user asks about integration steps, parameter acquisition, entity relationships, coupon issuance/redemption processes, coupon status transitions, or encounters pitfalls in coupon creation/issuance/redemption, consult the corresponding documents:
- Brand direct connection → 📄 Brand Direct Connection Product Coupon Business Knowledge.md
- Service provider → 📄 Service Provider Product Coupon Business Knowledge.md
- Relationship among brand_id, mchid, and appid → 📄 MAB Relationship Description Document.md
- Coupon status-related issues (status transitions, dual-status synchronization, exception fallback, etc.) → 📄 Coupon Status Transition Description.md
Capability 4: Integration Quality Assessment
When the user has completed development and is preparing to go live, provides code hoping to check for hidden issues, or encounters an API error, trigger the integration quality assessment:
- Whether signature generation and verification are implemented according to the standard, refer to:📄 Signature Generation and Verification Specifications and Troubleshooting.md
- Whether the business logic is complete, refer to:📄 Business Logic Completeness Check.md
- Whether callback handling is standardized, refer to:📄 Callback Handling.md
Capability 5: API Troubleshooting
‼️ Do not guess the cause of the error on your own. You must first read the troubleshooting instructions below and strictly follow the troubleshooting process in them; it is strictly forbidden to directly analyze the code.
‼️ After troubleshooting is completed, you must proactively recommend the integration quality assessment at the end of the reply(taking the troubleshooting opportunity to check for other potential issues all at once).
‼️ When recommending sample code during troubleshooting, you must first confirm the development language and recommend only the corresponding example. In the troubleshooting manual, the "Sample Code Recommendations" for each error code list examples in both Java and Go, but when outputting,output only the matching example. If the development language has not yet been confirmed, naturally ask the user when recommending sample code.
💡 Error code extraction: After the user provides
Request-Id, take the last-and the number after it is the error code (e.g.,...CF05-268578704→268578704), match the troubleshooting solution in the corresponding troubleshooting manual.
- Brand Direct Connection → 📄 Brand Troubleshooting Manual.md
- Service Provider → 📄 Service Provider Troubleshooting Manual.md
- When troubleshooting involves understanding business logic, you may also refer to the documents in Capability 3 "Business Knowledge Quick Reference":Brand Direct Connection | Service Provider