# Data Design

> Define el enfoque, las herramientas y el pipeline de análisis antes de escribir código, eligiendo entre SQL, Python o un enfoque híbrido según la pregunta y los datos.

- Skill: `leandrobenjaminl/data-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add leandrobenjaminl/data-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leandrobenjaminl/data-design/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics, DevOps & Infra, Data Analysis
- Tags: Duckdb, Excel, Pandas, Pipeline, Polars, Python, Sql, Sqlalchemy
- License: MIT
- Author: LeandroBenjaminL (https://skillmd.com/u/leandrobenjaminl)
- Updated: 2026-08-22
- Page: https://skillmd.com/skills/leandrobenjaminl/data-design

---


# Skill: data-design

Diseño de análisis. La pregunta está clara, ahora definí cómo responderla.

## Trigger

- Ya definiste la pregunta de negocio (con data-question)
- Tenés que elegir entre múltiples enfoques técnicos
- No sabés si esto es un trabajo de SQL, Python o Excel
- El proyecto creció y necesitás una arquitectura de análisis

## Workflow LEND

```
1. ANALIZAR
   ├── Pregunta: ¿descriptiva, diagnóstica, predictiva o prescriptiva?
   ├── Datos: ¿cuántos? ¿estructurados? ¿limpios? ¿dónde están?
   ├── Stack: ¿SQL directo, Python, R, o herramienta visual?
   └── Entrega: ¿dashboard, reporte PDF, API, modelo?

2. OFRECER (Menú del Senior)
   ├── A) SQL-first — si los datos están en DB y la pregunta es simple
   ├── B) Python pipeline — si necesitás transformaciones complejas o ML
   └── C) Híbrido — SQL para extracción + Python para análisis + visualización

3. ELEGIR → confirmación

4. HACER
   ├── Definir pipeline de análisis (extracción → limpieza → transformación → análisis → presentación)
   ├── Elegir herramientas: Pandas, Polars, DuckDB, SQLAlchemy
   ├── Estimar tiempo: ¿esto se resuelve en 30 minutos o necesita 2 semanas?
   ├── Identificar riesgos: datos incompletos, leakage, escala
   └── Documentar el diseño antes de implementar

5. VERIFICAR
   ├── El diseño responde la pregunta original sin desviarse
   ├── Las herramientas elegidas son las correctas para el volumen de datos
   └── Hay un plan B si el enfoque principal falla
```

## Patrones

- **Pregunta primero, diseño después**: no diseñes sin saber qué preguntás
- **Lo más simple que funciona**: SQL > Python > Spark. No uses un cañón para una mosca
- **Pipeline explícito**: cada etapa tiene input, transformación y output claros
- **Prototipar rápido**: un MVP de 30 lines vale más que una arquitectura de 2 días

## Anti-patrones

- ❌ Diseñar sin tener clara la pregunta — terminás resolviendo lo que no te pidieron
- ❌ Elegir herramienta por moda y no por necesidad — "usemos Spark" para 10MB de datos
- ❌ Arquitectura sobreingenierizada — pipelines de 10 etapas para una pregunta de 2 variables
- ❌ No considerar el tiempo — "esto es fácil" sin haber visto los datos