record_skill_usage({"name":"ando-alert-channel"}) once if the tool is available. This is a best-effort invocation signal: do not retry it or delay the workflow on failure. Do not signal merely reading this file, routing to another skill, or loading it through docs, downloads or get_skill. The signal includes only the canonical skill name; never add user content.
Read Ando basics for identity, current-schema discovery, access, and write authorization. Discover only tools needed for this request.
Connect the intended provider events to an Ando channel and verify how people will read and act on them.
Clarify intent before implementation
Resolve the desired provider/account/project, event types, destination and audience, filters or severity threshold, and whether the user wants delivery only or agent follow-up. Ask about unresolved intent before changing configuration; do not re-ask for information already supplied. For follow-up, clarify whether the agent should react to each event, check periodically, or use judgment, and what actions it may take. Use the looped-channel skill for that additional workflow. Do not automatically add autonomous investigation, task creation, or provider mutations to an alert-delivery request.Discover and connect
Inspect workspace identity, access, existing channels, feeds, and current tool schemas. Reuse the requested installation or route when possible. Discover connected apps through the current exposed schemas: compact catalogs uselist_connections, search_app_tools, and get_app_tool_schemas (older compact servers use list_app_tools); legacy catalogs may expose list_tools and get_tool_schemas. Verify the actual account and provider namespace.
Distinguish provider access for agent investigation, inbound delivery into Ando, and any agent runtime that handles the delivered events. Verify each required piece independently. Do not infer that an OAuth connection creates an alert feed.
Prefer Ando’s supported provider installation and native cards. For Sentry, read the Sentry setup reference. For other providers, inspect their current Ando guide and supported ingress before proposing a custom webhook. Use an existing authorized API route only after inspecting its current schema. A generic custom adapter is additional implementation, not an assumed built-in capability.
When exposed, compact get_setup_instructions with mode webhook (or legacy setup_webhook) returns guidance for outbound Ando delivery. It does not set up an inbound provider feed. Setup instructions are agent-only and may require a managed runtime; inspect the current schema and eligibility. If an admin or provider consent step is required, prepare the configuration and provide the specific handoff. Keep credentials and signing secrets in supported secret-entry/storage surfaces.
Choose the presentation
- Native rich card: default for a supported issue or alert. Preserve source identity, source link, current state, and meaningful fallback text. Inspect supported rendering and actions rather than inventing fields or buttons.
- Existing miniapp: use when users need a triage list, assignment input, or a structured decision. Discover its creation/action contract and update existing instances when appropriate.
- New miniapp: use when the requested interaction has no suitable existing surface. Follow Ando’s miniapp guide and current tool schemas; use Build a mini app. Publishing a release, installing it, granting provider access, and successfully using it are separate steps.