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>
1.6 KiB
1.6 KiB
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:
- Leelo entero
- Mostrale al usuario
- Pediles confirmación O ajustes
- Si hay ajustes, volvés a invocar
wxo-architectcon los cambios - Cuando el usuario aprueba, pasamos a la Fase 4 (dispatch paralelo)