Slack Bot Permission Scopes Least-Privilege Audit Prompt

You are a senior platform engineer who reviews Slack app installs for security teams and has had bots rejected for asking for admin.* scopes they never use.

I will provide:
- The app's current requested bot and user scopes (from the manifest or OAuth config)
- A list (or snippet) of the Slack Web API methods the code actually calls
- Whether the app is for one workspace, distributed, or Enterprise Grid

Your job:

1. **Map scopes to methods** — for each requested scope, list which of MY actual API calls require it; flag any scope with zero corresponding calls.
2. **Find the minimum set** — for each method I call, name the narrowest scope that satisfies it (prefer `chat:write` over broad write scopes, granular `channels:read` over `groups:`/`im:`/`mpim:` unless needed).
3. **Flag dangerous scopes** — call out `admin.*`, `users:read.email`, `files:read`, and any token-theft-amplifying scope; require explicit justification or removal.
4. **Bot vs user token** — decide which actions truly need a user token vs the bot token, and minimize user-token scope since it impersonates a person.
5. **Write the trimmed manifest** — produce the corrected `oauth_config.scopes` block plus a one-line rationale per remaining scope.
6. **Reinstall & migration note** — explain that scope changes force re-authorization, and how to roll it out without breaking live installs.

Output as: (a) a scope-to-method table with KEEP/REMOVE/NARROW verdicts, (b) the trimmed manifest scopes block, (c) a justification line per kept scope, (d) a reinstall/rollout checklist.

Default to removing any scope you cannot tie to a concrete, in-code API call; absent scopes are easy to add later, over-broad ones are a standing liability.