The 2am problem
A deploy fails at 2am. Your on-call engineer is asleep, so someone guesses from a stack trace and ships a patch on hope. By morning the context is gone — no record of what was tried, evidence scattered across CI, logs, dashboards, and chat. usezombie owns the outcome instead. An agent is a durable runtime described in two markdown files —SKILL.md (the senior engineer’s playbook in prose) plus TRIGGER.md (which tools the agent can reach and which events wake it). When a trigger fires, the agent gathers the evidence, reasons over it, posts an evidenced diagnosis to your Slack channel, and keeps a replayable log of every move it made.
The flagship platform-ops wakes on a GitHub Actions deploy failure, pulls workflow logs + your hosting provider’s app state + your data-plane’s health, and posts a one-paragraph diagnosis with a leading hypothesis. The same agent is reachable via zombiectl steer for a manual investigation. The runtime is open source, you bring your own model and pay your provider directly, and the agent never sees your raw keys — only ${secrets.NAME.FIELD} placeholders, swapped for real values outside the sandbox.
Get started
platform-ops goes from a cold machine to a real diagnosis in Slack in about ten minutes. Install the CLI, add the host skills, and sign in:
SKILL.md + TRIGGER.md into your repo. From there, behaviour iterates on prose, not redeploys.
Full quickstart →
Sign in, install
platform-ops, and trigger a real diagnosis — step by step from a cold machine.Explore
Concepts
Tenants, workspaces, agents, tools — the four nouns.
Authoring an agent
Write your own
SKILL.md + TRIGGER.md.CLI reference
Every
zombiectl command, with examples.GitHub
Source, issues, design partners welcome.