تشغيل أي مهارة في Manus بنقرة واحدة

infra-provisioning

النجوم٠

التفرعات٠

آخر تحديث١ يوليو ٢٠٢٦ في ٢٠:٠٦

Levanta y verifica la infraestructura local de un proyecto Spring Boot generado por la Fase 2 (base de datos, broker, cache, Keycloak, MinIO…) con Docker o Podman, y provee el cheatsheet de comandos CLI exactos por servicio para comprobar su estado. La usan el especialista `infra-provisioner` (Paso 0b) y el `flow-validator` (para verificar side effects). Úsala cuando necesites arrancar el compose, comprobar que un servicio está operativo, o consultar el comando CLI exacto de `psql`/`mysql`/`sqlcmd`/`sqlplus`, `kcat`, `redis-cli`, `mc`, o el health de Keycloak/RabbitMQ.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

asuridev

asuridev/dsl-springboot-generator

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مديرو الشبكات وأنظمة الحاسوبمهن الحاسوب والرياضيات·SOC 15-1244

مستكشف الملفات

2 ملفات

SKILL.md

readonly

name

infra-provisioning

description

Antes de empezar, lee las reglas inviolables y "cuándo detenerse" en la skill compartida .agents/skills/orchestration/SKILL.md.

Provisión y verificación de infraestructura

El especialista infra-provisioner deja la infraestructura local operativa para que el resto de la Fase 3 pueda validar flujos end-to-end. No implementa lógica de negocio ni toca .java, y no modifica docker-compose.yml: solo levanta (${COMPOSE} up -d) y verifica; si un servicio no levanta por un problema del compose, reporta el bloqueo, no lo edita.

status: ready exige que todos los servicios declarados en el compose estén up/healthy y que sus CLI tools respondan.

Guía de referencia

Guía (`references/`)	Contenido
`infra-validation-guide.md`	Cheatsheet de comandos CLI exactos por servicio: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Kafka, RabbitMQ, Redis, Keycloak, MinIO y reinicio/health de la app Spring Boot; patrones del contenedor `devtools`

Flujo de verificación (Paso 0b)

Detecta el runtime disponible (podman → podman compose; si no, docker → docker compose).
Ejecuta ./validate-infra.sh. Si todos los checks son [PASS] → status: ready.
Si algún check [FAIL]: el servicio está caído → ${COMPOSE} up -d, espera ~30 s y reintenta.
Si el script falla de forma inesperada (variable no definida, command not found, endpoint incorrecto): el bug es del script, no de la infra → verifica cada servicio manualmente con los comandos de infra-validation-guide.md antes de levantar nada.
Si tras reintentar un servicio sigue caído → status: failed con el detalle en blockers[].

المزيد من هذا المستودع

نفس المستودع

flow-validation

asuridev/dsl-springboot-generator

Valida end-to-end TODOS los escenarios (A, B, C…) de los flujos `FL-{BC}-{N}` de `{bc}-flows.md` contra la aplicación corriendo y la infraestructura real (DB, cache, broker, storage): ejecuta la request de cada escenario y verifica el status y los side effects esperados (o su ausencia). Opera en dos modos: `validate` (secuencial: recorre los flujos uno a uno reseteando la DB antes de cada uno; ni compila ni edita) y `fix` (serial: el fix-loop completo hasta que el flujo pasa). La usa el especialista `flow-validator`. Úsala cuando necesites probar un flujo de un BC end-to-end, validar escenarios de error/borde, o confirmar que un UC está realmente "completado" (no solo compilando).

2026-07-020

logic-implementation

asuridev/dsl-springboot-generator

Punto de entrada de la Fase 3 del pipeline DSL: orquesta la implementación completa de un bounded context generado por la Fase 2 lanzando agentes especialistas en un DAG (Fase 1 en paralelo: `todo-implementer` completa los `// TODO: implement business logic` e `infra-provisioner` levanta la infraestructura; Fase 2: un `flow-validator` en modo `validate` recorre secuencialmente todos los flujos —reseteando la DB antes de cada uno— y, si hay rojos, una única pasada `fix` secuencial que un solo agente aplica sobre todos los flujos rojos, validando todos los escenarios de cada flujo; Fase 3 en paralelo: `java-quality-auditor` audita la calidad Java y `postman-builder` emite las colecciones Postman). Es el único interlocutor con el usuario. Esta skill debe usarse cuando el usuario diga "implementa el BC X", "completa los TODO del bounded context Y", "fase 3 para el BC Z", "implementa la lógica de negocio de X", o pida finalizar la Fase 3 de un scaffold generado.

2026-07-020

orchestration

asuridev/dsl-springboot-generator

Referencia compartida de la Fase 3 del pipeline DSL, consultada por la skill de orquestación `logic-implementation` (el punto de entrada del usuario) y por los agentes especialistas. Define el DAG multi-agente, los roles, el contrato de handoff entre orquestador y especialistas, la adaptación por harness y —para TODOS los agentes— las reglas inviolables y los criterios de "cuándo detenerse". No es el punto de entrada del usuario: esta skill debe consultarse cuando se necesite coordinar el DAG de la Fase 3, conocer qué recibe y devuelve cada especialista, o aplicar las reglas compartidas al implementar o validar un bounded context.

2026-07-020

handler-implementation

asuridev/dsl-springboot-generator

Soporte para completar los // TODO de lógica de negocio (handlers, aggregates y domain services) de un bounded context generado por la Fase 2. Reúne las guías de detalle del especialista `todo-implementer`: cómo leer los artefactos de diseño (`{bc}.yaml` / `{bc}-flows.md`), cuándo y cómo extraer domain services, cuándo usar concurrencia con hilos virtuales y cómo integrar el almacenamiento de objetos. Úsala al implementar la lógica de negocio de un BC, completar handlers con `UnsupportedOperationException`, o decidir si un caso requiere domain service / hilos virtuales / storage.

2026-07-010

postman-authoring

asuridev/dsl-springboot-generator

Genera las colecciones Postman de un bounded context ya validado: `postman/{bc}-collection.json` (una carpeta por flujo `FL-{BC}-{N}`, una request por escenario A/B/C…, más una carpeta CRUD con los endpoints triviales del OpenAPI) y `postman/auth-collection.json` (compartido entre BCs, una request de token por rol — solo se crea si no existe). La usa el especialista `postman-builder`. Úsala cuando necesites emitir/regenerar colecciones Postman reutilizables para revalidar los flujos de un BC manualmente.

2026-07-010

java-quality-audit

asuridev/dsl-springboot-generator

Audita y ajusta la calidad del código Java de un bounded context ya implementado y validado: imports faltantes o sin usar, inyección de dependencias por constructor, campos `final`, tipado de excepciones de dominio, uso correcto de `@Transactional`, convenciones de `AGENTS.md` (sin Lombok ni setters en dominio). Aplica **solo cambios no-conductuales** que preserven el comportamiento ya validado por `flow-validator`, y define la frontera "no-conductual vs conductual". La usa el especialista `java-quality-auditor`. Úsala al pulir/limpiar el código Java de un BC sin cambiar su comportamiento.

2026-06-290

name

infra-provisioning

description

Antes de empezar, lee las reglas inviolables y "cuándo detenerse" en la skill compartida .agents/skills/orchestration/SKILL.md.

Provisión y verificación de infraestructura

status: ready exige que todos los servicios declarados en el compose estén up/healthy y que sus CLI tools respondan.

Guía de referencia

Guía (`references/`)	Contenido
`infra-validation-guide.md`	Cheatsheet de comandos CLI exactos por servicio: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Kafka, RabbitMQ, Redis, Keycloak, MinIO y reinicio/health de la app Spring Boot; patrones del contenedor `devtools`

Flujo de verificación (Paso 0b)

Detecta el runtime disponible (podman → podman compose; si no, docker → docker compose).
Ejecuta ./validate-infra.sh. Si todos los checks son [PASS] → status: ready.
Si algún check [FAIL]: el servicio está caído → ${COMPOSE} up -d, espera ~30 s y reintenta.
Si el script falla de forma inesperada (variable no definida, command not found, endpoint incorrecto): el bug es del script, no de la infra → verifica cada servicio manualmente con los comandos de infra-validation-guide.md antes de levantar nada.
Si tras reintentar un servicio sigue caído → status: failed con el detalle en blockers[].