botops

The default bot every Tico install gets. BotOps operates the other bots: it sets up new ones from templates, works out why a run failed or got stuck, sweeps for crashed bots and stuck tasks on a schedule, upgrades bots to newer templates, and keeps bot repositories healthy.

It is not the bot that does your company's work. It builds and repairs the bots that do.

What it does

Job	Playbook
Set up a new bot from a template	playbooks/set-up-a-bot.md
Diagnose a failed, stuck, or wrong run	playbooks/diagnose.md
Find crashed bots and fix them (every 8 hours)	playbooks/crash-sweep.md
Find stuck tasks and move them (daily)	playbooks/task-sweep.md
Upgrade BotOps and other bots to a newer template	playbooks/upgrade-botops.md

Standing rules, in AGENT.md:

• Works up to three tasks in parallel, each in its own worktree.
• Every distinct request becomes its own task before work starts.
• Never merges a pull request on its own unless the company has enabled it (a line in memory/decisions.md).
• Asks the owner before anything irreversible: deleting, force-pushing, archiving, publishing, spending, changing permissions, activating a bot or turning on sending.
• Never reads, copies, or rotates a credential value.

How Tico installs it

Every Tico install creates BotOps in your own GitHub organization from this template:

1. The installer copies this repository to <your-org>/emp-botops (a template copy, not a fork, so your history is your own).
2. It fills the placeholders declared in template.json: company name, owner email, GitHub organization, and the runtime and model you chose at setup. employee.yaml leaves runtime and model as chosen at setup in this template; nothing is preset.
3. It registers the bot with the hub, seeds the two sweep routines from employee.yaml, and runs the readiness check.

To install by hand, create the repository from this template, replace the {{...}} placeholders, register it with hub bot create botops ..., and run hub bot check botops.

Customize

• Schedules: edit the schedules: block before install (or hub routine set afterwards). Set the timezone to yours.
• Merging: to let BotOps merge its own tested pull requests, record who decided it and for which repositories in memory/decisions.md. Without that line it always asks.
• Access: declare the services it needs under access: in employee.yaml (for example GitHub, with the narrowest can: list). Declaring access does not create it; the operator supplies credentials.
• Playbooks: these are plain markdown. Tighten them to your fleet as you learn. Put lessons in memory/learnings.md and facts about your bots in knowledge/.

Layout

AGENT.md          role, rules, how a run starts and ends (CLAUDE.md, AGENTS.md, GEMINI.md point here)
employee.yaml     name, labels, runtime/model (chosen at setup), routines, access
template.json     placeholders the installer fills
state.md          current focus and open threads
knowledge/        what this install knows about its fleet
memory/           learnings.md (how to do the job), decisions.md (dated decisions)
playbooks/        one checklist per kind of work
software/         small scripts BotOps writes for itself

Contributing

Lessons that are true for every Tico install belong here. Open a pull request that adds a learning to memory/learnings.md or tightens a playbook. Keep contributions generic: no company names, people, domains, account ids, or credentials. Use fictional Acme examples.

License

Apache-2.0. See LICENSE.