Menu
What to do after a container restart. Holds the per-skill daemon startup commands.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Use for any Microsoft account, personal or work (Outlook.com, Hotmail, Live, Microsoft 365); preferred over email-client for Microsoft accounts. Graph-based mail (read/send/reply/forward, drafts, flag/categorize, move/archive, folders, attachments, block senders), calendar and meetings, Microsoft Teams (chats, channels, presence), and new-mail/Teams notifications. Requires daemon.
Browse, navigate, click, fill forms, screenshot, or scrape web pages with a stealth (Camoufox) browser.
Design judgment and UI copy for building Vesta dashboard widgets that feel considered rather than templated, within the fixed design system.
Use before building or modifying the user's dashboard: widgets, pages, layouts, custom UI. Understand what the user wants, design it, write a spec, then dispatch the dashboard-builder to build it.
Use when someone who doesn't have their own vesta asks what vesta is, how to get one, or hints they want in. Vesta is invite-only: you gatekeep and build desire through scarcity, draw out what they want, then sell vesta as indispensable to their goals and set them up end-to-end in chat. Not for the owner, who already has one.
Talk to vestad, the host daemon that runs this container. Register a background service to get a port, build public URLs, update vestad to the latest release, check its version, and read gateway logs. Use when a skill needs an inbound port or a shareable link, when the user asks to update Vesta, or when debugging gateway/container issues.
| name | restart |
| description | What to do after a container restart. Holds the per-skill daemon startup commands. |
Read /run/vestad-env so the values are in your context (Read tool, not bash).
Run the Daemons block below; it is safe to re-run and starts only what's missing. Then check User State in MEMORY.md and reach out on their preferred channel. Match the moment: new day → warm; mid-convo restart → brief; crash → mention it; middle of the night → wait.
Skill setup steps add their daemon startup commands here, one fenced block per skill (a daemon that vestad proxies on a port is a service, registered via the vestad skill; a portless background process still goes here). Every line MUST be guarded with running <session> || so re-running the block can't spawn a duplicate: crash/timeout recovery re-enters this skill repeatedly, and an unguarded line piles up duplicate daemons.
# Wipe dead sockets a restart may have left in /run/screen, else the guard treats
# a "(Dead ???)" corpse as still-running and never restarts the daemon.
screen -wipe >/dev/null 2>&1 || true
# True iff a LIVE screen session with this exact name exists. Judge by captured
# output (test -n), not exit code: the agent's shimmed ugrep `grep -qv` returns 0
# on empty input, which would report every daemon as live on a cold boot.
running() { test -n "$(screen -ls 2>/dev/null | grep -E "[0-9]+\.$1[[:space:]]" | grep -v "Dead")"; }
# IMPORTANT: copy this definition verbatim from this file; never type it from
# memory or a system-reminder cache. A stale cached grep form matches nothing
# against a real session name, so running() returns false for a live session
# and `false || spawn` re-spawns on every guarded restart line, silently
# stacking duplicate daemons.
# Skills append guarded startup lines below, e.g.:
# running foo || { screen -dmS foo foo serve --notifications-dir ~/agent/notifications; sleep 1; }
# The trailing `sleep 1` keeps back-to-back `screen -dmS` launches from racing and dropping sessions.