What this prompt does
This prompt builds a [platform] bot in Python for a [team_type], designed to [bot_purpose] and handle [expected_users] concurrent users. It lays out a modular architecture and works through the parts that actually matter in production: lifecycle handling with reconnection, [command_count] slash commands with cooldowns, interactive components with a state machine, scheduled tasks that survive restarts, external API integration, an admin system with an audit log, and robust error handling. The emphasis on reconnects, cooldowns, and persistent state is what separates a real ops tool from a toy.
The variables define the bot's surface and resilience. [bot_framework] and [auth_method] set the foundation, [command_count] and [primary_commands] define the command set with [cooldown_duration] rate limiting, and [interactive_elements] plus [conversation_flow] drive multi-step interactions via a state machine that expires after [session_timeout]. [scheduler_library], [scheduled_tasks], and [storage_backend] handle recurring jobs whose state outlives restarts, while [external_apis] and [admin_roles] cover integrations and permissions.
When to use it
- Building an internal Slack or Discord bot to offload repetitive ops work.
- Implementing slash commands with per-user
[cooldown_duration]cooldowns to prevent spam. - Driving multi-step flows like incident creation with a state machine that expires.
- Running scheduled jobs whose state survives bot restarts via
[storage_backend]. - Integrating external services like
[external_apis]with caching and rate-limit handling. - Adding an admin system with
[admin_roles]and an audit log for accountability.
Example output
You get a modular bot implementation with code: a project structure separating commands, events, tasks, and services; lifecycle handling with [auth_method] auth, graceful shutdown, and auto-reconnection; [command_count] slash commands ([primary_commands]) with type validation and [cooldown_duration] cooldowns; interactive components using [interactive_elements] and a state machine for [conversation_flow] expiring after [session_timeout]; [scheduler_library] jobs for [scheduled_tasks] with state in [storage_backend]; a service layer integrating [external_apis] with caching; an admin system with [admin_roles] and an audit log; and error handling routing failures to [error_channel].
Pro tips
- Make auto-reconnection non-negotiable; a bot that dies on a brief disconnect is useless for ops, so the lifecycle step must handle it.
- Add
[cooldown_duration]cooldowns to every command in[primary_commands]; without them, one impatient user can spam your integrations. - Persist state to
[storage_backend]so[scheduled_tasks]and in-flight[conversation_flow]sessions survive a restart instead of vanishing. - Cache
[external_apis]responses for the configured duration and handle their rate limits, or the bot will get throttled under load. - Keep an audit log of admin actions; for a bot wired into deployments and on-call, accountability is essential.
- Set a
[session_timeout]on multi-step flows so abandoned conversations clean themselves up instead of lingering. - Route unhandled exceptions to
[error_channel]with friendly user-facing messages, so the bot never crashes silently and the team sees failures fast.
