YCloud Developer Kit

View saved version →

---
name: ycloud-api-authentication
description: Design, implement locally, or evaluate secure server-side YCloud API authentication with the contract’s X-API-Key scheme, placeholder configuration, environment isolation, secret-manager boundaries, and API-key rotation planning. Use for API-key storage, header, or API-key rotation questions; webhook endpoint secret rotation belongs to Webhooks.
---

# YCloud API Authentication

Design or implement authentication at a trusted server boundary. Use the global authentication scheme in `references/openapi.md` and the official error behavior in `references/runtime.md`. When translating authentication errors or designing rotation coordination, also read `references/shared/integration-boundaries.md` and label project policy separately from YCloud behavior. Never call YCloud, read a credential, or expose a real secret.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Infer the Architect dimensions when they are supplied: `scope`, `deliverable`,
and `mutation`. Without an Architect handoff, default to focused scope and
read-only guidance unless the user explicitly asks to implement local project
changes. Local-write authorization permits server config adapters, validation,
redaction, and no-network tests inside the scoped project. It does not permit
reading, setting, validating, or rotating a real key, changing deployment or
production configuration, or making an external request.

## Scope and handoff

Handle only server-side API-key configuration and API-key rotation planning. A generic "rotate secret" request must be clarified: webhook endpoint secret rotation belongs to Webhooks, not Authentication. Route these requests away:

- Message send/retrieve (including sending an existing template) → `ycloud-whatsapp-messages`.
- Media upload → `ycloud-whatsapp-media`.
- Template lifecycle or analytics → `ycloud-whatsapp-templates`.
- Webhook endpoint management → `ycloud-webhook-endpoints`.
- Broad or multi-domain integration planning → `ycloud-integration-architect`.
- Plugin readiness → the readiness-only smoke Skill; repository-maintenance and issue-tracker workflows are outside this Plugin.

## Workflow

For explicitly requested sandbox/mock/no-real-side-effect tests, also read
`references/shared/sandbox-contract.md`. The fixed synthetic key belongs only to
the local Facade and is not a YCloud test credential or an example of production
key format.

1. Inspect project structure read-only to identify the server runtime, configuration mechanism, deployment environments, and test harness. Do not open or parse secret values from `.env`, credential files, secret stores, logs, shell history, browser storage, or customer data. Ask only for a missing runtime/deployment fact that changes the guidance.
2. Read both narrow references and preserve their exact boundaries. The request header is `X-API-Key`; show only a placeholder such as `<YCLOUD_API_KEY>`, never a user-provided key. An invalid key is documented as HTTP `401` with `error.code=UNAUTHORIZED`; preserve that provider envelope and `YCloud-Request-ID`. If the project exposes RFC 9457, translate only at its own API boundary and retain redacted `provider_code`/`provider_request_id`; never claim YCloud returned Problem Details.
3. Keep the key on a trusted server boundary. Recommend an environment-specific secret injection path or Secret Manager reference, least-privilege access, redaction, and ro

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-balance
description: Design, implement locally, or evaluate retrieval and interpretation of the YCloud account balance. Use for the single Balance read operation or a balance-to-readiness evidence handoff; exclude plugin readiness checks, billing history, top-ups, and real API operations.
---

# YCloud Balance

Design or implement contract-aware retrieval of the current account balance.
Use synthetic responses and a mock transport only; never call YCloud, read a
credential, expose customer financial data, or claim a live balance was checked.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor an Architect handoff for scope, deliverable, mutation, capability ID,
project seams, and evidence. Without one, default to focused read-only guidance
unless the user explicitly requests local implementation. Local-write
authorization permits a trusted-server adapter, typed response mapping,
mock-only handler/service bindings, fixtures, and no-network tests in the scoped
project. It never authorizes a live balance request or production readiness
decision.

## Scope and handoffs

After this Skill is selected, read the generated [OpenAPI
contract](references/openapi.md) and reviewed [runtime
behavior](references/runtime.md). If retry, error translation, rate limiting, or
production architecture is requested, also read
`references/shared/integration-boundaries.md`. If either generated reference is
missing, stale, or conflicts with the pinned source, report the drift and stop
instead of guessing.

This Skill owns exactly `GET /balance`, operationId `balance-retrieve`. It does
not own transactions, billing history, invoices, spending forecasts, top-ups,
currency conversion, or account mutation. API-key configuration belongs to
`ycloud-api-authentication`; broad planning belongs to
`ycloud-integration-architect`.

Balance may provide one synthetic or observed-at-runtime input to an
application's operational-readiness policy, but this Skill does not define a
minimum sufficient balance and cannot certify plugin, deployment, account, or
production readiness. Route an explicit Developer Kit installation/readiness
check to the readiness/smoke workflow. Keep any application threshold, alert,
reservation, or fail-open/fail-closed rule labeled as project policy.

## Contract-first workflow

1. Confirm the source hash, exact method/path, `operationId`, lack of parameters
   and request body, and response schema in the generated reference. Do not
   infer an SDK method from `balance-retrieve`.
2. Preserve the documented `200 Balance` shape: required numeric `amount` and
   required string `currency`, where currency is an ISO 4217 code. Do not assume
   `amount` is an integer, minor units, non-negative, available credit, or a
   promise that a future operation will succeed. Preserve decimal precision
   according to the target project's established money strategy; if none
   exists, surface that decision instead of silently rounding through binary
   floating-point arithmetic.
3. Keep provider-generated identifiers and future opaque strings
   case-sensitive and unparsed. Preserve unknown response properties and an
   explicit unknown branch for future enum-like values. Do not convert currency
   or combine balances unless a separate, authoritative project contract is in
   scope.
4. At the provider adapter, retain the standard error envelope and
   `YCloud-Request-ID` (or `error.requestId`) 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-contacts
description: Design, implement locally, or evaluate YCloud Contacts lifecycle, attribute, and note operations with strict contact/note ID separation and defensive pagination. Use for Contacts API work; exclude Custom Events, Unsubscribers, message sending, and real API mutations.
---

# YCloud Contacts

Design or implement contract-aware contact, contact-attribute, and contact-note
workflows against mocks only. Never call YCloud, read credentials or customer
data, perform a real mutation, or treat a contact change as a downstream event,
subscription, or message action.

## Execution and authority boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor an Architect handoff for `scope`, `deliverable`, `mutation`, capability
IDs, project seams, and evidence. Without one, default to focused, read-only
guidance unless the user explicitly requests local implementation. Local-write
authorization permits request models/builders, adapters, handlers, service
bindings, mocks, fixtures, and no-network tests inside the scoped project. Every
create, update, or delete remains mock-only; local-write authorization does not
authorize a real contact or note mutation.

Keep claims in three authority layers:

1. **Provider contract** — [references/openapi.md](references/openapi.md) and
   [references/runtime.md](references/runtime.md). State these as YCloud behavior.
2. **Developer Kit policy** — `references/shared/integration-boundaries.md` when
   retry, idempotency, queueing, error translation, or webhook reliability is in
   scope. Label its recommendations as local policy.
3. **Project decisions** — only facts confirmed in the user's scoped project.

Do not promote an `operationId`, generated model name, `x-*` extension, example,
platform recommendation, or project convention into provider behavior. If the
generated references are absent, stale, internally inconsistent, or do not list
all ten operations below, stop and report the drift.

## Exact operation allowlist

Load both generated references after this Skill is selected. Match only these
operations and preserve every source-defined parameter, request/response schema,
status code, and description constraint.
For contact list work, also read
[`references/shared/pagination-contract.md`](references/shared/pagination-contract.md).

| Intent | Method and path | operationId |
| --- | --- | --- |
| List attributes | `GET /contact/contacts/attributes` | `contact-attributes-list` |
| Create contact | `POST /contact/contacts` | `contact-create` |
| Delete contact | `DELETE /contact/contacts/{id}` | `contact-delete` |
| List contacts | `GET /contact/contacts` | `contact-list` |
| Create note | `POST /contact/contacts/{contactIdentifier}/notes` | `contact-note-create` |
| Delete note | `DELETE /contact/notes/{noteId}` | `contact-note-delete` |
| Update note | `PATCH /contact/notes/{noteId}` | `contact-note-update` |
| List notes | `GET /contact/contacts/{contactIdentifier}/notes` | `contact-notes-list` |
| Retrieve contact | `GET /contact/contacts/{id}` | `contact-retrieve` |
| Update contact | `PATCH /contact/contacts/{id}` | `contact-update` |

No search operation is in this allowlist. Contact attributes are configurations,
not contact values. Contact retrieve/list responses do not contain notes; use
`contact-notes-list` when note contents or note IDs are needed.

## Identifier separation

Treat every identifier as opaque and case-sensitive e

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-custom-events
description: Design, implement locally, or evaluate YCloud custom-event definition/property lifecycle and CONTACT-associated event ingestion. Use for the seven allowlisted Custom Events operations; exclude Contact lifecycle, webhook consumption, analytics, and real API mutations.
---

# YCloud Custom Events

Design or implement contract-aware custom-event schema management and event
ingestion with synthetic data and a mock transport only. Never call YCloud,
read credentials or customer data, mutate a real definition, or send a real
event.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor an Architect handoff for scope, deliverable, mutation, capability IDs,
project seams, Contact artifacts, and expected evidence. Without one, default
to focused read-only guidance unless the user explicitly requests local
implementation. Local-write authorization permits server-side request models,
builders, adapters, handlers, fixtures, and no-network tests in the scoped
project. It never authorizes an external create, update, delete, retrieve, or
send request. Use placeholders and synthetic identifiers throughout.

After this Skill is selected, read the pinned [OpenAPI
contract](references/openapi.md) and reviewed [runtime
boundaries](references/runtime.md). If retry, idempotency, outbox/queue, rate
limiting, or error translation is requested, also read
`references/shared/integration-boundaries.md`. If the source hash, operation
coverage, or contract facts drift, stop and report the mismatch instead of
guessing.

## Exact scope and routing

Definition and property lifecycle is separate from occurrence ingestion:

| Concern | Method and path | operationId |
| --- | --- | --- |
| Create definition | `POST /event/definitions` | `custom_events-create-definition` |
| Retrieve definition | `GET /event/definitions/{name}` | `custom_events-retrieve-definition` |
| Update definition metadata | `PATCH /event/definitions/{name}` | `custom_events-update-definition` |
| Create property definition | `POST /event/definitions/{name}/properties` | `custom_events-create-property-definition` |
| Delete property definition | `DELETE /event/definitions/{name}/properties/{propertyName}` | `custom_events_delete-property-definition` |
| Update property metadata | `PATCH /event/definitions/{name}/properties/{propertyName}` | `custom_events_update-property-definition` |
| Ingest event occurrence | `POST /event/events` | `custom_events-send-event` |

The first six operations manage reusable definitions; they do not ingest an
event. The final operation submits one occurrence; it does not create or alter
its definition. Contact create/retrieve/update/delete and identity resolution
belong to the Contact workflow. Webhook consumption, analytics, readiness, and
broad multi-domain planning are outside this Skill.

## Contract-first workflow

1. Match only the selected operations above to their exact method, path,
   parameters, request schema, responses, and descriptions in `openapi.md`.
   Treat `operationId` as an identifier, not an SDK method. Use raw HTTP shapes
   or an SDK artifact/version already confirmed in the project.
2. For definition creation, preserve required `name`, `label`, and `objectType`;
   the pinned enum contains only `CONTACT`. Preserve the exact source patterns
   and lengths without “correcting” or anchoring them. Definition update changes
   only `label` and/or `descri

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-developer-kit-smoke-test
description: Return a fixed readiness message without external side effects. Use when the user explicitly asks to verify that the local YCloud Developer Kit Codex plugin is installed, discoverable, or ready.
---

# YCloud Developer Kit Smoke Test

Return exactly this text and nothing else:

```text
YCloud Developer Kit is ready. No external API was called.
```

Do not call tools, run shell commands, access the network, invoke MCP servers, call APIs, read credentials, or inspect customer data.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-integration-architect
description: Design, implement, or evaluate a cross-domain YCloud integration from local project context, with explicit scope, deliverable, mutation boundaries, domain handoffs, and coverage evidence. Use for broad integration or multi-domain orchestration; do not use for readiness, repository-maintenance, issue-tracker, support, or requests confined to one domain.
---

# YCloud Integration Architect

Orchestrate a contract-aware YCloud integration across every Developer Kit-owned
domain. Normalize the request before acting, delegate
domain contract decisions to the matching Skill, and merge their evidence into
one result. Never call a real YCloud API, read credentials or customer data, or
infer permission for an external action from permission to edit local files.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

## Normalize the request

Resolve these dimensions from the user's words and project context:

```text
scope: focused | full-first-wave | full-whatsapp-operations | full-supported-operations
deliverable: project-integration | test-console | production-plan
mutation: read-only | local-write-authorized
```

- Default to `focused` when the user names a concrete outcome or domain.
- “All currently supported capabilities” means `full-supported-operations`: 88
  API operations plus 2 cross-cutting capabilities = 90 coverage rows.
- `full-first-wave` remains a compatibility mode: 17 API operations + 2
  cross-cutting capabilities = 19 coverage rows.
- “All YCloud APIs” requires an explicit `88 API operations + 2 cross-cutting capabilities = 90 coverage rows`
  disclosure, with 7 operations excluded by product decision. Product exclusion
  is not provider deprecation; never claim all 95 are covered.
- Select `test-console` only when the user asks for a test UI, console, explorer,
  or comparable interactive surface. Do not turn `full-first-wave` into a
  dashboard on its own.
- Select `production-plan` for production architecture or rollout planning. It
  is read-only unless the user separately asks to implement local artifacts.
- Local implementation authorization permits writes only inside the scoped
  project. It never permits sending, uploading, deleting, rotating, changing a
  remote endpoint, or otherwise calling a real provider API.

Read only the selected mode reference:

- `focused` → [references/modes/focused.md](references/modes/focused.md)
- `full-first-wave` → [references/modes/full-first-wave.md](references/modes/full-first-wave.md)
- `full-whatsapp-operations` → [references/modes/full-whatsapp-operations.md](references/modes/full-whatsapp-operations.md)
- `full-supported-operations` → [references/modes/full-supported-operations.md](references/modes/full-supported-operations.md)
- `test-console` → [references/modes/test-console.md](references/modes/test-console.md)
- `production-plan` → [references/modes/production-plan.md](references/modes/production-plan.md)

When scope or completion is material, also read
[references/capability-catalog-summary.md](references/capability-catalog-summary.md)
and [references/coverage-matrix-schema.md](references/coverage-matrix-schema.md).
For multi-domain work, read
[references/handoff-contracts.md](references/handoff-contracts.md).

## Domain routing

| Concern | Owner Skill | Boundary |
| --- | --- | --- |
| API key, trusted-server header, storage, API-key rotation plan | `ycloud-api-authentica

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 16 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-unsubscribers
description: Design, implement locally, or evaluate YCloud customer unsubscribe creation, lookup, listing, and deletion. Use for opt-out records and message-eligibility evidence; exclude Contact CRUD, message sending, provider delivery status, and real API operations.
---

# YCloud Unsubscribers

For `unsubscriber-list`, read
[`references/shared/pagination-contract.md`](references/shared/pagination-contract.md)
with the generated OpenAPI/runtime references.

Design or implement contract-aware handling for the five Unsubscriber operations
in the pinned reference. Use synthetic customers and a mock transport only.
Never call YCloud, inspect credentials or customer data, or mutate a real
unsubscribe record.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor an Architect or Contact handoff for scope, deliverable, mutation,
capability IDs, project seams, confirmed customer identity, and expected
evidence. Without one, default to focused read-only guidance unless the user
explicitly requests local implementation. Local-write authorization permits
request/response models, adapters, handlers, mock fixtures, policy-evidence
mappers, and no-network tests in the scoped project. Create and delete remain
mock-only, and even GET operations must use mocks in this workflow.

After this Skill is selected, read the generated [OpenAPI
contract](references/openapi.md) and reviewed [runtime
behavior](references/runtime.md). For retry, idempotency, error translation, or
production architecture, also read
`references/shared/integration-boundaries.md`. If either local reference is
missing, stale, or inconsistent with its recorded source hash or operation
count, report drift and stop rather than reconstructing the contract from
memory.

## Exact operation scope

| Intent | Method and path | operationId |
| --- | --- | --- |
| Create an unsubscribe record | `POST /unsubscribers` | `unsubscriber-create` |
| Delete by composite identity | `DELETE /unsubscribers/{customer}/{channel}` | `unsubscriber-delete-by-customer-and-channel` |
| List unsubscribe records | `GET /unsubscribers` | `unsubscriber-list` |
| List all records for one customer | `GET /unsubscribers/{customer}` | `unsubscriber-list-all-by-customer` |
| Retrieve by composite identity | `GET /unsubscribers/{customer}/{channel}` | `unsubscriber-retrieve-by-customer-and-channel` |

Contact discovery and updates belong to a Contact capability; message request
construction, `filterUnsubscribed`, submission, retrieval, and message status
belong to `ycloud-whatsapp-messages`. Authentication belongs to
`ycloud-api-authentication`; broad multi-domain planning belongs to
`ycloud-integration-architect`. Webhook processing, keyword configuration,
marketing consent design, and non-WhatsApp channel behavior are out of scope.

## Contract-first workflow

1. Match only the five allowlisted operations. Report exact method, path,
   `operationId`, parameters, body, response schema, and documented status.
   Treat operation IDs and `x-*` fields as identifiers or codegen hints, not SDK
   method names or additional behavior.
2. Model `(customer, channel)` as the unique Unsubscriber identity. Do not use
   `regionCode`, `source`, or `createTime` as identity. For the documented
   `type=PHONE_NUMBER`, require `customer` to remain an E.164 string, never a
   number, and URL-encode it as one path segment (including the leading `+`).
   Th

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-webhook-endpoints
description: Design, implement locally, or evaluate YCloud webhook endpoint management and secure receivers from the official signature, retry, acknowledgement, and delivery contract. Use for endpoint CRUD/rotate-secret integration or event receiving; do not use for message sending, readiness, broad integration planning, or real endpoint/API mutations.
---

# YCloud Webhook Endpoints

For endpoint-list work, read
[`references/shared/pagination-contract.md`](references/shared/pagination-contract.md)
with the generated OpenAPI/runtime references.

Design or implement endpoint-management integrations from the pinned OpenAPI
contract and receiver integrations from the reviewed official runtime contract.
Keep those two modes distinct in the result.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor Architect handoffs for `scope`, `deliverable`, `mutation`, capability IDs,
project seams, and expected evidence. Without one, default to focused scope and
read-only guidance unless the user explicitly requests local implementation.
Local-write authorization permits endpoint request builders, adapters, receiver
handlers, inbox/state models, test-console bindings, synthetic fixtures, and
no-network tests inside the scoped project. It never authorizes endpoint create,
update, delete, secret rotation, callback delivery, or any real API call. Reuse
the project's existing UI/interface stack; do not create a dashboard or choose a
framework on your own.

## Trigger boundary

Use this skill for creating, listing, retrieving, updating, deleting, or rotating
the secret of a YCloud webhook endpoint, and for receiver acknowledgement,
signature verification, retry/deduplication handling, or event-delivery design.
Endpoint CRUD comes from `references/openapi.md`; receiver behavior comes from
`references/runtime.md`. Event-type-specific payload fields beyond the documented
common envelope require a selected event reference or remain `CANNOT`. Route message operations to `ycloud-whatsapp-messages`, media upload
to `ycloud-whatsapp-media`, template lifecycle to `ycloud-whatsapp-templates`,
and broad integration design to `ycloud-integration-architect`. Readiness and
Repository-maintenance and issue-tracker prompts do not trigger this skill.

After selection, read `references/openapi.md` and `references/runtime.md`. In
receiver mode, also read `references/shared/webhook-contract.md`,
`references/shared/webhook-event-types.txt`, and
`references/shared/webhook-signature-vectors.tsv`. For
`whatsapp.message.updated`, also execute
`references/shared/webhook-message-lifecycle-fixtures.json`. For receiver reliability,
error translation, replay, secret rotation, or callback-URL security, also read
`references/shared/integration-boundaries.md`. The OpenAPI reference mechanically lists the
six allowlisted endpoint-management operations: create, list, retrieve, update,
delete, and rotate-secret. Use the exact source-derived paths, methods,
operationIds, parameters, request/response schemas, and descriptions. Never
invent endpoint paths, event payload fields, retry behavior beyond the published
schedule, delivery semantics, or rotation choreography. The runtime reference
does confirm `YCloud-Signature`, HMAC-SHA256 over `<timestamp>.<raw-body>`, a
fast `2xx`, and seven retry intervals; do not put those facts in `CANNOT`. If
the reference is missing or its source hash/coverage drifts, r

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 10 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-business-accounts
description: Design, implement locally, or evaluate YCloud WhatsApp Business Account listing, retrieval, and automatic creative optimization operations. Use for WABA inventory or ACO integration; exclude phone-number management, messaging, template lifecycle, broad planning, and real API mutations.
---

# YCloud WhatsApp Business Accounts

Design or implement contract-aware support for the four WABA operations in the
generated reference. Never call YCloud or Meta, read credentials or customer
data, or mutate a real WABA.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor Architect handoffs for `scope`, `deliverable`, `mutation`, capability IDs,
project seams, and expected evidence. Without one, default to focused,
read-only guidance unless the user explicitly requests local implementation.
Local-write authorization permits request models/builders, adapters, handlers,
service bindings, mocks, synthetic fixtures, and no-network tests inside
the scoped project. The ACO PATCH operation is mock-only: local implementation
does not authorize a real enrollment update. Reuse the project's existing
interface stack and preserve concurrent work.

Load [the generated OpenAPI reference](references/openapi.md) and
[the reviewed runtime reference](references/runtime.md) only after this skill is
selected. If retry, idempotency, queueing, or error translation is requested,
also read `references/shared/integration-boundaries.md`. Exact paths, schemas,
responses, and descriptions come from `openapi.md`; cross-cutting pagination,
error, request-ID, rate-limit, and compatibility behavior comes from
`runtime.md`. If either generated reference is missing, stale, or inconsistent
with its recorded source hash and operation count, report drift and stop rather
than reconstructing the contract from memory.
For WABA list work, also read
[`references/shared/pagination-contract.md`](references/shared/pagination-contract.md).

## Exact operation scope

| Intent | Method and path | operationId |
| --- | --- | --- |
| List WABAs | `GET /whatsapp/businessAccounts` | `whatsapp_business_account-list` |
| Retrieve one WABA | `GET /whatsapp/businessAccounts/{id}` | `whatsapp_business_account-retrieve` |
| Retrieve ACO enrollment | `GET /whatsapp/businessAccounts/{wabaId}/automatic-creative-optimizations` | `whatsapp_waba-retrieve-automatic-creative-optimizations` |
| Partially update ACO enrollment | `PATCH /whatsapp/businessAccounts/{wabaId}/automatic-creative-optimizations` | `whatsapp_waba-update-automatic-creative-optimizations` |

Phone-number inventory and configuration belong to
`ycloud-whatsapp-phone-numbers`. Message submission/retrieval belongs to
`ycloud-whatsapp-messages`; template lifecycle and analytics belong to
`ycloud-whatsapp-templates`; authentication-only work belongs to
`ycloud-api-authentication`; broad multi-domain planning belongs to
`ycloud-integration-architect`. Readiness, repository maintenance, and issue
tracking are out of scope.

## Contract-first workflow

1. Match only an allowlisted operation and report its exact method, path,
   operationId, parameters, request/response schemas, and documented responses.
   Treat `operationId` and `x-*` fields as identifiers or codegen hints, not SDK
   method names or business rules. Use a project SDK only when its actual
   artifact, version, and method are confirmed.
2. Keep every WABA ID as an opaque, c

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-calling
description: Design, implement locally, or evaluate YCloud WhatsApp Calling connect, pre-accept, accept, reject, terminate, and call-media download operations. Use for API-sourced call sessions after Phone Numbers and Webhook Receiver handoffs; exclude calling settings, media upload, message operations, and real API calls.
---

# YCloud WhatsApp Calling

Design or implement contract-aware WhatsApp Calling session commands and call
media downloads. Keep every example synthetic and every transport mock-only;
never call YCloud or Meta, inspect credentials or customer data, or claim that a
real call changed state.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor Architect handoffs for scope, deliverable, mutation, capability IDs,
project seams, and evidence. Without one, default to focused read-only guidance
unless the user explicitly requests local implementation. Local-write
authorization permits trusted-server request builders, adapters, handlers,
state models, synthetic webhook fixtures, mock transports, and no-network tests
inside the scoped project. It never authorizes a real call command or media
download.

After this Skill is selected, read the generated [OpenAPI
contract](references/openapi.md) and reviewed [runtime
behavior](references/runtime.md). If retry, idempotency, queueing, error
translation, or production architecture is requested, also read
`references/shared/integration-boundaries.md`. If either Calling reference is
missing, stale, or inconsistent with the pinned source hash and operation count,
report drift and stop rather than reconstructing the contract from memory.

## Exact operation scope

| Intent | Method and path | operationId |
| --- | --- | --- |
| Connect an outbound call | `POST /whatsapp/calls/connect` | `whatsapp_call-connect` |
| Pre-accept an inbound call | `POST /whatsapp/calls/preAccept` | `whatsapp_call-pre-accept` |
| Accept an inbound call | `POST /whatsapp/calls/accept` | `whatsapp_call-accept` |
| Reject an inbound call | `POST /whatsapp/calls/reject` | `whatsapp_call-reject` |
| Terminate an active call | `POST /whatsapp/calls/terminate` | `whatsapp_call-terminate` |
| Download call recording/transcription | `GET /whatsapp/calls/media/{mediaAssetId}` | `whatsapp_call-download-media` |

Calling/capture configuration belongs to `ycloud-whatsapp-phone-numbers`.
Webhook signature verification, raw-body handling, durable acceptance,
deduplication, and event parsing belong to the Webhook Receiver. Media upload
belongs to `ycloud-whatsapp-media`; WhatsApp message submission and message IDs
belong to `ycloud-whatsapp-messages`; authentication belongs to
`ycloud-api-authentication`; broad multi-domain planning belongs to
`ycloud-integration-architect`.

## Required incoming handoffs

- **Phone Numbers:** consume a separately confirmed WhatsApp Business
  `phoneId`, source E.164 phone number, and Calling/capture readiness evidence.
  Settings or registration success is only prerequisite evidence; it does not
  authorize a call command or prove that a call can connect.
- **Webhook Receiver:** consume only a signature-verified, durably accepted,
  deduplicated call event. For inbound pre-accept, accept, reject, or terminate,
  take `wacid` and `phoneId` from the parsed Call Connect/session event. For a
  recording or transcription, take `mediaAssetId`, `wacid`, `phoneId`, and
  `status` from the parsed media event.

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-flows
description: Design, implement locally, or evaluate all 9 YCloud WhatsApp Flows operations across draft creation, retrieval, metadata or structure updates, publishing, preview, deprecation, and deletion. Use for Flow lifecycle management; exclude Flow message sending and real API mutations.
---

# YCloud WhatsApp Flows

Design or implement contract-aware WhatsApp Flow lifecycle management against
mocks only. Never call YCloud, mutate a real Flow, open a live preview URL, read
credentials or customer data, or imply that managing a Flow sent a message.

## Execution and authority boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor an Architect handoff for `scope`, `deliverable`, `mutation`, capability
IDs, project seams, and evidence. Without one, default to focused, read-only
guidance unless the user explicitly requests local implementation. Local-write
authorization permits request models/builders, multipart adapters, handlers,
handler/service bindings, mocks, fixtures, and no-network tests inside the scoped
project. Every create, update, publish, deprecate, delete, or preview-link
invalidation remains mock-only; no authorization level in this Skill permits a
real API call.

Keep claims in three authority layers:

1. **Provider contract** — [references/openapi.md](references/openapi.md) and
   [references/runtime.md](references/runtime.md). State these as YCloud behavior.
2. **Developer Kit policy** — `references/shared/integration-boundaries.md` when
   retry, idempotency, queueing, error translation, or webhook reliability is in
   scope. Label its recommendations as local policy.
3. **Project decisions** — only facts confirmed in the user's scoped project.

Do not promote an `operationId`, generated model name, `x-*` extension, example,
platform recommendation, or project convention into provider behavior. If the
generated references are absent, stale, internally inconsistent, or do not list
all 9 operations below, stop and report the drift.

## Exact operation allowlist

Load both generated references after this Skill is selected. Match only these
operations and preserve every source-defined path/query parameter,
request/response schema, content type, status code, and description constraint.
For Flow list response adaptation, also read
[`references/shared/pagination-contract.md`](references/shared/pagination-contract.md).

| Intent | Method and path | operationId |
| --- | --- | --- |
| Create Flow | `POST /whatsapp/flows` | `whatsapp_flow-create` |
| List Flows | `GET /whatsapp/flows` | `whatsapp_flow-list` |
| Retrieve Flow | `GET /whatsapp/flows/{flowId}` | `whatsapp_flow-retrieve` |
| Update structure | `PATCH /whatsapp/flows/{flowId}/assets` | `whatsapp_flow-update-structure` |
| Update metadata | `PATCH /whatsapp/flows/{flowId}/metadata` | `whatsapp_flow-update-metadata` |
| Publish Flow | `POST /whatsapp/flows/{flowId}/publish` | `whatsapp_flow-publish` |
| Generate preview URL | `GET /whatsapp/flows/{flowId}/preview` | `whatsapp_flow-preview` |
| Deprecate Flow | `POST /whatsapp/flows/{flowId}/deprecate` | `whatsapp_flow-deprecate` |
| Delete Flow | `DELETE /whatsapp/flows/{flowId}` | `whatsapp_flow-delete` |

Flow interactive message composition and sending belong to
`ycloud-whatsapp-messages`, even when the Flow already exists. This Skill owns
only management of the Flow resource and its preview URL.

## Contract-first workflow

1. Confirm the sele

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-groups
description: Design, implement locally, or evaluate all 12 YCloud WhatsApp Groups operations, including asynchronous lifecycle tracking, join requests, participants, settings, invite links, and the invite-link message handoff. Use for group management; exclude ordinary or Flow message sending, Flow lifecycle, and real API mutations.
---

# YCloud WhatsApp Groups

Design or implement contract-aware WhatsApp group management against mocks only.
Never call YCloud, perform a real group or message mutation, read credentials or
customer data, or claim that an accepted request reached its final state.

## Execution and authority boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor an Architect handoff for `scope`, `deliverable`, `mutation`, capability
IDs, project seams, and evidence. Without one, default to focused, read-only
guidance unless the user explicitly requests local implementation. Local-write
authorization permits request models/builders, adapters, handlers, service
bindings, mocks, fixtures, and no-network tests inside the scoped project. Every
mutating operation remains mock-only; local-write authorization does not
authorize a real create, delete, update, participant action, invite-link reset,
join-request action, or message send.

Keep claims in three authority layers:

1. **Provider contract** — [references/openapi.md](references/openapi.md) and
   [references/runtime.md](references/runtime.md). State these as YCloud behavior.
2. **Developer Kit policy** — `references/shared/integration-boundaries.md` when
   retry, idempotency, queueing, error translation, or webhook reliability is in
   scope. Label its recommendations as local policy.
3. **Project decisions** — only facts confirmed in the user's scoped project.

Do not promote an `operationId`, generated model name, `x-*` extension, example,
platform recommendation, or project convention into provider behavior. If the
generated references are absent, stale, internally inconsistent, or do not list
all 12 operations below, stop and report the drift.

## Exact operation allowlist

Load both generated references after this Skill is selected. Match only these
operations and preserve every source-defined path parameter, query parameter,
request/response schema, status code, and description constraint.
For either list operation, also read
[`references/shared/pagination-contract.md`](references/shared/pagination-contract.md).

| Intent | Method and path | operationId |
| --- | --- | --- |
| Create group | `POST /whatsapp/{businessPhoneNumber}/groups` | `whatsapp_group-create` |
| List groups | `GET /whatsapp/{businessPhoneNumber}/groups` | `whatsapp_group-list` |
| Retrieve group | `GET /whatsapp/{businessPhoneNumber}/groups/{groupId}` | `whatsapp_group-retrieve` |
| Delete group | `DELETE /whatsapp/{businessPhoneNumber}/groups/{groupId}` | `whatsapp_group-delete` |
| Retrieve invite link | `GET /whatsapp/{businessPhoneNumber}/groups/{groupId}/inviteLink` | `whatsapp_group-retrieve-invite-link` |
| Reset invite link | `POST /whatsapp/{businessPhoneNumber}/groups/{groupId}/inviteLink/reset` | `whatsapp_group-reset-invite-link` |
| Send invite-link message | `POST /whatsapp/{businessPhoneNumber}/groups/inviteLink/messages` | `whatsapp_group-send-invite-link-message` |
| List join requests | `GET /whatsapp/{businessPhoneNumber}/groups/{groupId}/joinRequests` | `whatsapp_group-list-join-requests` |
| Approve joi

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-inbound-messages
description: Design, implement locally, or evaluate the two YCloud WhatsApp inbound-message acknowledgement operations for marking a received message as read or showing a typing indicator. Use after verified inbound-message receipt; exclude webhook receiving, message sending, and real API operations.
---

# YCloud WhatsApp Inbound Messages

Design or implement contract-aware acknowledgement of an already received
WhatsApp message. Keep all examples synthetic and every operation side effect
behind a mock transport; never call YCloud, read credentials or customer data,
or claim that a real read receipt or typing indicator was produced.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor an Architect handoff for scope, deliverable, mutation, capability IDs,
project seams, and evidence. Without one, default to focused read-only guidance
unless the user explicitly requests local implementation. Local-write
authorization permits server-side request builders, adapters, handlers, mock
transport bindings, synthetic fixtures, and no-network tests in the scoped
project. It does not authorize a real API call or a browser/mobile integration
that exposes `X-API-Key`.

## Scope and handoffs

After this Skill is selected, read the generated [OpenAPI
contract](references/openapi.md) and reviewed [runtime
behavior](references/runtime.md). If retry, idempotency, error translation, or
production architecture is requested, also read
`references/shared/integration-boundaries.md`. If either generated reference is
missing, stale, or conflicts with the pinned source, report the drift and stop
instead of guessing.

The allowlist is exact:

| Intent | Method and path | operationId |
| --- | --- | --- |
| Mark received message as read | `POST /whatsapp/inboundMessages/{id}/markAsRead` | `whatsapp_inbound_message-mark-as-read` |
| Mark as read and show typing | `POST /whatsapp/inboundMessages/{id}/typing` | `whatsapp_inbound_message-typing` |

The Webhook Receiver owns signature verification, exact raw-body handling,
durable acceptance, deduplication, and parsing of
`whatsapp.inbound_message.received`. This Skill begins only after that boundary.
Consume `event.whatsappInboundMessage.id` or its `wamid`; never substitute the
webhook envelope's `event.id`. Return acknowledgement results to the receiver's
asynchronous business-processing path without changing its already-issued HTTP
response.

Route message composition or sending to `ycloud-whatsapp-messages`, API-key
configuration to `ycloud-api-authentication`, webhook endpoint/receiver work to
`ycloud-webhook-endpoints`, and broad multi-domain work to
`ycloud-integration-architect`. Readiness and repository-maintenance workflows
are outside this Skill.

## Contract-first workflow

1. Confirm the selected operation's source hash, exact method/path,
   `operationId`, path parameter, response schemas, and descriptions in the
   generated references. Do not infer SDK methods from operation IDs.
2. Treat `{id}` as an opaque, case-sensitive path value. The operation accepts
   the YCloud inbound-message ID or the original WhatsApp `wamid`. Preserve the
   value, encode it as one URL-path segment, support contract-compatible future
   formats, and never parse prefixes or impose a local wamid grammar. Neither
   operation has a request body.
3. Preserve the effects exactly. `markAsRead` also marks earlier messages in
   the 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-media
description: Design, implement locally, or evaluate the YCloud WhatsApp media upload contract, multipart request and response handling, and media-to-message handoff. Use for media upload integration; do not use for sending messages, template lifecycle, readiness, broad integration planning, or real API operations.
---

# YCloud WhatsApp Media

Design or implement a contract-aware media upload integration. Keep this skill
limited to the one media-upload operation and the handoff that follows it.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor Architect handoffs for `scope`, `deliverable`, `mutation`, capability IDs,
project seams, and expected evidence. Without one, default to focused scope and
read-only guidance unless the user explicitly requests local implementation.
Local-write authorization permits multipart builders, adapters, handlers,
test-console bindings, synthetic fixtures, and no-network tests inside the scoped
project. It does not authorize opening or transmitting a real user file or
calling the upload API. Reuse the project's existing UI/interface stack; do not
create a dashboard or select a framework without user/project support.

## Trigger boundary

Use this skill when the user asks to upload WhatsApp media, construct the upload
request, interpret its response, or connect an upload result to a later message.
Route these requests elsewhere:

- Send a message, including a message that references an existing media object: hand off to `ycloud-whatsapp-messages`.
- Create, edit, list, retrieve, delete, or analyze a template: hand off to `ycloud-whatsapp-templates`.
- Design a multi-domain YCloud integration: hand off to `ycloud-integration-architect`.
- Check Developer Kit readiness or run repository-maintenance/issue-tracker workflows: do not trigger this skill.
- Download, inspect, or transmit a real local file: stop and use a synthetic fixture instead.

Do not load the complete OpenAPI document. Read only
`references/openapi.md` and `references/runtime.md` after this skill has been selected. If retry, idempotency, queueing, or error translation is requested, also read `references/shared/integration-boundaries.md`. Treat the exact
source path, method, operationId, schema, and constraints in that generated
reference as authoritative. If the reference is missing, stale, or conflicts
with the pinned source, report the drift and stop rather than guessing.

## Workflow

1. Identify the server-side project location and runtime only from files the user
   explicitly places in scope. Ask for missing facts; do not assume a framework,
   SDK, package, deployment, or credential source. When local writes are
   authorized, preserve existing project patterns and concurrent edits.
2. Select the single upload operation documented in the reference:
   `POST /whatsapp/media/{phoneNumber}/upload`, operationId
   `whatsapp_media-upload`. Preserve its path parameter, multipart content type,
   required fields, request schema, response schema, and documented descriptions
   exactly as generated. Apply the standard error envelope, request ID, generic
   `429` headers, documented `413 CONTENT_TOO_LARGE`, the one-file rule,
   reviewed media type/size limits, and 30-day persistence from `runtime.md`.
   Reject multiple files locally even though the API would process only the
   first. Do not invent a media-specific quota, safe replay rule, idempotency,
  

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-messages
description: Design, implement locally, or evaluate contract-aware WhatsApp message submission and retrieval for direct, queued, or existing-template sends, including conditional request semantics and accepted-versus-final status handling. Use for message send/retrieve intent; exclude template lifecycle, media upload, webhook endpoint management, authentication-only, readiness, and repository maintenance.
---

# YCloud WhatsApp Messages

Design or implement project-local support for the three message operations in the generated reference. Never call YCloud, send a real message, read credentials or customer data, or claim that a submission was delivered.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor Architect handoffs for `scope`, `deliverable`, `mutation`, capability IDs,
project seams, and expected evidence. Without one, default to focused scope and
read-only guidance unless the user explicitly requests local implementation.
Local-write authorization permits request builders, adapters, handlers,
test-console bindings, mocks, and no-network tests inside the scoped project. It
never authorizes a real send or retrieve call. A `test-console` must expose the
selected conditional message shapes and must reuse the project's existing UI or
interface stack; do not create a dashboard or choose a framework on your own.

## Scope and operation routing

Load `references/openapi.md` and `references/runtime.md` only after this Skill is selected. If the request includes retry, idempotency, outbox/queue, circuit breaking, or error translation, also read `references/shared/integration-boundaries.md`. The allowlist is exact:

| Intent | Method and path | operationId |
| --- | --- | --- |
| Direct submission | `POST /whatsapp/messages/sendDirectly` | `whatsapp_message-send-directly` |
| Queued submission | `POST /whatsapp/messages` | `whatsapp_message-send` |
| Retrieve by message ID | `GET /whatsapp/messages/{id}` | `whatsapp_message-retrieve` |

Sending an already-created template message belongs here. Creating, editing, listing, retrieving, deleting, or analysing a template belongs to `ycloud-whatsapp-templates`. Uploading media belongs to `ycloud-whatsapp-media`; receive its confirmed media reference before constructing a media message. API-key-only questions belong to `ycloud-api-authentication`; broad/multi-domain planning belongs to `ycloud-integration-architect`. Readiness, repository-maintenance, and issue-tracker workflows are out of scope.

## Contract-first workflow

For an explicitly requested local sandbox/mock path, also read
`references/shared/sandbox-contract.md`. Use its fixed synthetic key, sender,
recipient, base URL, scenarios and lifecycle controls only in tests. Never expose
`X-YCloud-Mock-*` or `/_mock/*` as provider contract, and never let a mock
`accepted` result satisfy final delivery evidence.

1. Confirm the selected operation’s exact path, method, parameters, request schema, response schema, and descriptions in the generated reference. If the source/reference hash or operation list drifts, stop and report it.
2. For direct versus queued requests, preserve endpoint-specific fields and semantics from the reference. Do not substitute one endpoint for the other or imply that a queue is a delivery guarantee.
   For queued template messages, preserve the reference’s confirmed rule that the referenced template must be `APPROVED`; an `A

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-phone-numbers
description: Design, implement locally, or evaluate YCloud WhatsApp business phone-number inventory, registration, profile, display-name, Business Username, contact-book, Calling/capture settings, and commerce settings operations. Use for phone-number management; exclude WABA management, message sending, template lifecycle, WhatsApp Calling sessions, and real API mutations.
---

# YCloud WhatsApp Phone Numbers

Design or implement contract-aware support for the fifteen phone-number
operations in the generated reference. Never call YCloud or Meta, read
credentials or customer data, or mutate a real phone-number resource.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor Architect handoffs for `scope`, `deliverable`, `mutation`, capability IDs,
project seams, and expected evidence. Without one, default to focused,
read-only guidance unless the user explicitly requests local implementation.
Local-write authorization permits request models/builders, adapters, handlers,
service bindings, mocks, synthetic fixtures, and no-network tests in the
scoped project. Register, PATCH, settings save, and both DELETE operations are
mock-only. Reuse the project's existing interface stack and preserve concurrent
work.

Load [the generated OpenAPI reference](references/openapi.md) and
[the reviewed runtime reference](references/runtime.md) only after this skill is
selected. If retry, idempotency, queueing, or error translation is requested,
also read `references/shared/integration-boundaries.md`. Exact paths, schemas,
responses, and descriptions come from `openapi.md`; cross-cutting pagination,
error, request-ID, rate-limit, and compatibility behavior comes from
`runtime.md`. If either generated reference is missing, stale, or inconsistent
with its recorded source hash and operation count, report drift and stop rather
than reconstructing the contract from memory.
For phone-number list work, also read
[`references/shared/pagination-contract.md`](references/shared/pagination-contract.md).

## Exact operation scope

| Intent | Method and path | operationId |
| --- | --- | --- |
| List phone numbers | `GET /whatsapp/phoneNumbers` | `whatsapp_phone_number-list` |
| Retrieve phone number | `GET /whatsapp/phoneNumbers/{wabaId}/{phoneNumber}` | `whatsapp_phone_number-retrieve` |
| Retrieve Business Username | `GET /whatsapp/phoneNumbers/{wabaId}/{phoneNumber}/businessUsername` | `whatsapp_phone_number-retrieve-business-username` |
| Update Business Username | `PATCH /whatsapp/phoneNumbers/{wabaId}/{phoneNumber}/businessUsername` | `whatsapp_phone_number-update-business-username` |
| Delete active Business Username | `DELETE /whatsapp/phoneNumbers/{wabaId}/{phoneNumber}/businessUsername` | `whatsapp_phone_number-delete-business-username` |
| Retrieve username suggestions | `GET /whatsapp/phoneNumbers/{wabaId}/{phoneNumber}/businessUsername/suggestions` | `whatsapp_phone_number-retrieve-business-username-suggestions` |
| Delete Meta contact-book entry | `DELETE /whatsapp/phoneNumbers/{wabaId}/{phoneNumber}/contactBook/{bsuid}` | `whatsapp_phone_number-delete-contact-book-entry` |
| Update display name | `PATCH /whatsapp/phoneNumbers/{wabaId}/{phoneNumber}/displayName` | `whatsapp_phone_number-update-displayName` |
| Retrieve profile | `GET /whatsapp/phoneNumbers/{wabaId}/{phoneNumber}/profile` | `whatsapp_phone_number-retrieve-profile` |
| Update profile | `PATCH /what

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: ycloud-whatsapp-templates
description: Design, implement locally, or evaluate YCloud WhatsApp template create, list, retrieve, edit, delete, and analytics operations. Use for template lifecycle integration; do not use for sending template messages, media uploads, readiness, broad integration planning, or real template/API mutations.
---

# YCloud WhatsApp Templates

Design or implement safe, contract-aware WhatsApp template lifecycle and
analytics work. This skill never mutates a real template.

## Execution boundary

These restrictions govern Skill execution: do not call a YCloud Provider API, access real credentials, or read real business data. The Skill may generate server-side adapter code for an application's runtime, but must not start it or make a live request. Reading public official documentation as contract evidence is allowed and is not a Provider API call or business-data access. A live smoke test is outside the default workflow and requires separate, explicit authorization naming the target/environment, allowed operations, credential boundary, and required result evidence.

Honor Architect handoffs for `scope`, `deliverable`, `mutation`, capability IDs,
project seams, and expected evidence. Without one, default to focused scope and
read-only guidance unless the user explicitly requests local implementation.
Local-write authorization permits request models/builders, adapters, handlers,
component editors, test-console bindings, mocks, and no-network tests in the
scoped project. It does not authorize create, edit, delete, analytics, or any
other real API call. Reuse the project's existing UI/interface stack and do not
generate a dashboard or bind a framework without user/project support.

## Trigger boundary

Use this skill for template creation, listing, retrieval, editing, deletion, or
analytics. A request to send a message that happens to use a template belongs to
`ycloud-whatsapp-messages`, even when the template already exists. A request to
upload media belongs to `ycloud-whatsapp-media`. Broad integration design belongs
to `ycloud-integration-architect`; readiness, repository-maintenance, and issue-tracker prompts do
not trigger this skill.

Read only `references/openapi.md` and `references/runtime.md` after selection.
For create requests, component editors, or template smoke tests, also read
`references/create-examples.json`. If retry, idempotency, queueing, or error
translation is requested, also read `references/shared/integration-boundaries.md`. The generated OpenAPI reference is
the contract index for the seven allowlisted template operations: create, list,
retrieve, edit, delete-by-name, delete-by-name-and-language, and analytics. Use
the exact source-derived path, method, operationId, parameter, schema, response,
and descriptions from the reference; do not guess names or paths from prose.
For template-list work, also read `references/shared/pagination-contract.md`.
Interpret `allOf` as schema composition and `x-*` extensions or generated model
names as codegen hints, not additional lifecycle behavior.
If source hash, operation coverage, or reference content drifts, report the drift
and stop.

## Workflow

1. Establish the user’s intended lifecycle operation and the target server-side
   project context. Ask for missing language, framework, environment, or
   template identity rather than inferring them.
2. Match exactly one of the seven operations in the generated reference. Keep
   lifecycle operations separate from message sending. Preserve source-defined
   path parameters, request/response schemas, enum values, and description-only
   constraints. Use the runtime reference for the shared Management API quota,
   standard error envelope, request ID, pagination behavior, edit replacement
   semantics, extensible status handling, and documented template error codes.
   Do not fill gaps with imagined safe replay, idempotency, approval states,
   delivery semantics, or analytics meanings.
3. Gen

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 6 — file references are metadata, not package contents.