Communitygithub.com

Luijaa/web-template

Diseña un nuevo sistema o una característica grande antes de escribir código — entrevista por rondas, escribe docs/design/<slug>.md a partir de la plantilla, ADRs y glosario, ejecuta make docs-check y abre un PR solo de documentación para su aprobación. Úsalo cuando te pidan diseñar algo, o cuando /new-feature encuentre que la característica es grande.

¿Qué es web-template?

Este skill para agentes de IA (como Claude Code, Cursor o Codex) guía el proceso de diseño técnico previo a la implementación. Cuando se solicita diseñar un sistema o una funcionalidad grande —o cuando el comando `/new-feature` detecta que la tarea es compleja— el agente orquesta un flujo estructurado: evalúa si realmente se necesita un diseño, crea un issue épico con la etiqueta `design`, genera una rama `docs/<id>-design-<slug>`, y sigue la plantilla `docs/design/template.md`. Luego realiza entrevistas iterativas con el usuario (en rondas con preguntas y recomendaciones), documenta cada decisión en el archivo de diseño, actualiza el glosario (`CONTEXT.md`), propone ADRs en `docs/adr/`, y actualiza diagramas C4 en `docs/architecture.md` si cambian contenedores o sistemas externos. Finalmente ejecuta `make docs-check` para validar la documentación y abre un Pull Request exclusivo de documentación (sin código, sin merge automático) para que el usuario lo apruebe. Está diseñado para integrarse con repositorios que usan `web-template` y es especialmente útil para equipos que siguen un proceso formal de diseño antes del desarrollo.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Luijaa/web-template/tree/HEAD/.agents/skills/design

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Diseño: $ARGUMENTS

Sigue todos los pasos de docs/design-process.md — ese archivo es la regla; este skill solo ordena el trabajo. Si hay conflicto, prioriza ese archivo.

  1. ¿Es necesario diseñar? — compara con la tabla del punto 1 de docs/design-process.md
    • No necesario: indica la razón en una línea y vuelve a new-feature
    • No estoy seguro: pregunta primero al usuario
  2. Inicio (punto 3.0): crea un issue épico (etiqueta design), una rama docs/<id>-design-<slug>, copia docs/design/template.md → docs/design/<slug>.md (system.md o <id-épico>-<slug>.md), establece status: draft y agrega una fila en docs/design/README.md
  3. Lee antes de preguntar: CONTEXT.md, docs/adr/, docs/architecture.md, otros diseños en docs/design/ — busca hechos que puedas encontrar por ti mismo, no preguntes
  4. Entrevista por rondas (punto 3.1) con el formato Qn — Tema: Pregunta + Sugerencia: … en cada punto, 1–2 casos límite por ronda — recorre las ramas A–H (punto 3.2) por completo y espera al usuario en los puntos de aprobación 1, 2 (system), 3
  5. Escribe en el archivo después de cada ronda: secciones en el archivo de diseño, términos nuevos en CONTEXT.md, ADR proposed en docs/adr/ (+ índice), diagramas C4 en docs/architecture.md si cambian contenedores o sistemas externos
  6. Revisa (punto 3.3): make docs-check debe pasar (en repos que aún no tengan este target en el Makefile: python3 <ruta-de-web-template>/scripts/check-docs.py <repo> — equipo Hermes: /home/opc/projects/web-template) + lista de verificación manual, luego establece status: proposed
  7. PR solo de documentación: docs(design): <slug>, cuerpo con Refs #<épico>, resumen de alternativas aún abiertas y sección ## CHANGELOG con - — sin código, sin merge
  8. Aprobación (punto 3.4): cuando el usuario apruebe, haz commit con status: approved + approved-by + cambia el ADR a accepted en el mismo PR (make docs-check debe pasar), luego deja que el usuario haga merge
  9. Después del merge (punto 3.5): abre issues secundarios según el punto 13, uno por uno, cada uno enlazando el épico y el archivo de diseño — el trabajo de código comienza con new-feature

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Skills relacionados