Skill de revisión editorial para Claude Code

Revisada el 2026-10-12

Skill de Claude Code que revisa una wiki o colección de fichas como un equipo editorial: estructura, neutralidad, fuentes, duplicidades, propiedad intelectual y adecuación al público.

Se usa para auditorías completas o parciales de una enciclopedia, general o infantil. Distingue entre informar, corregir y publicar según el verbo del encargo, y no le conviene usar para una simple corrección ortográfica. El método explicado paso a paso está en Revisión editorial de una colección de fichas con IA.

Datos clave
Formato	Skill de Claude Code (SKILL.md)1
Idioma	Español
Instalación	Global: ~/.claude/skills/revision-editorial/SKILL.md. Solo un proyecto: .claude/skills/revision-editorial/SKILL.md1

Prompt

Copia el bloque completo en un archivo SKILL.md. La cabecera inicial (name y description) es la que usa Claude Code para decidir cuándo ofrecer la skill.¹

---
name: revision-editorial
description: Revisa y homogeneiza enciclopedias, wikis y colecciones de fichas para convertirlas en contenido profesional, neutral, verificable y respetuoso con la propiedad intelectual. Úsala para auditorías editoriales completas o parciales, tanto en una enciclopedia general como en una versión infantil. No la uses para una simple corrección ortográfica aislada.
---
 
# Revisión editorial
 
Revisa una wiki o colección de fichas como lo haría un equipo editorial: estructura, coherencia, neutralidad, nivel de detalle, fuentes, duplicidades, propiedad intelectual y adecuación al público.
 
La revisión puede aplicarse a:
 
- Una enciclopedia general sobre inteligencia artificial.
- Una versión infantil o educativa.
- Toda la colección.
- Un capítulo, categoría o conjunto de fichas.
- Una única ficha, cuando se solicite expresamente.
 
## Alcance de la intervención
 
Interpreta el verbo usado por el usuario:
 
- «Audita», «analiza» o «informa»: inspecciona y entrega hallazgos, sin modificar archivos.
- «Revisa», «corrige», «homogeneiza» o «aplica los cambios»: revisa y modifica los archivos necesarios.
- «Publica» o «despliega»: publica solo si se solicita expresamente y después de superar las verificaciones.
- Una petición de revisión no autoriza por sí sola a desplegar, borrar contenido, cambiar el dominio ni modificar la audiencia del sitio.
 
Antes de actuar, lee las instrucciones del repositorio y su línea editorial. Estas reglas prevalecen sobre los criterios generales de esta skill.
 
## Objetivo editorial
 
El resultado debe parecer una enciclopedia revisada por varios autores especializados:
 
- Comprensible sin conocimientos previos.
- Útil para adquirir nociones básicas y avanzar un poco más.
- Suficientemente detallada, pero sin convertirse en un manual exhaustivo.
- Neutral, impersonal y coherente.
- Basada en fuentes identificables.
- Sin experiencias privadas presentadas como conocimiento general.
- Sin procedimientos que faciliten infracciones, engaños o usos no autorizados.
- Sin repeticiones evitables entre fichas.
- Con una función editorial clara para cada artículo.
 
No reescribas por cambiar de estilo si el texto ya cumple estos objetivos.
 
## 1. Inventario inicial
 
Antes de editar:
 
1. Localiza todas las fichas, plantillas, índices, reglas editoriales y archivos que definan la estructura de lectura.
2. Identifica:
   - fichas activas;
   - borradores;
   - fichas retiradas;
   - anexos;
   - contenido público y privado;
   - páginas generadas automáticamente;
   - fichas con datos sujetos a caducidad.
3. Comprueba el estado de Git. Conserva los cambios ajenos o previos.
4. Detecta los comandos existentes para validar, probar, construir y publicar.
5. Haz una lista interna de los asuntos que aparecen en más de una ficha.
 
No edites índices o páginas generadas a mano si el proyecto dispone de un generador.
 
## 2. Revisión de cada ficha
 
Evalúa todas las fichas incluidas en el alcance, también los anexos y las retiradas cuando la petición abarque la colección completa.
 
### Función de la ficha
 
Cada ficha debe responder a una sola necesidad principal:
 
- definir un concepto;
- explicar un procedimiento;
- describir una herramienta;
- comparar alternativas;
- ofrecer una visión de conjunto;
- explicar un caso práctico;
- conservar una plantilla o prompt reutilizable.
 
Si una ficha mezcla varias funciones, separa lo esencial o enlaza la ficha especializada correspondiente.
 
### Comprensión
 
Comprueba que:
 
- La primera frase define el asunto.
- La entradilla permite entender por qué importa.
- Los términos técnicos se explican antes de usarlos.
- Una persona ajena al proyecto puede entender los ejemplos.
- Las secciones siguen un orden lógico.
- El texto evita relleno, grandilocuencia y conclusiones vagas.
- Los ejemplos aclaran el contenido y no introducen estructuras particulares innecesarias.
 
### Nivel de detalle
 
Conserva:
 
- definición;
- funcionamiento básico;
- utilidad;
- límites;
- un ejemplo práctico cuando aporte valor;
- enlaces a conceptos relacionados.
 
Resume o elimina:
 
- inventarios demasiado largos;
- variantes poco relevantes;
- instrucciones internas del proyecto;
- incidencias históricas sin valor general;
- cifras o configuraciones particulares que no ayuden al lector;
- explicaciones repetidas en otras fichas.
 
## 3. Neutralidad e impersonalidad
 
El cuerpo enciclopédico no debe depender de conocer al editor ni su entorno.
 
Retira o generaliza:
 
- nombres de personas del entorno privado;
- referencias a familiares, colegios o clientes;
- servidores domésticos o equipos concretos;
- rutas privadas y nombres de carpetas personales;
- reglas internas de otro proyecto;
- enlaces privados;
- notas en primera persona del editor sobre su forma de trabajar;
- valoraciones subjetivas presentadas como autoridad;
- tareas pendientes del editor;
- resultados de pruebas particulares presentados como reglas universales.
 
Una ruta estándar necesaria para explicar una herramienta puede conservarse. Una ruta particular debe sustituirse por un marcador claro, como `<carpeta-del-proyecto>`.
 
Los metadatos privados de trazabilidad pueden mantenerse si el proyecto los excluye de la publicación.
 
## 4. Propiedad intelectual y usos legítimos
 
Revisa con especial atención fichas sobre ebooks, PDF, libros, imágenes, vídeo, audio, voz, datasets, scraping, entrenamiento y transformación de documentos.
 
Una receta solo debe trabajar con:
 
- obras propias;
- materiales de dominio público;
- contenidos con licencia compatible;
- obras para las que exista autorización suficiente.
 
La posesión, compra o acceso a una obra no demuestra por sí solo que se pueda copiar, transformar, compartir o subir a un servicio.
 
No incluyas ni normalices:
 
- retirada o elusión de DRM;
- formas de saltarse controles de acceso, licencias o paywalls;
- fuentes orientadas a obtener copias no autorizadas;
- distribución de archivos protegidos;
- reconstrucción extensa de una obra mediante resúmenes sucesivos;
- prompts destinados a sustituir una obra protegida;
- clonación o imitación engañosa de la identidad, imagen o voz de terceros;
- instrucciones para ocultar la procedencia ilícita de un archivo.
 
Cuando un procedimiento pueda afectar a derechos de terceros:
 
1. Coloca la comprobación de derechos o autorización entre los requisitos.
2. Recuérdala antes de la primera copia, captura o carga.
3. Limita el procedimiento al material necesario.
4. Indica que cambiar nombre, formato o metadatos no modifica los derechos sobre la obra.
5. Distingue una copia de trabajo de una copia destinada a distribución.
6. Evita presentar excepciones legales como permisos universales.
7. Si hace falta una conclusión jurídica concreta, remite a la legislación y asesoramiento aplicables en vez de inventarla.
 
Las imágenes, voces y datos personales requieren además consentimiento y respeto a los derechos de imagen, voz y privacidad.
 
## 5. Fuentes y verificabilidad
 
Comprueba que las afirmaciones verificables tengan respaldo.
 
Prioriza:
 
1. Documentación y normas oficiales.
2. Artículos científicos y fuentes primarias.
3. Evaluadores técnicos reconocidos.
4. Fuentes secundarias de referencia.
5. Prensa especializada.
6. Creadores y comunidades, identificando su alcance.
 
Para precios, versiones, planes, funciones, legislación o información que pueda cambiar, verifica las fuentes actuales si el encargo requiere exactitud vigente.
 
No presentes como comprobado:
 
- contenido leído solo mediante un extracto;
- resultados de una prueba no reproducida;
- afirmaciones procedentes únicamente de una nota privada;
- conclusiones que la fuente no sostiene;
- opiniones de un creador como consenso general.
 
Cuando no pueda verificarse un dato:
 
- elimínalo si no es necesario;
- formula el alcance real;
- o márcalo como pendiente de fuente según la convención del proyecto.
 
No copies párrafos de las fuentes. Resume con palabras propias y usa citas literales solo cuando sean breves, necesarias y atribuidas.
 
## 6. Duplicidades y arquitectura de contenidos
 
Crea internamente un mapa de responsabilidades para los asuntos repetidos.
 
Como principio:
 
- Una ficha canónica contiene la explicación completa.
- Las demás ofrecen solo el contexto imprescindible y enlazan la ficha canónica.
- No mantengas listas cambiantes de modelos, precios o versiones en varias páginas.
- No repitas el mismo procedimiento en una receta y en la documentación de una automatización.
- No uses una ficha panorámica como copia resumida de todas las demás.
 
Ejemplo de reparto para una enciclopedia de IA:
 
- Comparador de modelos: versiones y resultados vigentes.
- Laboratorios: fabricantes, familias y formas de acceso.
- Historia: hitos y evolución.
- Benchmarks: cómo interpretar evaluaciones.
- Modelos abiertos: licencias, pesos y ejecución local.
- Asistentes: productos y experiencia de uso.
 
Cuando dos fichas sean realmente equivalentes:
 
1. Elige la más clara como canónica.
2. Integra en ella lo que falte.
3. Retira la duplicada con un aviso y un enlace.
4. No borres la ficha salvo que el usuario lo solicite o las reglas del proyecto lo establezcan.
5. Actualiza enlaces, aliases, índices y mapas.
 
## 7. Enciclopedia infantil
 
Cuando el destino sea una wiki infantil, aplica además estos criterios.
 
### Lenguaje
 
- Averigua la edad objetivo a partir del proyecto; si no consta, usa un nivel comprensible para alumnado de 8 a 12 años y deja constancia de la suposición.
- Usa frases cortas y vocabulario concreto.
- Explica una idea nueva cada vez.
- Define los términos técnicos con ejemplos cotidianos.
- No infantilices en exceso ni uses un tono condescendiente.
- Evita metáforas que creen una idea falsa de cómo funciona la IA.
- Distingue claramente «parece», «puede» y «siempre».
 
### Seguridad y autonomía
 
- No pidas a menores que compartan nombres completos, fotos, voz, ubicación, centro educativo, contraseñas o documentos personales.
- Las actividades con cuentas, compras, publicaciones, descargas o servicios externos deben requerir supervisión adulta cuando corresponda.
- No presentes la IA como una persona, autoridad, amiga infalible o sustituto de docentes y familiares.
- Enseña a contrastar respuestas y a pedir ayuda cuando algo resulte extraño, dañino o confuso.
- Evita ejemplos violentos, sexuales, discriminatorios o inquietantes que no sean necesarios para el tema.
- Los riesgos se explican sin alarmismo y con una acción concreta de protección.
 
### Relación con la enciclopedia general
 
La versión infantil puede simplificar la explicación, pero no debe contradecir la versión general.
 
- Reutiliza las mismas definiciones esenciales.
- Reduce detalle, no exactitud.
- No copies automáticamente párrafos de la versión adulta.
- Adapta ejemplos y vocabulario.
- Conserva una única fuente canónica para datos cambiantes cuando la arquitectura lo permita.
 
## 8. Ejecución de cambios
 
Cuando el usuario haya pedido aplicar la revisión:
 
1. Corrige primero los riesgos altos:
   - propiedad intelectual;
   - privacidad;
   - instrucciones inseguras;
   - afirmaciones falsas o sin respaldo;
   - contenido personal publicado.
2. Después resuelve:
   - duplicidades;
   - fichas internas impropias de una enciclopedia;
   - estructura;
   - tono;
   - longitud;
   - terminología.
3. Conserva slugs y URL públicas cuando sea posible.
4. Si cambia un título, mantén el anterior como alias cuando el sistema lo admita.
5. Actualiza las fechas conforme a las reglas del proyecto.
6. Regenera índices y salidas derivadas mediante sus scripts.
7. Documenta decisiones editoriales relevantes.
8. No cambies el estado de publicación ni despliegues salvo que el encargo lo autorice.
 
No conviertas una revisión editorial en un rediseño técnico del sitio.
 
## 9. Verificación final
 
Usa los validadores existentes del proyecto. Como mínimo, comprueba:
 
- metadatos y cabeceras;
- enlaces internos;
- referencias;
- aliases;
- fichas huérfanas;
- fechas y caducidad;
- datos sensibles;
- términos personales prohibidos;
- índice actualizado;
- pruebas automatizadas;
- construcción del sitio cuando el contenido vaya a publicarse;
- ausencia de fichas privadas o retiradas en la salida pública.
 
Haz además búsquedas específicas de:
 
- referencias a entornos privados;
- DRM, piratería y descargas no autorizadas;
- nombres de personas, centros o carpetas;
- primera persona del editor;
- bloques repetidos sobre modelos y versiones;
- procedimientos de voz, imagen o documentos sin consentimiento o autorización.
 
Acepta avisos únicamente cuando estén comprendidos, documentados y no afecten al contenido publicado.
 
## 10. Informe de cierre
 
Entrega un resumen que indique:
 
- número de fichas revisadas;
- fichas activas, borradores y retiradas;
- cambios editoriales principales;
- duplicidades resueltas;
- salvaguardas de propiedad intelectual añadidas;
- contenido privado generalizado o retirado;
- verificaciones ejecutadas;
- errores y avisos restantes;
- si el sitio fue construido;
- si el sitio fue desplegado;
- commit creado, si procede.
 
Si el proyecto mantiene informes o un registro de cambios, actualízalos siguiendo sus convenciones.
 
No afirmes que no existen errores en todo el contenido solo porque las comprobaciones mecánicas hayan pasado. Distingue entre validación estructural, revisión editorial y verificación factual de fuentes.

Cómo adaptarla

• Sustituye las referencias a «wiki» o «ficha» por el vocabulario de la colección si es otro (artículos, entradas, páginas).
• Las reglas propias del repositorio, como su línea editorial, prevalecen sobre los criterios generales de la skill; indícalo en las instrucciones del proyecto.
• Revisa la sección de propiedad intelectual con la legislación aplicable al caso: la skill no sustituye el asesoramiento jurídico.
• Ajusta los ejemplos de reparto de fichas al tema de la colección.

Referencias

Footnotes

1. Extend Claude with skills. Anthropic, documentación de Claude Code. Consultado el 2026-10-10. ↩ ↩² ↩³