Este repo defiende una regla antes que cualquier otra: plan antes de código. Cada skill produce un plano por escrito antes de escribir una sola línea: un PRD, un DESIGN.md, un mockup, un impl plan, un epic. Este hub es la versión legible de esos planos: cómo piensa cada skill, qué archivo espera de vos, y qué te devuelve.
Constitución, PRD, SRS: el porqué del producto.
DESIGN.md + mockups por historia.
Plan → código → review, historia por historia.
Deploy gateado, con rollback.
Doctrina transversal: cómo el agente principal orquesta subagentes y sesiones, cómo decide su registro de comunicación, dónde vive el backlog y dónde vive el mapa del negocio. Vale la pena leer esto antes que cualquier "cómo funciona" puntual.
Claude Code, OpenCode y Codex leen el mismo AGENTS.md y la misma tienda de skills: qué es canónico, qué se genera y cómo llegan las credenciales MCP a cada uno.
Abrir →Un AGENTS.md chico que siempre carga, una sección por tema que se lee a pedido, el router fijo y la línea ROUTE: que el hook inyecta.
Abrir →Butler Pattern, PM Voice, Visual Mapping y el reparto de capas: por qué el repo responde como responde, con la misma sesión en los dos estilos.
Abrir →Dos ejecutores (subagente y worker supervisado), el briefing que sigue briefing-template.md, conductor / worker / automatización y el launch.txt que funciona sin runtime.
Abrir →Jira es la fuente de verdad, el disco es un caché: los tres tiers, la escalera de .gitignore, context:hydrate y las defensas del workspace compartido.
Abrir →Por qué el mapa de datos, features y API vive en una skill, cómo se lee por sección con bun run context:map y cómo se corrige de a una sección, con evidencia y tu sí.
Abrir →Las skills en el orden en que un producto nuevo realmente las atraviesa: definir, diseñar, levantar el repo, armar el backlog y entregar historia por historia. Una app que ya existe entra por la adopción en lugar de levantar el repo.
Antes de la primera línea de código: Constitución, PRD, diseño, SRS con ADRs y Discovery.
Abrir →DESIGN.md una vez, mockup por historia, y el design gate que rutea entre los dos.
Abrir →Backend, frontend y piezas de integración desde el PRD, el SRS y el DESIGN.md, antes de la primera historia.
Abrir →Leer la app sin tocarla, un plan que esperás aprobar y la prueba de que compila, lintea y testea igual que antes.
Abrir →Cómo el backlog pasa de PRD a historias refinadas en Jira y a un orden de ejecución.
Abrir →Cómo la IA arma y refresca los mapas de negocio, el plan maestro y el roadmap, un modo por vez y con tu aprobación antes de pisar nada.
Abrir →Planning, Implementation, Code Review, Staging y Production con compuerta: plan en Jira, app viva, review adversarial, historia por historia.
Abrir →Red-green-refactor, nombres, mocks y cobertura, sola o desde la etapa de Implementation.
Abrir →La página /qa que enseña a testear la app, y las credenciales detrás de una puerta con permisos.
Abrir →Git, review, sesiones largas, corridas sin nadie mirando, Jira y deploy: lo que se usa todos los días una vez que el ciclo de vida principal ya está rodando.
Estrategia de ramas, compuerta de push por variable, paridad con el host, trailers forenses, PRs encadenados y worktrees.
Abrir →Rigor elegido antes de leer, hallazgos citados en Real / Pattern / Positive, y nada se postea sin tu OK.
Abrir →Cuando la ventana de contexto se llena: un archivo que deja a una sesión nueva seguir exactamente donde paró la anterior, en el mismo worktree y el mismo harness.
Abrir →Lo que una corrida hace, y nunca hace: lock, git como verdad, corrida vacía correcta, traspaso limpio.
Abrir →Dos operaciones de admin de Jira, selladas tras lectura previa y aprobación explícita.
Abrir →La skill se carga antes del binario: Jira por CLI sin romper campos, deploys verificados por SHA y credenciales MCP que no fallan en silencio.
Abrir →Para quien agrega un deck, corrige uno o mantiene el boilerplate. Todo vive en GitHub; nada de esto se publica como página.
Tokens "Planos", IIFEs compartidos, la regla de nombrar dueños y nunca conteos ni fechas, y el checklist antes de publicar.
GitHub ↗Qué deck enseña qué skill, cuáles se plegaron en otro y cuáles se descartaron, con el motivo.
GitHub ↗Qué se copia a _site/ (este hub, los decks y la página de inicio) y qué pushes a main lo disparan.
GitHub ↗REGISTRY.md, generado por bun run skills:registry: la lista real de skills y sus reglas compactas. Los decks nombran ese archivo en vez de copiar la lista.
GitHub ↗