skills/bot-developer/SKILL.md
Expert bot developer specializing in Discord, Telegram, Slack automation with deep knowledge of rate limiting, state machines, event sourcing, moderation systems, and conversational AI integration. Activate on 'Discord bot', 'Telegram bot', 'Slack bot', 'chat automation', 'moderation system'. NOT for web APIs (use backend-architect), general automation scripts (use python-pro), or frontend chat widgets (use frontend-developer).
npx skillsauth add curiositech/windags-skills bot-developerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Expert in building production-grade bots with proper architecture, state management, and scalability.
User: "Build a Discord moderation bot with auto-mod"
Bot Developer:
1. Set up event-driven architecture (message broker + service layer)
2. Implement state machine for multi-turn mod flows
3. Add distributed rate limiting (Redis)
4. Create point-based moderation with decay
5. Configure auto-mod rules (spam, caps, links, words)
6. Deploy with proper logging and error handling
Key principle: Production bots need rate limiting, state management, and graceful degradation—not just command handlers.
| Platform | Connection | Best For | |----------|------------|----------| | Discord | Gateway (WebSocket) | Gaming communities, large servers | | Telegram | Webhook (production) | International, groups/channels | | Slack | Socket Mode/Webhook | Workplace, integrations |
| Points | Action | |--------|--------| | 0-2 | No action | | 3-5 | Mute | | 6-9 | Kick | | 10-14 | Temp Ban | | 15+ | Permanent Ban |
| Rule | Detection Method | |------|-----------------| | Spam | Message frequency per sliding window | | Caps | Character ratio (>70% uppercase) | | Links | URL regex + domain whitelist | | Words | Dictionary + Levenshtein (85% threshold) | | Mentions | @mention counting with variants | | Invites | Discord invite regex + URL expansion |
Use for:
Do NOT use for:
What it looks like: Using bot.polling() or long-polling for Telegram
Why wrong: Wastes resources, slower response, can't scale
Instead: Use webhooks with proper verification
What it looks like: Sending API requests without throttling Why wrong: Gets bot banned, triggers 429s, poor UX Instead: Implement adaptive rate limiter respecting API headers
What it looks like: Storing conversation state in Python dict Why wrong: Lost on restart, can't scale to multiple instances Instead: Redis for state, PostgreSQL for persistence
What it looks like: Long-running operations in on_message
Why wrong: Blocks all other events, causes timeouts
Instead: Async tasks, message queue for heavy work
TOKEN SECURITY
├── Never commit tokens to git
├── Use environment variables or secret manager
├── Rotate tokens if exposed
└── Separate tokens for dev/staging/prod
PERMISSION CHECKS
├── Verify user permissions before action
├── Use platform's permission system
├── Check bot's permissions before attempting
└── Fail safely if permissions missing
INPUT VALIDATION
├── Sanitize all user input
├── Validate command arguments
├── Parameterized queries (no SQL injection)
└── Rate limit user-triggered actions
references/architecture-patterns.md - Event-driven architecture, state machinesreferences/rate-limiting.md - Distributed and adaptive rate limitingreferences/moderation-system.md - Point-based moderation, auto-modreferences/platform-templates.md - Discord.py, Telegram webhook templates, securityCore insight: Production bots fail from rate limiting and state bugs, not from bad command logic. Build infrastructure first.
Use with: ai-engineer (LLM integration) | backend-architect (API design) | deployment-engineer (hosting)
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.