app-chat

name	app-chat
description	The user's chat screen in the Vesta app (web, desktop, mobile). Reply to `source=app-chat` notifications via `app-chat send`. Requires daemon.

App Chat - CLI: app-chat

App chat is the built-in chat screen of the Vesta app on web, desktop, and mobile: the user's direct line to you, no third-party account involved. Messages the user types there arrive as source=app-chat notifications; replies sent with app-chat send appear in their chat live (and as a push notification when they are away). Treat it as a first-class messaging channel with the texting style below.

Setup

uv tool install --editable ~/agent/skills/app-chat/cli

Daemon: app-chat daemon start|stop|restart|status:

• Start is idempotent (a running daemon is a no-op)
• Stop marks the shutdown as intentional so it doesn't fire a daemon_died notification
• Status reports the daemon process state plus its service port and connected client count as JSON

Manage the daemon through these commands, not raw screen. Restart: Add to the ## Daemons section of ~/agent/skills/restart/SKILL.md:

running app-chat || { app-chat daemon start; sleep 1; }

app-chat daemon start registers the app-chat service (getting its port) and starts the HTTP server (intake, history, and the live /ws chat socket).

Quick Reference

app-chat daemon status
app-chat send --message 'Hello!'
app-chat history --search 'query'
app-chat history --limit 20

How it works

• The daemon is a registered service: it owns the app-chat channel, serving POST /message (intake) and GET /history on its registered port, backed by its own store (~/.app-chat/app-chat.db)
• When the app user sends a message, the service persists it and writes the source=app-chat notification itself, so a dead process never drops a message the app already showed as delivered
• You receive the notification and reply with app-chat send: the reply is persisted to the store, then fanned to any connected /ws chat sockets so the app sees it live
• Durability is the store, not the socket: a reply succeeds even with no client connected, and a client refetches history by id on reconnect to pick up anything it missed
• History and search read the same store: app-chat history and app-chat history --search

Notes

• Always reply to app messages using app-chat send, not through any other channel
• send enforces short-bubble texting: a wall (over ~220 chars, or any text after a full stop) is rejected so you re-send as several short calls, one thought each. Don't use full stops at all: a ., ! or ? may only close a bubble, never carry text after it. Ellipses stay free, they're a beat rather than a stop. For genuine reference material the user asked for (a brief, a code block, a list), pass --longform to bypass
• A numbered or bulleted list is fine to send as one message (each item is one short thought); a line-leading marker like 1. or 2) is not a full stop, so a list does not need --longform
• Send multiple short messages instead of one long one (like texting)
• Lowercase, no bullets, keep messages tight, texting feel, not document feel
• Messages render as markdown: use fenced ``` blocks for code/commands, [label](url) for links. Newlines work
• The app reconnects its chat socket automatically if the daemon or agent restarts