Skip to content

svallejo-dev/ingenieria

v0.4.0MIT

Flujo de ingeniería en español y agnóstico al lenguaje: glosario y ADRs, specs y tickets locales, TDD, diagnóstico de bugs, diseño de módulos profundos, code review, commits y PRs. Delega lo específico de cada lenguaje en plugins de lenguaje (go, ...). Basado en mattpocock/skills (MIT).

code-review

Revisa cambios de código en cualquier lenguaje, sea un diff local desde un punto fijo (commit, rama, tag) o un pull request de GitHub (número, URL o rama), con revisores en paralelo (Transversal, uno por lenguaje vía los plugins de lenguaje, y Spec) y hallazgos con severidad. Publica en GitHub solo si se pide y nunca aprueba. Triggers: "code review", "revisa desde main", "revisa esta rama", "revisa este PR", "review PR #123", "revisión de PR".

codebase-design

Vocabulario compartido, agnóstico al lenguaje, para diseñar módulos profundos. Úsala cuando el usuario quiera diseñar o mejorar la interfaz de un módulo, paquete o tipo, encontrar oportunidades de profundizar, decidir dónde va un seam, hacer el código más testeable o navegable por agentes, o cuando otra skill necesite este vocabulario.

create-pr

Redacta o abre un pull request de GitHub para la rama actual, siguiendo la plantilla, el estilo de título y el idioma del repo; si no hay, usa un título Conventional Commits y una plantilla con resumen visual, evidencia antes/después y riesgo de merge. Solo redactar, sin push: \"write a PR description\", \"redacta la descripción del PR\", \"draft the PR\". Hace push y gh pr create solo cuando se pide abrirlo: \"open a PR\", \"abre un PR\", \"haz un PR\", \"sube esto a review\". Commitea solo los archivos de la tarea, maneja forks y nunca mergea. Sin shell o sin gh, redacta el texto y los comandos.

diagnosing-bugs

Ciclo de diagnóstico para bugs difíciles y regresiones de rendimiento, en cualquier lenguaje. Úsala cuando el usuario diga "diagnostica", "debug this", "depura" o reporte algo roto, que lanza error, falla, da resultados distintos o va lento.

domain-modeling

Construye y afina el modelo de dominio de un proyecto. Úsala cuando se discuta la terminología del código o del negocio, al escribir o editar un GLOSARIO.md, o al registrar o editar un ADR.

git-commit

Write commit messages and create atomic git commits that follow the repo's own conventions (commitlint, CONTRIBUTING, git log style), falling back to Conventional Commits. Drafting only, nothing executed: \"write a commit message\", \"suggest a commit message\", \"redacta el mensaje de commit\", or a pasted diff. Runs git commit only when asked to commit: \"commit this\", \"haz commit\", \"commitea\", \"split into atomic commits\". Stages only the current task's files, leaves other changes alone, never pushes unless asked. Without a shell it drafts the text plus the commands.\n

grill-with-docs

Interrogatorio sin tregua para afinar un plan o diseño que, sobre la marcha, escribe el glosario del dominio y los ADRs. Úsala solo cuando el usuario la pida explícitamente.

ingenieria-setup

Configura este repo para las skills de ingeniería: dónde viven las specs y tickets locales y dónde vive la documentación de dominio (glosario y ADRs). Ejecútala una vez por repo antes de usar to-spec, to-tickets o code-review. Úsala solo cuando el usuario la pida explícitamente.

tdd

Test-driven development en cualquier lenguaje. Úsala cuando el usuario quiera construir una feature o arreglar un bug test-first, mencione "TDD", "red-green-refactor" o "test primero", o pida tests de integración.

to-spec

Convierte la conversación actual en una spec (PRD) y la guarda en el tracker local, sin entrevista, solo sintetizando lo ya discutido. Úsala solo cuando el usuario la pida explícitamente.

to-tickets

Divide un plan, una spec o la conversación actual en tickets tracer-bullet (rebanadas verticales), cada uno con sus bloqueos declarados, y los guarda como un archivo por ticket en el tracker local. Úsala solo cuando el usuario la pida explícitamente.