felipefontoura

For CONTRIBUTORS working inside a local clone of the bento repo — scaffold a new application stack (stacks/<category>/<key>/ with compose.yml + manifest.json + optional install.sh) and, when the app exposes a programmable API, a companion /bento:<key> operate skill, following repo conventions, then commit it for a PR upstream. This is NOT an operator/end-user skill; it edits and commits repo files. To DEPLOY an app onto a running VPS, use the bento plugin's deploy skill instead.

Operate the Chatwoot customer support platform via HTTP API on an already-deployed bento VPS — reply to a customer, send a support message, create a new conversation, list open conversations, assign a conversation to an agent, resolve or reopen a ticket, create or search a contact, list help desk inboxes, add a private note, filter conversations by status/inbox/team/label. Use when the user says "reply to a customer", "send a message to a contact", "create a support ticket", "list open chats", "assign this conversation", "resolve a ticket", "create a contact in chatwoot", "set up a help desk inbox", "check unassigned conversations", "list my inboxes", "add a note to a conversation", "search for a contact", "get chatwoot conversations", or any other day-2 support desk operation. Deploying Chatwoot itself is `/bento:deploy`.

Operate the Evolution API (WhatsApp gateway) on a bento VPS — create WhatsApp instances, get the QR code to connect a phone, check connection state, send WhatsApp messages (text and media), configure webhooks, list or delete instances, and manage the full lifecycle of a WhatsApp bot or integration. Use when the user says "send a WhatsApp message", "connect my WhatsApp", "get the QR code", "set up a WhatsApp bot", "configure a WhatsApp webhook", "create a WhatsApp instance", "disconnect WhatsApp", "check WhatsApp status", "link my phone number to the API", "scan the QR", "set up WhatsApp automation", or anything about getting WhatsApp to work on their server. Day-2 operation of the running app's HTTP API. Deploying the stack is `/bento:deploy`.

Operate the Hermes agent gateway on a bento VPS — chat with the agent over its OpenAI-compatible API, run the CLI (sessions, tools, config), and wire MCP servers so the agent gains new tools. Use when the user says "talk to my hermes agent", "call my agent from a script/bot", "add an MCP server to hermes", "give my agent the youtube/search tools", "list hermes sessions", "change the hermes model", or otherwise wants to drive a running hermes stack. Two surfaces: the HTTP API (:8642, Bearer) and the CLI (`docker exec ... hermes`). Deploying hermes itself is the deploy skill.

Operate MetaMCP on a bento VPS — add MCP servers to the gateway, group them into namespaces, create unified public endpoints, manage API keys, and get the URL to plug your tools into Claude/Cursor/an agent. Use when the user says "add an MCP server to my gateway", "group my MCP tools", "create an MCP endpoint", "create a namespace", "get the URL to plug my MCP tools into Claude or Cursor or an agent", "give my agent a bundle of MCP tools", "create an API key for my MCP endpoint", "set up MetaMCP", or otherwise wants to drive a running MetaMCP stack. Two surfaces: the web admin UI (primary, all CRUD) and tRPC procedures callable from the box (automation). Deploying MetaMCP itself is /bento:deploy.

Operate n8n (workflow automation) on a bento VPS THROUGH the n8n-mcp server — build, validate, deploy, and manage automation workflows by driving the n8n-mcp tools, not the raw REST API. Use when the user says "build an n8n workflow", "automate this with n8n", "add a node to my workflow", "fix my n8n workflow", "list/run my workflows", "connect a webhook", or describes an automation to wire up. Work via the n8n-mcp MCP tools (node schemas + validation baked in) — never hand-roll the n8n REST API. Deploying n8n/n8n-mcp themselves is the deploy skill.

Operate the Paperclip API on a bento VPS — create and configure agents, write their instruction bundles, import and sync skills, manage issues/projects/goals, and wire the official MCP server as a control plane. Use when the user says "create a paperclip agent", "configure my chiefs", "import skills into paperclip", "delete paperclip issues", "set up the paperclip MCP server", or otherwise wants to drive a running paperclip stack's API (not deploy it). Mutations go through the HTTP API with a Bearer board key — never raw DB writes. Deploying paperclip itself is the deploy skill.

Operate the Plunk email platform API on a bento VPS — send a transactional email, send an email to a user, track an email event, add a contact to my email list, trigger an email automation, create or update a contact, unsubscribe a contact, list contacts. Use when the user wants to drive a running Plunk stack's HTTP API for day-2 work: sending emails, managing contacts, or firing event-based automations. Plunk exposes two key types (secret sk_* for server-side operations, public pk_* for client-side event tracking) and sends through AWS SES. Deploying Plunk itself is `/bento:deploy`.

Chooses the correct next action for prospects based on offer readiness, awareness, trust, friction, price, urgency, and MVP maturity. Use after message-system to define CTA and acquisition path.

Consolidates all Pi Strategy artifacts into the final handoff file .ai/strategy/handoff/strategy-brief.md for downstream SDD, build, or go-to-market packages. Use after acquisition-path.

Initializes the Pi Strategy workspace in a project by creating .ai/strategy directories, index.md, and optional .ai/steering guidance. Use before running the strategy pipeline in a new or existing project.

Identifies whether a raw product, SaaS, devtool, community, course, method, or service idea has enough reachable market signal to continue. Use at the beginning of Pi Strategy before user, offer, MVP, or build work.

Turns offer, mechanism, MVP, and proof into clear technical messaging: positioning, promise, pillars, hooks, claims, objection matrix, CTA options, FAQ seeds, words to use/avoid, and a skeptical developer explanation. Use after proof-system.

Defines the smallest MVP or deliverable capable of proving the offer and mechanism. Use after product-offer and unique-mechanism, before proof, messaging, acquisition, downstream deliverables, or build planning.

Maps the surface problem, deeper problem, cost of inaction, failed attempts, desired outcomes, transformation gap, and priority problem. Use after market signal and user context, before offer creation.

Creates a product offer using the value equation from $100M Offers: dream outcome, perceived likelihood, time delay, effort/sacrifice, offer stack, risk reversal, pricing logic, naming, and one-liner. Use after problem/outcome.

Explicit command-style skill for implementing approved SDD tasks from tasks.md with tight scope, tests, and verification evidence. Use only when the user explicitly asks to execute or implement a specific approved SDD task or feature. Do not auto-load for discussion, planning, review, or unapproved tasks.

Conversational SDD skill for exploring raw product or feature ideas before planning. Use when the user wants to brainstorm, clarify, compare directions, or convert an early idea into a plan or requirements, even without an explicit command. Do not use for implementation or technical task execution.

Explicit command-style skill for initializing or adopting SDD in a project by creating or preparing .ai/, .ai/steering/, and .ai/sdd/. Use only when the user explicitly asks to initialize, set up, adopt, or bootstrap SDD. Do not auto-load for general planning, feature specs, status checks, or implementation.

Cognitive SDD skill for creating or updating optional PLAN.md from captured ideas or project goals. Use when the conversation calls for roadmap, personas, feature mapping, phases, dependencies, and open decisions before requirements, even without an explicit command. Do not use for feature-level requirements or coding.

Core cognitive SDD skill for creating or updating requirements.md from an approved idea, plan, or feature request. Use when the conversation calls for defining WHAT and WHY: user stories, acceptance criteria, EARS functional requirements, NFRs, and boundaries, even without an explicit command. Do not use for technical design or coding.

Cognitive SDD skill for reviewing an implementation against requirements.md, design.md, and tasks.md, producing review.md with coverage, findings, verification evidence, and merge readiness. Use when the conversation calls for review after implementation or before completion, even without an explicit command. Do not use to implement fixes directly.

Core cognitive SDD skill for creating design.md technical specifications from approved requirements. Use when the conversation calls for HOW decisions: architecture, components, data/state, APIs, flows, edge cases, technical decisions, risks, and implementation FAQ, even without an explicit command. Do not use for requirements creation, task breakdown, or coding.

Explicit command-style skill for inspecting .ai/sdd state and recommending the next safe action. Use only when the user explicitly asks for SDD status, progress, blockers, readiness, or next action. Do not auto-load for general SDD work; do not create specs or implement code.