Communitygithub.com

caseycme/skills

Orquesta el ciclo de vida completo de una funcionalidad: Refinar → Sistema de diseño → Arquitectura → Construir → Verificar preparación para producción. Úsalo al iniciar una historia, implementar una funcionalidad de principio a fin, o cerrar el trabajo antes de un PR. El skill padre coordina los skills hijos — no duplica sus reglas.

¿Qué es skills?

Este skill orquesta el ciclo de vida completo de una funcionalidad, coordinando skills hijos especializados en cada fase: refinamiento, sistema de diseño, arquitectura, construcción y verificación de preparación para producción. Está diseñado para ser usado con historias de usuario o tickets, pasando contexto entre fases y evitando duplicar trabajo. Soporta flujos como planificación de nuevas historias (fases 1-3), implementación (fase 4), cierre/pre-PR (fase 5) o ciclo completo. Hace referencia a skills específicos en rutas como `refine/SKILL.md`, `design-system/SKILL.md`, etc. y genera un plan combinado tras las fases 1-3. Es independiente de plataforma (funciona con Claude Code, Cursor, Codex, etc.) y debe usarse cuando se necesita un proceso estructurado y estandarizado para desarrollar funcionalidades.

Compatible con✓Claude Code~Codex CLI~Cursor
Part ofDesign & UI
npx skills add https://github.com/caseycme/skills/tree/HEAD/skills/feature-development
Ver original→Ver todas las habilidades

Preguntar en tu IA favorita

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

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentación

Desarrollo de funcionalidades

Planifica usando los estándares → construye usando los estándares → verifica contra los estándares.

Este skill solo orquesta. Cada fase delega en un skill hijo. No reafirmes los flujos de trabajo de los hijos aquí.

FaseSkillRutaModo (skill hijo)
1refinerefine/SKILL.md—
2design-systemdesign-system/SKILL.mdPLAN
3architecturearchitecture/SKILL.mdPLAN
4buildbuild/SKILL.mdBUILD
5verifyverify/SKILL.mdpuerta de producción

Usa feasibility antes de la fase 1 cuando el equipo necesite un veredicto listo/no listo para decidir si empezar.

Flujo de trabajo

Progreso de planificación:
- [ ] 1. Refinar
- [ ] Decisiones resueltas (si las hay)
- [ ] 2. Sistema de diseño (PLAN)
- [ ] 3. Arquitectura (PLAN)
- [ ] Plan de desarrollo de la funcionalidad emitido
- [ ] 4. Construir
- [ ] 5. Verificar preparación para producción
- [ ] Listo para PR

1. Refinar

Invoca: refine/SKILL.md

Pasa: clave del ticket o pegado, enlaces a Figma/diseño, épica padre, contexto de chat.

Salida: qué/cómo lo suficientemente claro para estimar; decisiones abiertas nombradas o resueltas; resumen de refinamiento consolidado cuando las decisiones estén tomadas.

Puerta: detente para Preguntas que requieren una decisión antes de la fase 2.

2. Sistema de diseño

Invoca: design-system/SKILL.md en modo PLAN.

Pasa: resumen de refinamiento, Figma/capturas de pantalla, rutas/superficies involucradas.

Salida: recomendaciones de reutilización, posibles cambios en PL, secuenciación (PR de PL si corresponde). O "No aplica (sin UI)" en una línea.

3. Arquitectura

Invoca: architecture/SKILL.md en modo PLAN.

Pasa: resumen de refinamiento, plan del sistema de diseño (si lo hay), rutas/APIs/campos de sesión involucrados.

Salida: lista de verificación del tema aplicable con precedentes del repositorio.

Después de 1–3: emite el plan combinado una sola vez.

4. Construir

Invoca: build/SKILL.md.

Pasa: resumen de refinamiento, salida del PLAN del sistema de diseño, lista de verificación del PLAN de arquitectura.

Salida: implementación en la rama siguiendo esos estándares.

5. Verificar preparación para producción

Invoca: verify/SKILL.md — puerta única previa al PR. No ejecutes la REVISIÓN del sistema de diseño o arquitectura por separado; verify las gestiona.

Pasa: resumen de refinamiento / criterios de aceptación, salida del PLAN del sistema de diseño, lista de verificación del PLAN de arquitectura, diff de la rama.

Salida: APROBADO | PARCIAL | FALLIDO, preparación para PR, y lo que se verificó/corrigió.

Reglas de orquestación

  • Los skills hijos son dueños de su comportamiento. Lee y sigue el skill enlazado para cada fase.
  • Pasa el contexto hacia adelante — cada fase consume las salidas anteriores.
  • Un único artefacto de planificación después de las fases 1–3; no publiques tres informes completos.
  • Verify requiere código — omite las fases 4–5 durante invocaciones solo de planificación, a menos que ya exista implementación.
  • Pre-PR es solo la fase 5 — sin "reejecutar arquitectura antes del PR" por separado.

Cuando se invoca

IntenciónEjecutar
Planificar una nueva historiaFases 1–3 → plan combinado
Implementar funcionalidadFase 4 (después de 1–3, o con resumen existente)
Cerrar / pre-PRFase 5
Ciclo de vida completo1 → 2 → 3 → plan → 4 → 5

Plan combinado (después de las fases 1–3)

Sintetiza las salidas de los hijos. No reimprimas los informes completos de los hijos.

# Plan de desarrollo de la funcionalidad: [ticket o título]

## Resumen

[3–5 oraciones del refine + bloqueadores + preparación para estimar]

## Refinamiento

[Hallazgos delta, borrador de criterios de aceptación, seguimientos — de la salida del skill refine]

## Sistema de diseño (PLAN)

[De la salida del modo PLAN del skill design-system — o "No aplica"]

## Arquitectura (PLAN)

[De la lista de verificación del modo PLAN del skill architecture]

## Decisiones abiertas

[Vacío si refine completó]

## Siguiente

→ Fase 4 Construir, luego fase 5 Verificar

Después de verificar (fase 5)

Anexa o devuelve la salida del skill verify (consulta verify/SKILL.md). El padre no define secciones de verify — el hijo es dueño del informe.

Skills hijos

Individual skills in this repo

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

caseycme/skills

Guides systematic refactoring to align features with established patterns, remove duplication, and improve code reuse. Includes DataGrid/pattern-library, typing, fetch pagination, view-model vs override-prop guidance, and MUI sx-first layout (avoid deprecated Box style shorthand props). Use when refactoring features, consolidating duplicate code, extracting shared utilities, or aligning patterns across similar features.

caseycme/skills

>- Design-system guidance in three modes: PLAN (prospective reuse and abstractions before build), BUILD (apply those standards while implementing), REVIEW (audit branch diff against them). Use in feature-development phases 2, 4, and 5; or standalone for inline styles, sx, custom CSS, one-off cards, or pattern-library scope. Formerly pattern-library-refactor.

Skills relacionados

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community