juanca202

@juanca202 source repo

17 skills
0 followers
6 hours ago last updated

▌
Test Define · juanca202 bundle
Crear casos de prueba (TC-XXX) a partir de los criterios de aceptación de cualquier artefacto de especificación que los tenga con identificador codificado: una historia de usuario (US-XXX), un work item (WI-XXX), un feature ya implementado (FT-XXX) o cualquier otro documento de especificación cuyos criterios estén numerados o codificados (AC-001, 1.1, R-3, etc.), siguiendo el estándar IEEE 29119-4. Activar cuando el usuario pida "definir test cases", "crear casos de prueba", "generar TCs", "pruebas para la US/WI/FT", "pruebas para este spec/documento", "documentar pruebas", "casos de prueba para los criterios de aceptación", o cualquier variante que implique producir documentación de prueba a partir de requisitos ya especificados. También activar cuando el usuario mencione "test-define" o "/test-define". Si el artefacto está archivado en docs/archive/, se detiene: es trabajo cerrado y hay que desarchivarlo antes.

0
installs
▌
Work Define · juanca202 bundle
Crear o actualizar Historias de Usuario (US-XXX). Activar cuando el usuario pida una historia de usuario nueva, describa una funcionalidad o necesidad de negocio concreta que deba documentarse como historia, quiera crear varias historias relacionadas a la vez, o pida actualizar, estandarizar o alinear historias existentes a las convenciones del proyecto. Activar también para descomponer en historias un SRS-XXX terminado por /requirement-refine («arma las historias del SRS-003»): agrupa FR-XXX/NFR-XXX en historias y hereda repos, wireframes y criterios; la entrada por defecto sigue siendo la necesidad descrita directamente. NO activar para redactar, refinar o decidir el contenido de un SRS o de sus requisitos funcionales/no funcionales (eso corresponde a /requirement-refine), ni para registrar bugs, incidentes o work items de mantenimiento, ni para implementar o planificar tareas TK-XXX. El ID de una US archivada sigue ocupado; una US archivada no se actualiza sin desarchivarla.

0
installs
▌
Arch Discover · juanca202 bundle
Inspeccionar un proyecto existente para descubrir decisiones arquitectónicas implícitas y las reglas/convenciones vivas que están en vigor, y proponer los ADR y estándares candidatos que las documentarían. Usar cuando el usuario quiera auditar un repositorio en busca de decisiones o normas no documentadas, pida "descubrir ADRs", "descubrir estándares", "qué decisiones arquitectónicas tiene este proyecto", "qué convenciones sigue el código", "analiza la arquitectura del proyecto" o cualquier variante que implique explorar el código/estructura para inferir arquitectura relevante que merezca documentarse. Activar también cuando el usuario llegue a un proyecto nuevo y quiera entender qué decisiones y reglas ya existen, aunque no mencione explícitamente "ADR" o "estándar". Descubre una raíz de arquitectura por corrida —el repo principal o un submódulo—, y crea los artefactos aprobados en esa misma raíz.

0
installs
▌
Design Define · juanca202 bundle
Crear o actualizar documentación técnica (modelos de datos, APIs/endpoints, flujos/procesos, diagramas de clases/contexto/contenedores/componentes) en docs/specs/technical-docs/, organizada por capability, para que sirva como referencia de implementación de historias de usuario (US-XXX), tareas técnicas (TK-XXX) y tareas de mantenimiento (WI-XXX). Activar cuando el usuario pida documentar o especificar un modelo, entidad, DTO, contrato de API, endpoint, flujo, proceso técnico o un diagrama (clases, C4, arquitectura de la capability); cuando pida «más detalle» sobre un elemento técnico sin especificación mencionado en una US, TK o WI; o cuando otro skill (work-define, work-plan) delegue la creación de la especificación técnica. También activar con «/design-define», «documento técnico», «technical doc», «especificación técnica» o «diseño técnico», aunque el usuario no nombre la capability.

0
installs
▌
Quality Check · juanca202 bundle
Ejecutar las verificaciones automatizadas del stack —tipado, linter, unit tests, cobertura, build, e2e, análisis estático (Sonar) y las suites que declare el estándar de testing— y emitir un veredicto con informe y próximas acciones. Produce la caché test-run.json que consume trace-validate. No exige artefactos de este plugin: corre sobre cualquier repositorio y delega las correcciones en work-implement. Activar cuando el usuario pida correr las pruebas o las verificaciones: "ejecuta los checks", "corre los tests", "quality check", "valida antes del PR/merge", "¿está verde el repo?", o cuando lo invoque otro skill (work-integrate, pr-create, trace-validate). Proceso de cierre, no proactivo durante el desarrollo. Por defecto pide confirmación antes de corregir un fallo; `.sdd-devkit/settings.json` (`verification.qualityCheck.confirmFix: "never"`) permite corregir directo sin preguntar. La revisión cualitativa de diseño es de code-review.

0
installs
▌
Work Research · juanca202 bundle
Investigar y sintetizar hallazgos en un informe estructurado (RS-XXX). Skill genérico con seis flujos según la entrada: investigación libre de un tema; decisiones pendientes de un US-XXX/TK-XXX/WI-XXX antes de planificar; análisis de un issue o bug (reproducción, causa raíz y diagnóstico de pruebas, con entregable WI de tipo bug-fix); auditoría de un caso de prueba TC-XXX; análisis de legado (descubrir features FT-XXX y sus pruebas desde código existente); y discovery de migración entre proyectos. Activar cuando el usuario pida "investiga", "research", "¿es viable?", "¿cómo funciona X?", "¿qué impacto tiene?", "compara opciones", "¿qué falta por decidir?", "hay un bug", "falla en producción", "analiza el bug #1234", "revisa este caso de prueba", "analiza este código legacy", "ingeniería inversa de requisitos", "migración entre proyectos", o mencione "RS-XXX". Si hay un artefacto o un identificador del gestor de proyectos en contexto, usarlo sin preguntar.

0
installs
▌
Trace Validate · juanca202 bundle
Generar un reporte de trazabilidad que cruza los criterios de aceptación de un artefacto —una historia de usuario (US-XXX), una tarea de mantenimiento (WI-XXX), un feature ya implementado (FT-XXX) o cualquier documento cuyos criterios tengan identificador codificado (AC-001, 1.1, R-3…)— contra los casos y artefactos de prueba del repositorio. Por cada criterio indica qué lo cubre, su estado (`COVERED` / `PARTIAL` / `UNCOVERED`), si la prueba se ejecutó y con qué resultado, y cierra con un veredicto. No corre la suite: delega la ejecución en quality-check. Activar siempre que el usuario pida validar cobertura, generar una matriz o reporte de trazabilidad, verificar que los criterios de aceptación están probados, comprobar si un trabajo o un feature está cubierto por pruebas, o mencione "trazabilidad", "matriz de cobertura" o "validar criterios de aceptación", aunque no nombre el formato exacto. Traza también trabajo archivado en docs/archive/, dejando el reporte junto al artefacto.

0
installs
▌
Work Implement · juanca202 bundle
Implementar en código trabajo ya especificado, de cuatro tipos: (1) tareas técnicas (TK-XXX) bajo una historia de usuario; (2) tareas de mantenimiento (WI-XXX) sin historia — bugs, refactor, deuda técnica, dependencias, operativas; (3) casos de prueba (TC-XXX) — automatizar las pruebas ya documentadas por test-define; (4) features (FT-XXX) — automatizar los TC de sus criterios. Selecciona el tipo según el artefacto referenciado. Solo implementa trabajo en Estado: Ready; acepta además un modo corrección acotado, delegado por quality-check, sobre cualquier artefacto de la rama (US-XXX, WI-XXX, FT-XXX, TC-XXX en rama test/, o un artefacto externo al plugin), para arreglar un check o una prueba en rojo. Activar siempre que el usuario pida "implementar", "desarrollar", "ejecutar tareas", "codificar", "automatizar las pruebas", "implementa los test cases", "trabaja en el TK/WI/TC/FT" o variantes que impliquen escribir código desde una especificación ya redactada.

0
installs
▌
Work Integrate · juanca202 bundle
Cerrar e integrar el trabajo de una historia de usuario (US-XXX), una tarea de mantenimiento (WI-XXX) o una automatización de pruebas (rama test/ sobre un US-XXX, WI-XXX o FT-XXX) haciendo merge de la rama hacia la rama desde la que se creó, previa verificación de que progress.md tenga todas las unidades del trabajo en Done y de que pasen las puertas de calidad de cierre (quality-check, code-review y trace-validate). Cuando el trabajo es un US o WI en su rama funcional, pasadas las puertas resuelve el archivado según implementation.archiveMode (pregunta, archiva directo, o nunca) moviendo su carpeta bajo docs/archive/ antes del merge; si no se archiva, el merge sigue igual. En ramas test/ no archiva. Activar cuando el usuario pida cerrar, entregar, mergear, integrar, finalizar o hacer submit del trabajo de una historia, un WI, un feature o de la rama actual.

0
installs
▌
Requirement Refine · juanca202 bundle
Tomar un requerimiento en bruto (idea, ticket, correo, transcripción, diseño, wireframes) y estructurarlo como una Especificación de Requisitos de Software (SRS-XXX) siguiendo ISO/IEC/IEEE 29148: alcance, FR-XXX y NFR-XXX priorizados y verificables, interfaces externas, datos, cumplimiento normativo, riesgos, stack (investigar con /work-research o ya decidido), repositorios y proyecto base, equipo. Lee y entiende imágenes y diagramas adjuntos, como /work-define. Guarda el requerimiento original en references/; si tiene UI, genera wireframes SVG enlazados para revisión y usa las observaciones para cerrar el SRS. Cierra lagunas con preguntas estructuradas como /work-define o /work-plan. Activar con «refina este requerimiento», «crea un SRS», «especificación de requisitos», «/requirement-refine», o al describir una necesidad cruda antes de historias de usuario. No crea US ni AC-XXX (handoff a /work-define en Ready) ni documentación técnica de modelos/APIs (eso es /design-define).

0
installs
▌
Arch Init · juanca202 bundle
Identifica el punto de partida de un proyecto (sin código / con código base / con implementación) e inicializa lo que falte de su harness multi-agente: repo git —o, si la solución abarca varios repositorios, un repo de especificaciones que los agrega como submódulos—, placeholders `AGENTS.md`/`CLAUDE.md`/`.agents/MEMORY.md`/`.sdd-devkit/settings.json`/`docs/adr/README.md`/`docs/standards/README.md`/`README.md` (raíz, con descripción del proyecto), el stack tecnológico (investigando con `work-research` si hace falta), candidatos de ADR/estándares (vía `arch-discover` si ya hay implementación, por repositorio si es multi-repo) y la compuerta de calidad (vía `quality-check`). Cierra actualizando el stack y sugiriendo `work-define` o `work-plan`. Activar al pedir inicializar, bootstrapear o preparar uno o varios repos de una solución para agentes, configurar su harness, crear `AGENTS.md`/`CLAUDE.md`/`MEMORY.md` desde cero, o mencionar "arch-init", "/arch-init", "inicializa el harness".

0
installs
▌
Pr Create · juanca202
Crear Pull Request (PR) o Merge Request (MR) desde la rama actual hacia una rama destino preguntada al usuario, en dos modos: implementación (feature/fix/chore/refactor/test hacia su rama de integración) y promoción (develop hacia master/main/release, consolidando trabajos ya integrados). Puertas obligatorias y bloqueantes: en implementación, quality-check, code-review y trace-validate; en promoción solo quality-check. En ambos se verifica docs/policies/definition-of-done.md si existe. En implementación sobre un US/WI resuelve el archivado en docs/archive/ según implementation.archiveMode; si no se archiva, el PR se crea igual. Funciona sobre cualquier repositorio git con remoto: auto-detecta la plataforma (GitHub, GitLab, Bitbucket, Gitea, Azure Repos) y su CLI, y genera título y descripción. Usar siempre que el usuario pida crear, abrir o subir un PR, MR, pull request o merge request, o promover develop a master, incluso si solo dice "crea el PR" o "súbelo a develop".

0
installs
▌
Work Plan · juanca202 bundle
Planifica trabajo de distintos tipos sin generar código ni pruebas. Dos tipos de plan: (1) tareas técnicas (TK-XXX) bajo una historia de usuario existente; (2) tareas de mantenimiento (WI-XXX) sin historia asociada — bugs, refactor, deuda técnica, actualización de dependencias, tareas operativas. Activar cuando el usuario pida planificar implementación, descomponer trabajo, definir alcance técnico o planificar mantenimiento/deuda técnica/refactor, aunque no nombre «tarea», «TK» o «WI». Activar también, por defecto, cuando solo entregue una referencia a una historia («US-004», «planifica US-007»): proponer la descomposición en tareas por repositorio cubriendo los AC-XXX y preguntar si crear los planes completos, stubs, ajustar u otro, o cancelar. Selecciona el tipo según haya o no historia asociada y carga su definición desde references/. Cuenta el trabajo archivado en docs/archive/ al asignar IDs y detectar solapamientos; lo archivado no se edita.

0
installs
▌
Arch Audit · juanca202 bundle
Auditar el cumplimiento de los estándares de arquitectura (docs/standards/) y de las reglas de AGENTS.md contra el estado real del repositorio (Architecture Compliance Checking), citando el ADR de origen de cada estándar, y generar un informe priorizado en docs/audits/arch-audit-YYYY-MM-DD.md. Audita una raíz de arquitectura por corrida (repo principal o submódulo), con sus estándares, fitness functions e informe. Activar siempre que el usuario quiera verificar, auditar o comprobar si el código respeta los estándares, decisiones arquitectónicas o reglas del proyecto, aunque no diga "estándar", "ADR" o "auditoría". Frases: "audita el cumplimiento", "¿el código respeta los estándares/ADR?", "verifica que seguimos las reglas de AGENTS.md", "compliance de arquitectura", "arch-audit", "/arch-audit". Usar también ante sospecha de desvío de lo documentado, para un informe de brechas con acciones.

0
installs
▌
Git Commit · juanca202 bundle
Preparar y ejecutar git commit con mensajes Conventional Commits inferidos del diff (tipo, scope, descripción, staging). El push es opcional y lo gobierna `.sdd-devkit/settings.json` (`git.push`: ask/always/never; nunca por defecto), y solo aplica en invocación directa del usuario, no cuando lo invocan otros skills. No mergea, no toca la configuración global de git ni aplica operaciones destructivas. Activar cuando el usuario pida hacer commit, generar el mensaje, separar cambios en varios commits, o use invocaciones tipo `/commit`; también lo invocan automáticamente work-integrate y pr-create ante un working tree sucio.

0
installs
▌
Arch Manage · juanca202 bundle
Crear o actualizar la arquitectura documentada del proyecto: Architecture Decision Records (ADR, en docs/adr/) y estándares de arquitectura por dominio (en docs/standards/), en la raíz del repositorio al que pertenece el código (repo principal o submódulo). Un ADR registra el "por qué" de una decisión (histórico, inmutable); un estándar agrupa los requisitos verificables de un dominio — el "qué hay que cumplir hoy". Cada decisión que fija una regla actualiza el estándar de su dominio, no crea uno nuevo. Activar para documentar, registrar o cambiar el estado de una decisión arquitectónica o norma del proyecto, aunque no use las palabras "ADR" o "estándar". Frases: "registrar decisión", "documentar por qué usamos X", "decision record", "cambiar ADR a Accepted", "marcar como Superseded", "crear/actualizar ADR", "ADR-XXX", "definir un estándar", "añadir un requisito". Usar también ante una tensión arquitectónica que deba quedar documentada.

0
installs
▌
Code Review · juanca202 bundle
Revisión cualitativa de código, estilo ingeniero senior, sobre el diff de una rama contra su base (incluye lo no commiteado): intención, arquitectura y diseño (SOLID, Clean Architecture, ISO/IEC 25010: acoplamiento, fiabilidad, seguridad, desempeño) y feedback accionable que explica el porqué y propone cambios. Devuelve hallazgos con severidad, veredicto y próximas acciones. No exige artefactos de este plugin: la intención puede venir de una US-XXX/WI-XXX/FT-XXX, un ticket o spec externo, o la rama y sus commits. Activar cuando el usuario pida "revisa este código", "code review", "¿está bien resuelto esto?", "revisa el diseño antes del PR/merge", o cuando lo invoque otro skill (work-integrate, pr-create). Proceso de cierre, no proactivo. NO ejecuta pruebas, linter ni build — eso es de quality-check. Por defecto pide confirmación antes de corregir un hallazgo bloqueante; `.sdd-devkit/settings.json` (`verification.codeReview.confirmFix: "never"`) permite corregir directo sin preguntar.

0
installs

17 published skills