check-third-party-docs
Esta skill debe usarse cuando el usuario pide \"investiga documentación de\", \"consulta documentación de\", \"quiero integrar X en\", \"cómo integrar\", \"implementar X en proyecto\", \"qué librería para\", \"instalar\", \"configurar\", \"error con\", o menciona agregar funcionalidad que requiere dependencias especializadas (validación con zod, procesamiento imágenes con sharp, colas con bull, caché con ioredis, formularios con react-hook-form). IMPORTANTE: Invocar esta skill en lugar de usar Context7 MCP directamente - la skill proporciona framework de decisión sobre cuándo usar Context7 vs dependency-docs-collector agent según complejidad. No usar para paquetes ampliamente conocidos como express, react, vue, lodash, axios, jest; Claude tiene datos de entrenamiento suficientes para estos. Usar solo para paquetes especializados, plugins de framework, o librerías poco conocidas.
create-pr
Esta skill debe usarse cuando el usuario pide "crea el PR", "prepara el PR", "escribe el PR", "genera el PR", "draft del PR", "documenta el PR", "crea la descripción del PR", o menciona crear pull request manualmente. Proporciona formato estructurado adaptado al tamaño de los cambios.
deep-reason
Esta skill debe usarse cuando el usuario pide \"pensemos esto a fondo\", \"analicemos paso a paso\", \"evaluemos opciones\", \"razonemos sobre esto\", \"pensemos detenidamente\", \"meditemos\", \"qué me sugieres\", \"qué me recomiendas\", \"esto es complejo\", \"esto es complicado\", \"problema grande\", o ante problemas que requieren análisis profundo, afectan múltiples componentes del sistema, tienen implicaciones arquitectónicas importantes, o representan decisiones de diseño con impacto significativo. IMPORTANTE: Invocar esta skill en lugar de usar seq-think MCP directamente - la skill proporciona workflow estructurado con generación de documentos de análisis.
document
Esta skill debe usarse cuando el usuario pide "documentar un patrón", "documentar un problema", "documentar una decisión", "documentar guías", "documentar la sesión", "documentar el conocimiento de la sesión", "document session knowledge", "capturar lo aprendido en la sesión", "crear documentación de", o quiere capturar conocimiento técnico de la sesión usando plantillas estructuradas.
dropletify
Esta skill debe usarse cuando el usuario pide "desplegar en DigitalOcean", "configurar droplet", "deploy a droplet", "CI/CD para DigitalOcean", "GitHub Actions para droplet", o quiere preparar un proyecto para despliegue con Docker en DigitalOcean.
typescript-advanced-types
Esta skill debe usarse cuando el usuario pide "planear biblioteca TypeScript", "crear módulo reutilizable", "refactorizar tipados", "refactorizar tipos de un módulo", o cuando estés en modo plan y el diseño requiera tipados fuertes de TypeScript, sistemas extensibles, o arquitecturas type-safe. Especialmente útil para planear sistemas de notificaciones, background jobs, cores de aplicación, o módulos pluggables que requieran tipos complejos. Proporciona guía completa para diseñar y construir módulos y bibliotecas type-safe con el sistema de tipos avanzado de TypeScript.
plan-feature
Esta skill debe usarse cuando el usuario pide "planear una feature", "plan a feature", "crear un plan de acción", "disenar una implementacion", "design an implementation", "crear un plan de desarrollo", "create a development plan", "quiero planear", "quiero hacer un plan", "quiero disenar", o cuando solicite un feature cuya complejidad lo requiera. Ejecuta workflow de 5 fases: discovery, exploracion del codebase, clarificacion, arquitectura, y escritura del plan. Al aprobar el plan, invoca smart-delegation automaticamente para ejecutar la implementacion.
post-implementation
Esta skill debe usarse cuando el usuario pide "haz review de los cambios", "review the changes", "aplica el post-implementacion", "apply post-implementation", "run post-implementation", o cuando el plan aprobado instruye "invoke /smart-plan:post-implementation". Ejecuta workflow post-implementacion despues de que el codigo este completo con quality review (3 reviewers paralelos), auto-fix de issues (confianza >= 80%), documentacion del feature, y commit opcional. Puede usarse despues de cualquier implementacion, no solo smart-plan.
smart-delegation
Esta skill debe usarse cuando Claude detecta que una implementacion es lo suficientemente grande como para dividirla en sub-agentes (5+ archivos, dependencias entre cambios, nuevas abstracciones que otros archivos consumen), cuando el usuario pide "delega la implementacion", "orquesta los implementadores", "usa sub-agentes", "delegate to sub-agents", "orchestrate implementers", o cuando plan-feature invoca la delegacion tras aprobar un plan.
smart-interview
Esta skill debe usarse cuando el usuario pregunta "¿Preguntas?", "¿Tienes dudas?", "¿Tienes preguntas?", "¿Quieres aclarar algo?", "¿Necesitas aclarar algo?", "aclara lo que necesites", o cuando quiere aterrizar requerimientos antes de planear. Tambien la invoca plan-feature en Phase 3. Ejecuta entrevista estructurada para obtener requerimientos cuantificables, reglas de negocio traducibles a codigo, y flujos del sistema; luego anota los resultados en el plan.
add-testing
Esta skill debe usarse cuando el usuario pide \"agregar tests a proyecto existente\", \"add testing to existing project\", \"setup de testing\", \"configurar infraestructura de tests\", \"pipeline completo de testing\", \"quiero tests para este modulo\", \"agregar cobertura de tests\", \"add test coverage\", \"integrar testing al proyecto\". Ejecuta pipeline completo de 7 pasos: auditoria de testabilidad, adaptacion condicional de codigo, investigacion de dependencias, implementacion de tests, auditoria de calidad de inputs, reporte de cobertura y generacion de reglas del proyecto.
tdd-workflow
Esta skill debe usarse cuando el usuario pide \"aplicar TDD\", \"desarrollo guiado por tests\", \"test-driven development\", \"red green refactor\", \"ciclo RGR\", \"escribir tests primero\", \"nueva feature con TDD\", \"mejorar testabilidad\", \"filosofia TDD\", o menciona Iron Laws, TDD philosophy, o quiere entender el proceso TDD. NO usar cuando el usuario pide agregar tests a un proyecto existente o setup de testing — eso es testing:add-testing.