b089c2ef18
Boilerplate completo para construir soluciones agénticas sobre IBM watsonx Orchestrate (ADK 2.x) con una capa web encima. Destilado de cotemar-poc-n1 y dun-casos-prueba. Incluye: - 11 docs (best practices, architecture patterns, ADK cheatsheet, observability, tool authoring, deployment, RUNBOOK, DEPLOY_TO_NEW_WOX, known-issues con 16 errores reales y fix, eval strategy, INDEX) - 13 templates WxO (orchestrator/specialist/single-meta agents, 3 connections, KB + runbook, observable_tool decorator, coercion helpers, Python tools, OpenAPI spec, backend filter endpoint, webhook validator HMAC, MCP connection) - 6 scripts (deploy idempotente con fallback ADK, undeploy, reset, check-adk-version, new-specialist scaffold, eval-agents runner) - 4 eval pieces (linter de best practices, runner, smoke-test, direct backend probe) + scenario templates - 8 subagentes Claude (.claude/agents/) — wxo-architect, wxo-agent-author, wxo-tool-author, runbook-author, mock-builder, backend-tool-builder, eval-author, web-layer-builder - Skill bundle fit-wxo-bootstrap/ (SKILL.md + 3 templates) listo para copiar a ~/.claude/skills/ - Web layer default FastAPI+HTMX con vista timeline observable + endpoint receptor de trazas - Docker compose Coolify-ready (healthcheck wget -qO-, sin labels Traefik, network split internal:true) - CI Gitea workflow con lint + smoke Best practices enforced por evals/lint_wxo_yaml.py: - A1: máx 10 tools por agente - A3: orchestrator sin tools de remediación - A6: agente sin propósito (react sin tools ni KB) - T1: @observable_tool obligatorio, no @tool directo - T3: _compat shim inline en tools.py - D1: docker-compose sin wget --spider - I-005: OpenAPI con description per-operation - I-009: sin labels Traefik manuales Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
57 lines
1.6 KiB
Markdown
57 lines
1.6 KiB
Markdown
# Prompt template — invocar el subagente `wxo-architect`
|
|
|
|
Cuando llamás al subagente `wxo-architect` (definido en `.claude/agents/wxo-architect.md`
|
|
del boilerplate clonado), usá este formato:
|
|
|
|
```
|
|
Sos el wxo-architect. Necesito que decidas la topología WxO para esta solución:
|
|
|
|
CASO DE USO:
|
|
[descripción completa de lo que el usuario te contó]
|
|
|
|
CLIENTE: [nombre]
|
|
|
|
CONTEXTO ADICIONAL:
|
|
[transcripción, RFP, email, etc. — pegar literal]
|
|
|
|
DOMINIOS IDENTIFICADOS POR EL USUARIO:
|
|
1. [dominio 1]
|
|
2. [dominio 2]
|
|
...
|
|
|
|
SISTEMAS EXTERNOS:
|
|
- [sistema A]: [tipo: mock | backend propio | SaaS con MCP | API existente]
|
|
- [sistema B]: ...
|
|
|
|
STACK WEB ELEGIDO: [FastAPI+HTMX | FastAPI+React]
|
|
|
|
OUTPUT:
|
|
Devolveme un documento markdown con todas las secciones del template de tu agente:
|
|
1. Resumen del caso
|
|
2. Dominios
|
|
3. Topología propuesta (Single | Multi-Specialist | Meta-Tool | Multi-Capa)
|
|
4. Agentes detallados (nombre, propósito, tools, KB, collaborators)
|
|
5. Tipo de tools por dominio
|
|
6. Sistemas externos y cómo se integran
|
|
7. Web layer
|
|
8. Runbooks a escribir
|
|
9. Evals scenarios mínimos
|
|
10. Riesgos / decisiones abiertas
|
|
|
|
APLICÁ ESTRICTAMENTE las reglas de docs/wxo-best-practices.md:
|
|
- Máx 10 tools por agente
|
|
- Domain specialists, no todistas
|
|
- Orchestrator nunca remedia
|
|
- KB opcional
|
|
- Patrón meta-tool si el flujo es lineal
|
|
```
|
|
|
|
## Iteración
|
|
|
|
Cuando el `wxo-architect` devuelva su propuesta:
|
|
1. Leelo entero
|
|
2. Mostrale al usuario
|
|
3. Pediles confirmación O ajustes
|
|
4. Si hay ajustes, volvés a invocar `wxo-architect` con los cambios
|
|
5. Cuando el usuario aprueba, pasamos a la Fase 4 (dispatch paralelo)
|