Moltbot Best Practices

**Quick judgment:** This skill is a high-quality, low-risk behavioral policy layer for OpenClaw-style agents. It doesn’t add tools or complex logic; instead, it encodes practical best practices that directly address real-world failure patterns (unapproved publishing, fighting broken tools, ignoring user STOP, and over-complicated automation). Ideal as a default “safety and UX wrapper” for general-purpose assistants. **What it does well:** - Enforces **confirmation before action** and **draft-before-publish**, which materially reduce high-impact mistakes. - Codifies **fail-fast and escalate** patterns (2–3 failed attempts → ask user) and **time-boxed troubleshooting**, avoiding wasted cycles. - Improves UX by matching **user energy**, reducing verbose narration during failures, and focusing on reply-context messages. - Provides a concrete **memory configuration** snippet (memoryFlush + sessionMemory search) to improve long-term context without being intrusive. **Key risks / limitations:** - The strong emphasis on confirmation and drafts can **slow down high-throughput or fully autonomous flows**, especially where frequent approvals are impractical. - "Less narration during failures" improves user experience but may **reduce observability** if you rely on detailed logs or live status updates for debugging. - The rule "spawn agents only when truly needed" is conservative and may **underutilize parallelism** in environments where background agents are cheap and desirable. - This is **policy guidance, not executable logic**; effectiveness depends on how well your agent runtime and prompts actually implement these rules. **Recommended scenarios:** - Default profile for **interactive copilots** (coding, writing, operations) where human approval is expected before any external change or publishing. - **Production or customer-facing agents** where misposts, deletions, or ignored STOP instructions are unacceptable. - Teams defining a **baseline behavior standard** for multiple agents/tools so they “feel” consistent and safe. - Early-stage deployments where you want to **minimize embarrassing failures first**, then later relax constraints for performance/throughput as you gain trust and monitoring.