Convertí mis workflows de agentes en un marketplace reutilizable
Armé tobias-agent-toolkit, un marketplace personal para distribuir workflows, skills, agents y reglas entre Claude Code y Codex desde una sola fuente de verdad. El objetivo no fue hacer otro set de prompts, sino convertir mi forma de trabajar con agentes en tooling versionado, instalable y mantenible.
Problema
Venía usando agentes para desarrollar con más estructura: explorar antes de tocar código, bajar cambios a specs, aplicar por tareas, revisar contra el contrato y archivar lo aprendido. El flujo funcionaba, pero estaba demasiado pegado a cada herramienta y a cada repo. El problema no era escribir mejores prompts una vez. El problema era poder reutilizar el criterio: mismas reglas, mismos pasos, mismos nombres y misma forma de pensar, aunque cambie la CLI o el proyecto. Cuando ese conocimiento queda repartido entre chats, markdowns sueltos y memoria personal, se vuelve difícil de mantener.
Solución
Construí tobias-agent-toolkit como un marketplace multi-agente. La idea central es tener una sola fuente de verdad en core/ y generar adapters finos para Claude Code y Codex. Hoy el repo publica cuatro plugins: tat-core para infraestructura y updates, tat-opsx-openspec para el flujo OPSX sobre OpenSpec, tat-review-tools para revisión y gobernanza, y tat-explain-tools para entender sistemas existentes. El detalle importante es que no edito los adapters a mano. Los workflows, skills, commands, agents, rules y templates viven en core/. Después npm run build genera lo que necesita cada entorno. Claude recibe además commands, hooks y agents; Codex recibe skills y rules. Esa diferencia queda modelada en el build, no en duplicación manual.
Aprendizaje
El aprendizaje más fuerte fue que un buen workflow con agentes necesita distribución, no solo documentación. Si cada proyecto depende de que yo recuerde copiar el último prompt, el sistema no escala. Si el flujo está versionado, instalable y validado contra drift, empieza a parecerse más a una herramienta real. También me ayudó a separar dos capas que antes mezclaba: la intención de trabajo y el adapter de la herramienta. OPSX no debería ser "un prompt para Claude" ni "un prompt para Codex". Debería ser un flujo propio, con adapters que respeten las capacidades y límites de cada runtime. Todavía queda por resolver instalación automática para Codex, CI, MCP y una estrategia más madura de distribución. Pero el MVP ya valida la idea principal: mis workflows de desarrollo pueden vivir como producto interno, no como texto perdido en conversaciones.
TL;DR
Armé un marketplace personal llamado tobias-agent-toolkit para reutilizar workflows de agentes entre Claude Code y Codex. La fuente de verdad vive en core/ y genera adapters para cada CLI. Lo más importante no fue el código, sino el cambio de mentalidad: tratar mis flujos con agentes como tooling versionado e instalable, no como prompts sueltos.