{"id":18004,"plugin_id":"plugins_6a82b32a6ee8819191258c0368112b78","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:34.333Z","digest":"72e09c64900cb024c9935d49a6d05528ce8a372104cf500b5e3611422ae841f4","against":null,"payload":{"description":"Generate or update Zuora integration code using the selected APIs","included_files":[],"name":"zuora-api-build","skill_md_contents":"---\nname: zuora-api-build\ndescription: Generate or update Zuora integration code using the selected APIs\nargument-hint: <language> <API or requirement description>\nallowed-tools: [Read, Write, Edit, Glob, Grep, Bash, Agent, mcp__zuora-mcp__zuora_codegen, mcp__zuora-mcp__ask_zuora, mcp__zuora-mcp__query_objects]\n---\n\nCodex-only path resolution: When an instruction refers to `${CLAUDE_PLUGIN_ROOT}`, treat it as the root of this installed plugin. In Codex, resolve that root as the ancestor directory containing `skills/`, `references/`, and `.codex-plugin/`.\n\n\nYou are generating Zuora integration code. The user has either already run `/zuora-api-design` or is describing what they want to build.\n\n## Input\n\nThe user's request: $ARGUMENTS\n\n## Tool routing\n\nThis build skill depends on `mcp__zuora-mcp__zuora_codegen` for API specs, model fields, enum values, SDK idioms, and code rules. Do not use generic product knowledge for code generation details. `mcp__zuora-mcp__ask_zuora` is allowed only as a fallback for a specific product-behavior question that remains after codegen and references are checked; include the exact uncertainty and sources already checked.\n\n## Workflow\n\n### Step 1: Determine language and scope\n\nIdentify the target language (Java, Python, Node.js, C#, curl). If not specified, ask the user. Understand what APIs and operations are needed.\n\n### Step 2: Follow the mandatory codegen workflow\n\nThis sequence is critical — call `mcp__zuora-mcp__zuora_codegen` in this exact order:\n\n1. **`code_guidance`** with the target language — get SDK setup instructions and workflow guidance. This MUST be called first.\n2. **`list_api_classes`** — if the right API class is unclear, list all available classes to find the right one.\n3. **`get_class_apis`** — for the relevant class(es), get all available API methods.\n4. **`get_api_details`** — for each endpoint you will use, get method signature, parameters, request/response models.\n5. **`get_model_details`** — for ALL request and response models you will use. This is mandatory to get actual field names, types, and enum values. Call this for each model class. For complex field types, recursively call `get_model_details(fieldTypeName)`.\n6. **`code_rules`** — get language-specific coding rules. This MUST be called before presenting code to the user.\n\nFor simple queries (single API, known models), you may skip step 2 and go directly to step 3.\n\n### Step 2.5: Resolve custom field names (when the request includes custom fields)\n\nIf the request involves custom fields (fields ending in `__c`) on any Zuora object:\n\n1. Call `mcp__zuora-mcp__query_objects` with `objectType=<objectName>` and `help=fields` to retrieve the live field schema from the tenant.\n2. Extract the exact field names from the `properties` map in the response — custom field names are **case-sensitive** and must be used verbatim as returned (e.g., `Region__c`, not `region__c`).\n3. **Never invent or lowercase custom field names.** If `query_objects` returns no properties (no tenant context), ask the user to provide the exact names.\n\n### Step 3: Generate code\n\nFollowing the patterns from `code_guidance` and rules from `code_rules`:\n\n- Include SDK client initialization and authentication setup\n- Use correct model classes and constructors from `get_model_details` response\n- Use actual enum values — never guess enum strings\n- Use exact custom field names from Step 2.5 — never guess or lowercase them\n- Include error handling (try/catch, HTTP status checks, retry logic)\n- Include pagination handling for list/query operations\n- Add comments mapping code to business requirements\n- Follow language-specific conventions:\n  - **Java**: Fluent builder pattern, `.execute()` calls, SDK enum constants\n  - **Python**: Snake_case, keyword arguments, async/await where appropriate\n  - **Node.js**: camelCase, async/await, property assignment\n  - **C#**: PascalCase classes, camelCase methods, `Async` suffix on async methods\n  - **curl**: Environment variables for credentials, proper header formatting\n\n### Step 4: Read reference patterns\n\nRead `${CLAUDE_PLUGIN_ROOT}/references/api-integration-patterns.md` and `${CLAUDE_PLUGIN_ROOT}/references/best-practices.md`. Apply relevant patterns to the generated code.\n\n### Step 5: Write code to files\n\nIf the user's project context is clear (they're working in a repo), write code to appropriate files. Otherwise, present the code inline.\n\n### Step 6: Suggest validation\n\nRecommend the user run `/zuora-validate` on the generated code to check for correctness.\n\n## Critical rules\n\n- NEVER generate code before completing steps 2.1 through 2.6. The MCP responses contain actual SDK structure.\n- NEVER guess field names or enum values — always use values from `get_model_details`.\n- NEVER guess or lowercase custom field names (`__c` fields) — always resolve them from the live tenant via `query_objects help=fields` (Step 2.5). Custom field names are case-sensitive.\n- NEVER use setter methods like `setName()` in Java — use fluent builder pattern.\n- For discriminated types in Java/C#: instantiate the specific subtype first, then wrap in the base request class.\n- Always include proper error handling — at minimum, catch and log HTTP errors.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}