Skill maestro para diseñar entregables académicos

---

name: aula-d3magindesign

description: Skill maestro para diseñar entregables académicos de Mario Quiroz (marca d3magindesign) — herramientas HTML interactivas, documentos Word/PPT/PDF y exámenes de admisión — para sus cursos en UTP e IDC. Activa este skill SIEMPRE que el usuario pida una herramienta semanal de clase, una actividad gamificada, una rúbrica evaluativa, un infográfico con hotspots, un ejercicio tipográfico, un constructor de briefs, una guía de InDesign, una variante de examen de admisión, una calculadora de retícula editorial, una infografía interactiva, una clase en diapositivas, o cualquier artefacto pedagógico para los cursos Semiótica de la Imagen, Fundamentos del Diseño Tipográfico, Diseño de Información, Diagramación Editorial, Proyecto Ilustrador, o cualquier curso de diseño/comunicación. Activa también cuando el usuario diga frases informales como "una actividad para la clase", "algo para los chicos del curso", "una herramienta para esta semana", "un material para mis estudiantes" — aunque no nombre el formato. El skill define el sistema de diseño correcto (UTP o IDC), la alineación pedagógica obligatoria al modelo MPI-DUAE (DUA 3.0 + Kolb + Amabile), las convenciones de código y los patrones recurrentes que mantienen consistencia entre todos los entregables del docente.

---

# aula-d3magindesign · Skill maestro

Skill personal de Mario Rafael Quiroz Martínez (Mg.) para producir entregables académicos consistentes con su identidad **d3magindesign** y alineados a su marco doctoral **MPI-DUAE**. Este skill orquesta tres tipos de salida: **HTML interactivo**, **documentos** (DOCX/PPTX/PDF) y **exámenes de admisión**.

## 1 · Decisiones de orquestación

Antes de escribir una sola línea de código, Claude resuelve tres preguntas en orden:

### 1.1 ¿Qué tipo de entregable?

| Pista del pedido | Entregable | Skills auxiliares |

|---|---|---|

| "interactiva", "para que los estudiantes hagan clic", "gamificada", "PWA", "rúbrica que se llene", "hotspots" | **HTML self-contained** (un solo archivo) | — |

| "rúbrica imprimible", "brief", "guía de actividad", "syllabus" | **DOCX** | `docx` |

| "clase", "diapositivas", "presentación de la sesión" | **PPTX** | `pptx` |

| "examen de admisión", "evaluación", "documento institucional final" | **PDF** o **DOCX** según destino | `pdf`, `docx` |

| "calculadora", "anatomía tipográfica", "constructor de retícula" | **HTML self-contained** | — |

Cuando hay duda, **HTML interactivo es el default** porque es el formato dominante de Mario (la mayoría de salidas recientes han sido HTML).

### 1.2 ¿UTP o IDC?

| Indicador | Sistema |

|---|---|

| Curso UTP nombrado (Semiótica, Fund. Tipográfico, Dis. Información, Diagramación Editorial) | **UTP** |

| IDC, Proyecto Ilustrador, examen de admisión IDC, brief para estudiantes IDC | **IDC** |

| Sin contexto claro | Pregunta antes de empezar |

Lee `references/design-systems.md` para los tokens completos de cada sistema.

### 1.3 ¿Qué momento del ciclo Kolb activa?

Toda herramienta debe situarse en al menos **una** fase del ciclo experiencial:

- **CE — Concrete Experience** → caso, afiche, video disparador, observación

- **OR — Reflective Observation** → diagnóstico, anotación, hotspots

- **CA — Abstract Conceptualization** → cuadros teóricos, marcos, taxonomías

- **AE — Active Experimentation** → propuesta propia, brief, transformación

Una herramienta **completa** recorre las cuatro; una herramienta **focalizada** marca explícitamente cuál fase activa. Lee `references/pedagogical-framework.md` para la alineación detallada.

## 2 · Reglas no-negociables

Estas reglas vienen de errores reales cometidos en proyectos anteriores. Son obligatorias.

### 2.1 HTML interactivo

1. **Single-file siempre.** Todo (HTML + CSS + JS + fonts CDN + imágenes embebidas si caben en base64) en un único `index.html`. Las imágenes pesadas viven en `./assets/`.

2. **Hotspots = hermanos, no hijos.** Los puntos interactivos (`button.hotspot`) deben ser **hermanos** del contenedor `overflow:hidden` que contiene la imagen, no hijos. El tooltip se posiciona con `getBoundingClientRect()` y vive en un `position: fixed` global.

3. **Service Worker solo en HTTPS.** El registro debe envolverse en `if ('serviceWorker' in navigator && (location.protocol === 'https:' || location.hostname === 'localhost'))` para no fallar silenciosamente en `file://` o intranets.

4. **Comillas dobles o template literals en JS.** Nunca comillas simples en strings que puedan contener apóstrofes en español ("¿Qué's tu opinión?" rompe el tokenizer). Verificar con `node --check`.

5. **Cada string es una `key` de localStorage independiente** y vive bajo un namespace por proyecto (`STORAGE_KEY = "modalidades-greimas-v1"`).

6. **`@media print` siempre presente** si el entregable tiene cualquier registro escrito. El docente y los estudiantes imprimen.

7. **Identificación SVG por color, no por línea.** Cuando se parsean archivos `.ai` o SVGs grandes, el matching por `fill="#..."` es más confiable que line-numbers.

### 2.2 DOCX / PPTX / PDF

1. **Diagramas embebidos = matplotlib + base64**, no enlaces externos.

2. **Tablas con bordes explícitos** (Word ignora estilos sin borde declarado al imprimir).

3. **Fuentes seguras**: Calibri/Arial para Word, Syne/DM Sans solo si están disponibles en el sistema destino. Para entregables institucionales (admisión IDC), **siempre Arial**.

4. **Cabecera y pie consistente** con la firma `d3magindesign · curso · semana / ciclo`.

### 2.3 Comunicación con estudiantes

- Email institucional de Mario: **`c12139@utp.edu.pe`** (también ruta de envío de estudiantes).

- Marca pública: **d3magindesign**.

- Botón "Enviar al docente" usa `mailto:` con CC al propio estudiante para que conserve copia.

## 3 · Convenciones de código (HTML interactivo)

### 3.1 Estructura del archivo

```

<!DOCTYPE html>

<head>

<style>

:root { /* tokens del sistema elegido */ }

/* secciones: typography, app shell, components, animations, print */

</style>

</head>

<body>

<main>

<div class="course-credit">Docente: <strong>Mg. Mario Quiroz</strong> · Curso: <strong>...</strong> · <strong>YYYY-N</strong> · Semana <strong>N</strong></div>

</main>

const STORAGE_KEY = "<proyecto>-v1";

const state = { /* ... */ };

/* funciones modulares: persist(), setPhase(), renderX(), bindX(), init() */

document.addEventListener("DOMContentLoaded", init);

if ('serviceWorker' in navigator && (location.protocol === 'https:' || location.hostname === 'localhost')) {

/* registro SW */

}

</script>

</body>

</html>

```

### 3.2 Patrones de estado

```javascript

const state = {

currentPhase: 0,

teams: [],

awarded: [],

retoAnswers: {},

retoSolved: {},

hotspot: { active: "X", score: 20, solved: {}, errors: 0 }

};

function persist() { localStorage.setItem(STORAGE_KEY, JSON.stringify(state)); }

function load() {

try { Object.assign(state, JSON.parse(localStorage.getItem(STORAGE_KEY) || "{}")); }

catch (e) { /* ignore */ }

}

```

### 3.3 Patrones de render

```javascript

const $ = (sel, ctx = document) => ctx.querySelector(sel);

const $$ = (sel, ctx = document) => Array.from(ctx.querySelectorAll(sel));

const escapeHtml = s => String(s).replace(/[&<>"']/g, c => ({"&":"&","<":"<",">":">",'"':""","'":"'"}[c]));

```

### 3.4 Verificación obligatoria

Después de generar el HTML, validar siempre:

```bash

# 1. Extraer JS del <script> principal y validar sintaxis

python3 -c "import re; print(re.search(r'<script>(.*?)</script>', open('index.html').read(), re.DOTALL).group(1))" > /tmp/extracted.js

node --check /tmp/extracted.js

# 2. Validar balance de etiquetas HTML

python3 -c "from html.parser import HTMLParser; ..."

```

Si falla la validación, corregir antes de entregar.

## 4 · Identidad y firma

### Footer obligatorio en HTML interactivo

```html

Docente: <strong>Mg. Mario Quiroz</strong>

Curso: <strong>[Nombre del curso]</strong>

<strong>[Año-Ciclo]</strong>

Semana <strong>[N]</strong>

</div>

```

### Footer obligatorio en DOCX/PPTX/PDF

Pie de página con: `d3magindesign · [curso] · [año-ciclo] · página X de Y`.

Para documentos institucionales IDC, sustituir `d3magindesign` por el logo institucional pero conservar el formato.

## 5 · Cuándo leer cada referencia

Lee la referencia **antes** de empezar a producir, no después.

| Si vas a... | Lee primero |

|---|---|

| Elegir colores, fuentes, sombras, gradientes | `references/design-systems.md` |

| Implementar hotspots, gamificación, fases, reveals, persistencia, PWA, print, mailto, CSV | `references/interaction-patterns.md` |

| Justificar pedagógicamente la actividad, alinear a Kolb/DUA/Amabile, escribir objetivos, redactar instrucciones para el docente | `references/pedagogical-framework.md` |

Si el pedido toca dos áreas (ej. "una rúbrica DUA con hotspots"), lee las dos referencias relevantes en paralelo antes de codificar.

## 6 · Defaults razonables

Cuando el usuario no especifica algo, asume:

- **Idioma**: español (es-PE).

- **Audiencia**: estudiantes universitarios (UTP) o de educación superior técnica (IDC).

- **Duración de la actividad**: 35 minutos para herramientas de aula; 90 minutos para sesiones completas.

- **Tamaño de equipo**: 3-4 estudiantes; permitir trabajo individual como opción.

- **Sistema de puntuación**: 0-20 base, descuentos de -0.5 por error, bonus +5/+8/+10/+15 por logros cualitativos.

- **Persistencia**: `localStorage` con clave única por proyecto.

- **Accesibilidad**: WCAG 2.1 AA mínimo; contraste verificado; `aria-label` en botones de íconos; teclado funcional.

- **Print**: incluir `@media print` con ocultamiento de controles y exposición de respuestas.

## 7 · Antipatrones a evitar

- **No** uses fuentes genéricas (Arial, Roboto, Inter) en HTML salvo que el destino sea Word/Word-equivalente.

- **No** generes diseños "morados sobre blanco" estilo IA. La paleta es navy/oro o naranja/azul institucional, según UTP o IDC.

- **No** uses `localStorage` sin namespace de proyecto (causa colisiones entre herramientas).

- **No** registres service workers en `file://` (rompe el desarrollo local).

- **No** asumas que las imágenes están disponibles offline; siempre incluye fallback en `.image-fallback`.

- **No** generes contenido pedagógico sin alineación explícita a una fase de Kolb (rompe la coherencia con el marco MPI-DUAE).

- **No** entregues HTML sin pasar `node --check` sobre el JS y sin verificar balance de etiquetas.

## 8 · Procedimiento estándar

Para cualquier nuevo entregable:

1. **Resolver las tres decisiones de §1** (tipo, sistema, fase Kolb).

2. **Leer las referencias relevantes** (§5).

3. **Si es HTML interactivo**: copiar el esqueleto de §3.1, instanciar tokens del sistema elegido, construir las fases.

4. **Si es DOCX/PPTX/PDF**: invocar el skill auxiliar correspondiente, aplicar paleta y firma.

5. **Validar** (sintaxis JS, balance HTML, accesibilidad, print).

6. **Firmar** con el footer obligatorio (§4).

7. **Entregar** con `present_files`, acompañado de un resumen breve (qué se construyó, qué fase Kolb activa, cómo se usa en clase).

---

*Skill mantenido por Mario Rafael Quiroz Martínez · d3magindesign · 2026.*

Buscar este blog

Diseño Gráfico

Skill maestro para diseñar entregables académicos

Comentarios

Publicar un comentario

Entradas populares de este blog

Diseños Institucionales con Adobe Illustrator: Uso de Data Merge y Scripts

Creación y Configuración de Áreas de Sangrado en Adobe Illustrator para Diseño de Etiquetas y Packaging

Gestión Avanzada de Colores en Adobe Illustrator para Impresión de Diseño de Empaques