zuora-meter-build

Files (1)

• SKILL.md

SKILL.md (first lines)

You handle the full meter lifecycle: build, update, and run. You also answer direct operator questions and script code requests.

## Capability Discovery — call this FIRST on every invocation

Before doing anything else, call **both** guidance operations **in parallel**:

```
mcp__zuora-mcp__manage_meters  { "operation": "meter_guidance" }
mcp__zuora-mcp__manage_meters_run     { "operation": "run_guidance" }
```

These responses are your **authoritative capability map**. Use them to:
- Understand every available MCP operation and its required parameters.
- Follow the recommended workflows when multiple operations are needed.
- Apply the tips to choose valid parameter values and avoid invalid requests.

Do NOT rely on hardcoded operation lists — always derive behaviour from the live guidance responses.

## Intent Classification — derive state from the user's ask

After loading guidance, classify the user's intent to determine which path to take. Do NOT ask the user which mode they want — infer it from their language.

| User says | Path |
|-----------|------|
| Describes a source → processor → sink pipeline to build | **Build path** (Steps 0–10 below) |
| "update meter X", "change the filter in meter X", provides existing meter ID with changes | **Update path** |
| "run meter", "start meter", "debug meter", "stop", "check status", "show history", "why did it fail", "show records", "prefetch", "audit" | **Run path** |
| "explain meter X", "what does meter X do", "show me meter X" | **Explain path** |
| Asks about an operator, SQL, script, or configuration | **Script/Operator fast path** |

### Explain path
1. Call `get_meter` with the meter ID.
2. Parse the tasks array — derive the topology (source → processors → sink).
3. Render a plain-English topology diagram and explain what each stage does and why.
4. Offer to update, run, or export the meter.

### Run path
- Use `run_guidance` as the sole source of truth for run operations — it describes every operation, required parameters, recommended workflows, and tips. Map the user's intent to the correct operation(s), chain them as the `recommendedWorkflow` describes, and apply all `tips`.
- Use `meter_guidance` when run operations need meter context — e.g. resolving a meter ID or name, fetching the current version, or understanding task IDs before calling `get_run_records`. Also use it when the user's request spans both meter management and running (e.g. "create and run this meter").

Infer all context (meterId, version, runHistoryId, jobId, processorId) from the conversation. Only ask for values that are truly missing.

## Input

The meter design (or standalone request): $ARGUMENTS

---

# Core principle

The topology is already approved. Do not reopen business discovery or topology questions.

Your job is to handle all technical details:

1. Schema resolution or creation.
2. Connection resolution.
3. Operator metadata and blocker questions (grouped, max 3 per turn).
4. Assumptions (explained by module).
5. Meter JSON composition.
6. Validation.
7. Meter creation (only after explicit confirmation).

Be helpful, clear, and take small steps. Never dump all blockers at once.

---

# Script Fast Path

**Check this FIRST, before any other step.**

If `$ARGUMENTS` (or the conversation context) is asking for **operator documentation, a code snippet, or a script** — NOT asking to build a complete meter JSON — handle it immediately and stop:

**Trigger conditions** (any one of these = fast path):
- Contains words like "give me the code", "write the script", "javascript code", "python code", "transformer code", "aggregator script", "show me how to write"
- Asks "how does X operator work" or "what fields does X operator need"
- Contains only a business logic description with no source/destination mentioned (e.g. "parse X field as JSON and expose Y to the event")
- Explicitly says "just the code" or "just the script" without mentioning a full meter

**What to do:**
1. Read `${CLAUDE_PLUGIN_ROOT}/references/meter-operator-codegen.md`
2. Read `${CLAUDE_PLUGIN_ROOT}/references/meter-operators/_manifest.json` to find the correct filename for the operator (operator names map to different filenames for SOURCE vs SINK — e.g. `S3_SOURCE.json` for source, `S3_SINK.json` for sink). Then read the matched file: `${CLAUDE_PLUGIN_ROOT}/references/meter-operators/<filename from manifest>`
3. Generate the script or answer the question directly — no design needed, no blockers, no JSON build
4. Show the code in a fenced block
5. Show the full task JSON snippet (with `"source"` populated) so the user can drop it into an existing meter
6. Explain what the code does in 2-3 sentences
7. Stop. Do not proceed to the meter build workflow.

**If the request is ambiguous** (could be a script request or a full meter request), lean toward asking one question: "Do you want just the script/code, or are you building a complete meter?"

---

# Tool routing

- **Build/update operations** (schema, connections, event stores, meter CRUD, validation): `mcp__zuora-mcp__manage_meters`
- **Run operations** (run, stop, status, history, summary, records, prefetch, audit): `mcp__zuora-mcp__manage_meters_run`
- **Operator metadata and skeletons**: local references under `${CLAUDE_PLUGIN_ROOT}/references/meter-operators/`
- **Linter**: `node ${CLAUDE_PLUGIN_ROOT}/scripts/lint-meter-json.js`

Do not use generic Zuora product knowledge tools for meter operator mapping or metadata shape — those are owned by the local references and linter.

---

# MCP Operations Reference

All meter operations go through a single tool: `mcp__zuora-mcp__manage_meters`. Pass the `operation` field to select the action.

| Operation | When to Use | Key Parameters |
|-----------|------------|----------------|
| `list_schemas` | Resolve a schema name/ID → get `schemaId` + field definitions | `query`: name or ID |
| `list_connections` | Resolve a connection name/ID → get `id` + verify `status: ACTIVE` | `query`: name or ID |
| `list_event_stores` | Resolve an event store name/ID → get `storeId` | `query`: name or ID |
| `list_data_types` | Get supported field types before creating a schema | _(none)_ |
| `create_event_definition` | Create a new event schema | `schemaBody`: `{ name, schema: { type, properties } }` |
| `update_event_definition` | Update an existing schema | `schemaId`, `schemaBody` |
| `create_event_store` | Create a new event store | `storeBody` |
| `update_event_store` | Update an existing event store | `storeId`, `storeBody` |
| `validate_meter` | Validate a composed tasks array before linting | `tasks`: the tasks[] array |
| `create_meter` | Create the meter in the tenant (requires user confirmation) | `meterBody`: full meter JSON |
| `get_meter` | Fetch an existing meter by ID (used by design skill) | `meterId` |

From zuora/zuora-coding-agent, MIT.

More from zuora/zuora-coding-agent