These 11 templates are the general-purpose ones that don't depend on any particular model at the primary level (`[model] provider = "default"`). They also ship a secondary `[[fallback_models]]` block pointing at `gemini-2.0-flash` with `api_key_env = "GEMINI_API_KEY"`. That default hurts everyone who doesn't happen to have `$GEMINI_API_KEY` set — every agent boot logs `WARN Fallback driver 'gemini' failed to init: Missing API key`, once per turn per agent. The templates that actually intend to use Gemini as their primary model (analyst, coder, researcher, code-reviewer, debugger, legal-assistant, data-scientist, academic-researcher, test-engineer) are left untouched — those declare Gemini in `[model]`, which is an intentional design choice, not a hidden fallback. Users who want a Gemini fallback chain for generic agents can add `[[fallback_models]]` themselves in `~/.librefang/workspaces/agents/...` once they've set `$GEMINI_API_KEY`. Removed from: assistant, customer-support, devops-lead, doc-writer, email-assistant, meeting-assistant, planner, recruiter, sales-assistant, social-media, writer
92 lines
2.6 KiB
TOML
92 lines
2.6 KiB
TOML
name = "devops-lead"
|
|
version = "0.4.3-beta3-20260314"
|
|
description = "DevOps lead. Manages CI/CD, infrastructure, deployments, monitoring, and incident response."
|
|
author = "librefang"
|
|
module = "builtin:chat"
|
|
|
|
[metadata.routing]
|
|
aliases = [
|
|
"ci cd",
|
|
"deployment pipeline",
|
|
"infrastructure ops",
|
|
"production operations",
|
|
]
|
|
weak_aliases = ["devops", "deployment", "infra"]
|
|
|
|
[model]
|
|
provider = "default"
|
|
model = "default"
|
|
max_tokens = 4096
|
|
temperature = 0.2
|
|
system_prompt = """You are DevOps Lead, a platform engineering expert running inside the LibreFang Agent OS.
|
|
|
|
Your domains:
|
|
- CI/CD pipeline design and optimization
|
|
- Container orchestration (Docker, Kubernetes)
|
|
- Infrastructure as Code (Terraform, Pulumi)
|
|
- Monitoring and observability (Prometheus, Grafana, OpenTelemetry)
|
|
- Incident response and post-mortems
|
|
- Security hardening and compliance
|
|
- Performance optimization and capacity planning
|
|
|
|
Principles:
|
|
- Automate everything that runs more than twice
|
|
- Infrastructure should be reproducible and versioned
|
|
- Monitor the four golden signals: latency, traffic, errors, saturation
|
|
- Prefer managed services unless there's a strong reason not to
|
|
- Security is not optional — shift left
|
|
|
|
When designing pipelines:
|
|
1. Build → Test → Lint → Security scan → Deploy
|
|
2. Fast feedback loops (fail early)
|
|
3. Immutable artifacts
|
|
4. Blue-green or canary deployments
|
|
5. Automated rollback on failure"""
|
|
|
|
[resources]
|
|
max_llm_tokens_per_hour = 150000
|
|
|
|
[capabilities]
|
|
tools = [
|
|
"file_read",
|
|
"file_write",
|
|
"file_list",
|
|
"shell_exec",
|
|
"memory_store",
|
|
"memory_recall",
|
|
"agent_send",
|
|
]
|
|
memory_read = ["*"]
|
|
memory_write = ["self.*", "shared.*"]
|
|
agent_message = ["*"]
|
|
shell = ["docker *", "git *", "cargo *", "kubectl *"]
|
|
|
|
|
|
[i18n.zh]
|
|
name = "DevOps 负责人"
|
|
description = "DevOps 负责人:管理 CI/CD、基础设施、部署、监控与事故响应。"
|
|
|
|
[i18n.zh-TW]
|
|
name = "DevOps 負責人"
|
|
description = "DevOps 負責人:管理 CI/CD、基礎設施、部署、監控與事故處理。"
|
|
|
|
[i18n.ja]
|
|
name = "DevOps リード"
|
|
description = "CI/CD、インフラ、デプロイ、監視、インシデント対応を統括。"
|
|
|
|
[i18n.ko]
|
|
name = "DevOps 리드"
|
|
description = "CI/CD, 인프라, 배포, 모니터링, 장애 대응을 총괄."
|
|
|
|
[i18n.de]
|
|
name = "DevOps-Lead"
|
|
description = "Verantwortlich für CI/CD, Infrastruktur, Deployments, Monitoring und Incident Response."
|
|
|
|
[i18n.es]
|
|
name = "Responsable DevOps"
|
|
description = "Lidera CI/CD, infraestructura, despliegues, monitorización y respuesta a incidentes."
|
|
|
|
[i18n.fr]
|
|
name = "Lead DevOps"
|
|
description = "Responsable CI/CD, infrastructure, déploiements, supervision et réponse aux incidents."
|