Design a Discoverable Teams Bot Command Menu in the Manifest Prompt

You are a senior bot engineer who has shipped Teams ChatOps bots where discoverability and safe defaults drove adoption and cut support load.

I will provide:
- The bot's command surface (e.g. deploy, status, rollback, logs, oncall, help)
- Where it runs (personal chat, team/channel, group chat) and who uses it
- The manifest schema version in use and whether it is a bot-only or multi-capability app

Your job:

1. **Author the `commandLists` block** in the manifest:
   - Group commands under `bots[].commandLists` with the correct `scopes` (`personal`, `team`, `groupChat`)
   - Give each command a concise `title` (what the user types) and a `description` that shows a parameter hint, e.g. `deploy <service> to <env>`
   - Order commands by frequency; put `help` and `status` first for discoverability
   - Explain that this menu renders as the command list in the compose box — it advertises, it does not execute

2. **Match menu to handler grammar**:
   - Keep the advertised syntax identical to what the bot's mention/command parser actually accepts
   - Account for the leading `@BotName` mention in team scope vs. no mention in personal scope
   - Note reserved/duplicate-title pitfalls and casing behavior

3. **Design the help + error fallback**:
   - A `help` command that lists every command with examples (single source of truth generated from the same command registry that drives the menu)
   - An unknown-command handler that suggests the closest match and points to `help`
   - A per-command usage message when required parameters are missing

4. **Layer safety on top** (menu is not authz):
   - Server-side RBAC check per command before any action
   - Confirmation card (Action.Submit) for destructive commands, with the target service/env echoed back
   - Audit log of who invoked what, from which channel

5. **Cover scope differences**:
   - Which commands make sense in `personal` vs `team` vs `groupChat`
   - Commands hidden from a scope should not appear in that scope's command list
   - Sideloading/validation: how to test the menu in the Developer Portal / Teams Toolkit before publishing

6. **Keep the registry DRY**: one command definition that emits (a) the manifest `commandLists`, (b) the parser routes, and (c) the `help` output — so they can never drift.

Output as: (a) the annotated manifest `bots[].commandLists` JSON per scope, (b) the command-registry structure that generates menu + parser + help, (c) the help and unknown-command fallback copy, (d) the RBAC + confirmation gate for destructive commands, (e) a pre-publish test checklist.

Bias toward: menu syntax that exactly matches the parser, help as a generated single source of truth, and server-side authorization independent of the menu.