| name | course-audit |
| version | 1.0.0 |
| description | Auditoría de curso contra framework completo. Use when user asks to "audit my course", "review my syllabus", "check course quality", "auditar curso", "revisar mi syllabus", "validar curso", "/course-audit".
|
Auditoría de Curso
Valida un curso existente contra: CONTEXT→CONCEPT→BUILD→SHIP→REFLECT presence,
Bloom's progression climb, Ship-First Design alignment, hiring test, standalone
test, cmi5 structure validity, tag taxonomy compliance.
Regla de idioma
Español. Términos técnicos en formato "español (English)".
Inputs
course-slug (required, desde $ARGUMENTS): nombre del directorio en
docs/instructional-design/courses/.
Si vacío: listar cursos disponibles, pedir al usuario elegir.
Flujo
Paso 1 — Load + Validate JSON
- Verificar que existe
docs/instructional-design/courses/{slug}/course.json.
- Validar contra schema:
ajv validate -s ${CLAUDE_PLUGIN_ROOT}/assets/schemas/course.schema.json -d {course.json} --spec=draft2020 -c ajv-formats
Si falla schema → ABORT (no auditar contenido si la estructura está rota).
- Cargar el JSON en memoria.
Paso 2 — Run framework checks
Ejecutar TODOS los checks abajo y agruparlos por severidad (PASS / WARN / FAIL).
Check 1 — Infrastructure presence
| Field | Criterio |
|---|
business_context | Presente y no vacío |
learner_profile | id, name, primary_pain todos presentes |
capstone | id, title, deliverable, ≥3 criteria, hiring_test todos presentes |
analysis.blooms_progression | Array con length == modules.length |
analysis.ship_milestones_escalation | Array con length == modules.length |
Per módulo: feedback_form | Presente con tool + form_id + embed_url |
Check 2 — CONTEXT→CONCEPT→BUILD→SHIP→REFLECT presence
Por cada lesson:
| Field | Criterio |
|---|
context | ≥100 chars, no arranca con "En la lección anterior" |
concept | ≥200 chars |
build | ≥200 chars Y representa 50-60% del total chars de la lesson |
ship | ≥30 chars |
reflect | ≥1 question, NO genérica (rechazar "¿qué aprendiste?", "¿cómo te fue?", "¿algún comentario?") |
Check 3 — Bloom's progression climb
Mapear levels a integers:
Recognize=1, Explain=2, Build=3, Debug=4, Decide=5, Ship=6.
- PASS: progresión monotónica creciente (con plateaus OK).
- WARN: 3+ módulos en mismo nivel, O regression de 1 nivel.
- FAIL: regression de 2+ niveles, O salto de 3+ niveles sin step intermedio.
Check 4 — Ship-First alignment
- Cada módulo tiene
ship_milestone no vacío.
- Ship milestones escalan: commit local → push → deploy staging → prod → capstone público.
- Capstone está alineado con assessment_criteria (ej. si capstone dice "publicada en stores" debe haber criterio sobre publicación).
Check 5 — Hiring test no genérico
capstone.hiring_test debe ser >50 chars.- NO aceptar respuestas tipo "Sí" sin justificación.
- Aceptar respuestas razonadas, incluso "No" si el creador justifica el rediseño pendiente.
Check 6 — Standalone test
Por cada lesson:
- ¿BUILD asume conocimiento que NO está en CONCEPT de la misma lesson?
- ¿BUILD referencia conceptos de lessons FUTURAS?
Heurística: si BUILD menciona términos no introducidos en CONCEPT y no hay link a
lesson previa que los haya introducido → WARN.
Caso extremo (BUILD vacío o trivial): FAIL — anti-pattern Hello-Worlder.
Check 7 — cmi5 structure
Despachar ${CLAUDE_PLUGIN_ROOT}/agents/cmi5-metadata-writer.md en mode
validate-only (no escribir):
- IDs (
id, au_id en todos los niveles) son únicos en su scope.
masteryScore ∈ [0, 1].moveOn ∈ enum válido.launchMethod ∈ enum válido.activityType is a valid URI.
Check 8 — Tag taxonomy compliance
Si existe tag-taxonomy.md en el repo (proyecto del usuario, no del plugin):
- Cross-reference que los tags usados en
meta.keywords (si existen) están en la
taxonomía.
- WARN si hay tags no listados.
Si no existe tag-taxonomy.md: skip este check (PASS).
Paso 2.5 — Aplicar overlays al audit (Base + Overlay protocol)
Antes de componer el report, leer
${CLAUDE_PLUGIN_ROOT}/assets/runtime/overlay-protocol.md y ejecutar el
procedimiento (Discovery §2 + Invocation §3 + Layer 1 validator §5,
específicamente §5.4 porque el baseDraft es findings-shaped, NO el
course.json) sobre el conjunto de findings producido en el Paso 2:
command = "course-audit"cwd = directorio de trabajo desde donde se invocó /idt:course-auditbaseDraft = objeto con forma { findings: [...], summary: {...} } que
resume los 8 checks de framework. Cada finding tiene al menos los campos
check, severity (pass/warn/fail), description, y opcionalmente
recommended_change (texto libre o JSON Pointer-shaped) que el overlay
puede usar para proponer fixes. Un overlay puede AGREGAR findings — p.ej.
un overlay content-standards desde dojo-academy puede inyectar findings
Dojo-específicos como "Módulo 2 carece de text-classes load-bearing,
contradice la regla 'text classes carry the course'".context.cwd y context.repo per la convención general.context.locale derivado de course.meta.language cuando esté presente.context._sourceArtifact = el course.json cargado en el Paso 1
(side-channel del runtime, no parte del contrato público de
OverlayInput.context — ver overlay-protocol.md §5.4).
Reglas (§5.4):
- El validator Layer 1 toma el snapshot contra
context._sourceArtifact
(el course.json), NO contra baseDraft. El snapshot queda fijo durante
todo el run — los overlays agregan findings, no tocan el source.
- Después de cada overlay, además del snapshot-compare estándar, el runtime
escanea cada
finding nuevo y mira sus campos recommended_change /
proposed_diff / equivalentes. Si el texto del finding referencia
cualquier path Layer 1 de §4 con intención de mutar (p.ej.
set meta.id = ..., replace modules[0].au_id, delete capstone.id):
ABORT con error apuntando al SKILL.md del overlay AND al índice del
finding ofensor en el array findings[].
- Findings que proponen cambios sobre campos mutables (titles, slugs,
description text,
analysis.identified_risks, copy de lessons): OK — solo
los path L1 disparan el abort.
- Los findings de overlays se mezclan con los findings base en el report
(Paso 3) bajo una sub-sección "Overlay findings" por overlay aplicado, con
el
SKILL.md path del overlay como header.
- Si discovery devuelve cero overlays: el report contiene solo los 8 checks
base (auditoría voice-neutral cmi5/xAPI). Ningún warning.
- Warnings de overlays se acumulan y se incluyen en la presentación final
(Paso 4) junto al "N fixes prioritarios identificados".
Paso 3 — Compose audit report
Generar docs/instructional-design/courses/{slug}/audits/audit-{YYYY-MM-DD}.md con
estructura:
# Course Audit: {course title}
**Date**: {date}
**Auditor**: instructional-design-toolkit:course-audit
**Course version**: {version}
## Summary
- Infrastructure: {pass/total}
- Lesson formula compliance: {pass/total} lessons
- Bloom's progression: PASS | WARN | FAIL
- Ship-First alignment: PASS | WARN | FAIL
- Hiring test: PASS | WARN | FAIL
- Standalone test: {pass/total} lessons
- cmi5 structure: PASS | WARN | FAIL
- Tag taxonomy: PASS | WARN | SKIPPED
## Detail (por check)
[tablas detalladas]
## Top 5 Fixes Priorizados (impact × ease)
1. **{Most impactful fix}** — file + what to change + estimated effort
2. ...
Paso 4 — Present + gate
"Auditoría completa. {N} fixes prioritarios identificados. ¿Querés que proponga
los cambios concretos?
- Sí, proponer fixes
- No, solo el report"
PUERTA: si el usuario dice sí, proceder a Paso 5. Si no, terminar.
Paso 5 — Propose fixes
Para cada fix priorizado, mostrar el diff propuesto al usuario. Aplicar solo con
confirmación explícita por fix. NO bulk-apply.
Recursos
${CLAUDE_PLUGIN_ROOT}/references/methodology.md${CLAUDE_PLUGIN_ROOT}/assets/skill-references/blooms-taxonomy.md${CLAUDE_PLUGIN_ROOT}/assets/skill-references/ship-first-design.md${CLAUDE_PLUGIN_ROOT}/agents/cmi5-metadata-writer.md${CLAUDE_PLUGIN_ROOT}/assets/schemas/course.schema.json${CLAUDE_PLUGIN_ROOT}/assets/schemas/overlay-protocol.schema.json — contrato OverlayInput/OverlayOutput para el Paso 2.5${CLAUDE_PLUGIN_ROOT}/assets/runtime/overlay-protocol.md — discovery + invocation + Layer 1 invariant validator
