Vision
wp-opencode is a setup tool that bootstraps a WordPress + Data Machine + OpenCode stack on a VPS, with a pluggable chat interface layer. The goal: run one script and get a fully operational AI-managed WordPress agent that you can talk to from anywhere.
Core Stack (always installed)
- WordPress — the site
- Data Machine — the brain (scheduling, memory, tools, publishing)
- OpenCode — the hands (coding agent)
- Homeboy — fleet ops CLI
Chat Interface Layer (pluggable)
The chat bridge is how you talk to your OpenCode agent. Pick one (or more):
| Flag |
Bridge |
Platform |
Status |
--chat kimaki |
Kimaki |
Discord |
✅ Working (chubes-bot reference) |
--chat telegram |
opencode-telegram-bot |
Telegram |
🔍 Evaluating (44 ⭐) |
--chat imessage |
TBD |
iMessage |
🔜 Needs building |
--chat sms |
TBD |
SMS/Text |
🔜 Needs building |
--chat slack |
TBD |
Slack |
🔜 Needs building |
--chat beeper |
TBD |
All (via Beeper) |
💡 Possible shortcut — one bridge for everything |
Each bridge follows the same pattern as Kimaki: receive message from platform → pipe to OpenCode → return response. The bridges are independent — swap or stack them without touching the core stack.
Reference Implementation
chubes-bot (178.156.237.104 / chubes.net) is the working reference using Kimaki (Discord).
Kimaki systemd service (/etc/systemd/system/kimaki.service):
[Unit]
Description=Kimaki Discord Bot
After=network.target
[Service]
Type=simple
User=root
WorkingDirectory=/var/www/chubes.net
Environment=HOME=/root
Environment=PATH=/root/.bun/bin:/usr/local/bin:/usr/bin:/bin
Environment=BUN_INSTALL=/root/.bun
ExecStart=/usr/bin/kimaki --data-dir /root/.kimaki --auto-restart --no-critique
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
OpenCode config (/var/www/chubes.net/opencode.json):
{
"$schema": "https://opencode.ai/config.json",
"model": "anthropic/claude-opus-4-6",
"small_model": "anthropic/claude-haiku-4-5",
"agent": {
"build": {
"mode": "primary",
"model": "anthropic/claude-opus-4-6",
"prompt": "{file:./AGENTS.md}\n{file:./wp-content/uploads/datamachine-files/agent/SOUL.md}\n{file:./wp-content/uploads/datamachine-files/agent/MEMORY.md}"
},
"plan": {
"mode": "primary",
"model": "anthropic/claude-opus-4-6",
"prompt": "{file:./AGENTS.md}\n{file:./wp-content/uploads/datamachine-files/agent/SOUL.md}\n{file:./wp-content/uploads/datamachine-files/agent/MEMORY.md}"
}
}
}
Key facts from chubes-bot pilot:
- OpenClaw stopped & disabled (DM replaces it for crew agents)
- Kimaki
--memory disabled — Data Machine manages all state/memory
- ai-http-client is bundled in Data Machine, not a separate plugin
- DM stores API keys in
chubes_ai_http_shared_api_keys wp_option
gh CLI authenticated for GitHub operations
- Agent files (SOUL.md, MEMORY.md, USER.md) live in DM agent files directory
- OpenCode v1.2.2 (anomalyco/opencode)
What wp-opencode should do
Core setup (setup.sh)
- System deps — Install Node.js/Bun, PHP, MySQL/MariaDB, Nginx, Composer, git, gh CLI
- WordPress — Install WP-CLI, download WordPress, configure wp-config.php, create database
- Data Machine — Clone/deploy plugin, activate, configure API keys
- OpenCode — Install, generate
opencode.json with DM agent file paths
- Homeboy — Install binary, register as component/project/server
- Agent files — Bootstrap SOUL.md, MEMORY.md, USER.md, AGENTS.md templates
- Nginx — Configure vhost with SSL (Let's Encrypt)
- Security — fail2ban, UFW, SSH hardening, non-root service user
- Chat bridge — Install selected bridge(s) based on
--chat flag
Non-root by default
chubes-bot runs everything as root. wp-opencode should:
- Create a dedicated service user (e.g.
opencode or agent)
- Run chat bridge systemd service as that user
- WordPress owned by
www-data, agent user in www-data group
- OpenCode runs as the service user
- SSH keys for the service user (fleet access)
- Homeboy config in service user home dir
Chat Bridge Interface
Each bridge should implement a common pattern:
- Receive message from platform
- Invoke OpenCode with the message (via
opencode run or server mode)
- Return OpenCode's response to the platform
- Handle threads/sessions for context continuity
Bridges are installed as systemd services alongside the core stack.
Configuration
The setup script should accept or prompt for:
- Domain name — for Nginx/SSL
- Chat bridge — which platform(s) to install
- Platform credentials — Discord bot token, Telegram bot token, etc.
- API keys — Anthropic (OpenCode), OpenAI (Data Machine)
- GitHub token — for
gh CLI auth
- Agent identity — name, role
- Fleet registration — Command server IP for fleet membership
Templates
Ship workspace templates:
SOUL.md — agent identity template
MEMORY.md — initial memory structure
USER.md — captain/user context template
AGENTS.md — coding standards and agent instructions
opencode.json — OpenCode config template with DM agent file paths
Open Questions
Phases
Phase 1: Core setup script
setup.sh that provisions WordPress + Data Machine + OpenCode + Kimaki on a fresh Ubuntu VPS.
Phase 2: Templates & agent files
Workspace templates, AGENTS.md, opencode.json generation.
Phase 3: Fleet integration
Auto-register with Command server, Homeboy project/server/component setup, SSH key exchange.
Phase 4: Non-root hardening
Dedicated service user, Plasma Shield integration, fail2ban whitelisting.
Phase 5: Additional chat bridges
Telegram, iMessage, SMS, Slack bridges — following the Kimaki pattern.
Related
Vision
wp-opencode is a setup tool that bootstraps a WordPress + Data Machine + OpenCode stack on a VPS, with a pluggable chat interface layer. The goal: run one script and get a fully operational AI-managed WordPress agent that you can talk to from anywhere.
Core Stack (always installed)
Chat Interface Layer (pluggable)
The chat bridge is how you talk to your OpenCode agent. Pick one (or more):
--chat kimaki--chat telegram--chat imessage--chat sms--chat slack--chat beeperEach bridge follows the same pattern as Kimaki: receive message from platform → pipe to OpenCode → return response. The bridges are independent — swap or stack them without touching the core stack.
Reference Implementation
chubes-bot (178.156.237.104 / chubes.net) is the working reference using Kimaki (Discord).
Kimaki systemd service (
/etc/systemd/system/kimaki.service):OpenCode config (
/var/www/chubes.net/opencode.json):{ "$schema": "https://opencode.ai/config.json", "model": "anthropic/claude-opus-4-6", "small_model": "anthropic/claude-haiku-4-5", "agent": { "build": { "mode": "primary", "model": "anthropic/claude-opus-4-6", "prompt": "{file:./AGENTS.md}\n{file:./wp-content/uploads/datamachine-files/agent/SOUL.md}\n{file:./wp-content/uploads/datamachine-files/agent/MEMORY.md}" }, "plan": { "mode": "primary", "model": "anthropic/claude-opus-4-6", "prompt": "{file:./AGENTS.md}\n{file:./wp-content/uploads/datamachine-files/agent/SOUL.md}\n{file:./wp-content/uploads/datamachine-files/agent/MEMORY.md}" } } }Key facts from chubes-bot pilot:
--memorydisabled — Data Machine manages all state/memorychubes_ai_http_shared_api_keyswp_optionghCLI authenticated for GitHub operationsWhat wp-opencode should do
Core setup (
setup.sh)opencode.jsonwith DM agent file paths--chatflagNon-root by default
chubes-bot runs everything as root. wp-opencode should:
opencodeoragent)www-data, agent user inwww-datagroupChat Bridge Interface
Each bridge should implement a common pattern:
opencode runor server mode)Bridges are installed as systemd services alongside the core stack.
Configuration
The setup script should accept or prompt for:
ghCLI authTemplates
Ship workspace templates:
SOUL.md— agent identity templateMEMORY.md— initial memory structureUSER.md— captain/user context templateAGENTS.md— coding standards and agent instructionsopencode.json— OpenCode config template with DM agent file pathsOpen Questions
opencode run?Phases
Phase 1: Core setup script
setup.shthat provisions WordPress + Data Machine + OpenCode + Kimaki on a fresh Ubuntu VPS.Phase 2: Templates & agent files
Workspace templates, AGENTS.md, opencode.json generation.
Phase 3: Fleet integration
Auto-register with Command server, Homeboy project/server/component setup, SSH key exchange.
Phase 4: Non-root hardening
Dedicated service user, Plasma Shield integration, fail2ban whitelisting.
Phase 5: Additional chat bridges
Telegram, iMessage, SMS, Slack bridges — following the Kimaki pattern.
Related