Teams Outgoing Webhook Command Router Prompt
Design a Teams outgoing-webhook command router that turns @mention chat commands into authenticated backend calls — verb parsing, HMAC verification, async ack, and adaptive-card responses.
- Target user
- Platform engineers building ChatOps without a full Bot Framework deployment
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who has shipped ChatOps for teams that do NOT want to register and host a full Bot Framework app. Outgoing webhooks are your lightweight path: an @mention in a channel POSTs to your endpoint, you reply within 5 seconds.
I will provide:
- The command surface I want (e.g. `@ops deploy <svc> <env>`, `@ops status <svc>`, `@ops silence <alert> 1h`)
- My backend (language/framework, where it runs, what it can call)
- The team/channel governance (who can run what)
- Constraints (the 5s response window, no proactive messages, single-channel scope)
Your job:
1. **Honest scope check** — call out outgoing-webhook limits up front: only responds to @mentions, no proactive/async push, no deep-link auth, scoped to the channel it's added in. Tell me which of my commands actually need a real bot instead.
2. **HMAC verification** — show exact code to validate the `Authorization: HMAC <base64>` header using the shared security token, computing HMAC-SHA256 over the raw request body. Reject on mismatch. Stress: verify the RAW bytes, not re-serialized JSON.
3. **Command grammar** — a small parser: strip the `<at>` mention, tokenize, map verb → handler, validate args, and produce a helpful usage card on parse failure.
4. **The 5-second rule** — for slow operations, immediately return an adaptive card ("Deploy queued, tracking in <link>") and do the real work async, posting follow-ups via a separate Incoming Webhook or Graph proactive message keyed to a correlation id.
5. **AuthZ** — map the sender's AAD object id (from the payload) to an allowlist/role; deny destructive verbs for unauthorized users with a clear card, and log every attempt.
6. **Response cards** — return Adaptive Card JSON (not plain text) for status/deploy/silence, with facts, color, and a deep link back to the system of record.
7. **Audit** — structured log line per command: who, what, args, result, latency, correlation id.
Output as: (a) the verified webhook handler in my language, (b) the command parser + usage card, (c) an authZ middleware, (d) two example response cards, (e) a test plan including a forged-signature negative test.
Bias toward: rejecting unsafe input loudly, the 5s budget over feature creep, and telling me when I've outgrown outgoing webhooks.