Beautiful Article
背景原则
El contenido generado por IA, cuanto más complejo, más importante es el medio de salida. El valor del HTML radica en aumentar simultáneamente la densidad de información, la claridad visual, la facilidad para compartir y la capacidad interactiva: tablas, SVG, CSS, fragmentos de código, controles ajustables, botones de copia y exportación permiten al lector no solo "terminar de leer", sino comparar, localizar, ajustar, revisar y seguir usando. El propósito de Beautiful Article es convertir materiales de texto aburridos, lineales y difíciles de digerir en artículos web de una sola página que ofrezcan una experiencia visual más atractiva, un ritmo de lectura más claro y sean más fáciles de revisar y compartir.
边界（先判断要不要进这个 Skill）
- El producto principal final es un artículo HTML único, no una aplicación web.
- El artículo puede tener una capa libre
Raw(cualquier HTML / CSS / JS / React: interacciones, maquetación, animaciones, pequeños widgets, diagramas SVG / canvas bajo demanda), pero debe servir a la lectura, explicación, argumentación, ritmo o estética. - No se genera: backend, formularios, tableros de arrastrar y soltar, dashboards completos, prototipos de productos, aplicaciones web genéricas.
- La densidad de información la confirma el usuario; por defecto se conserva el 100% de la información, generando un artículo web de texto largo.
Si el usuario quiere una aplicación y no un artículo, detente y acláralo; no entres en este Skill.
工作流总览
Fase 0 Intake Determinar si se entra en este Skill + tipo de artículo preliminar
▼
Fase 1 Source → Markdown URL/PDF/DOCX/MD/Texto → source.md + extraction-notes.md
└ El agente principal verifica internamente una lista de 5 puntos (solo fuentes complejas/de baja confianza pasan a SubAgent)
▼
Fase 2 Editorial Planning Un plan.md (cuatro secciones: Brief / Outline / Theme / Assets)
└ El agente principal verifica internamente (sin SubAgent, sin archivos de revisión)
▼
Fase 3 Plan Checkpoint ★Checkpoint 1 obligatorio. Confirmar 5 puntos uno por uno: tipo de artículo (con porcentaje de retención estándar) / tema / maquetación / modo de ilustraciones / portada
▼
Fase 4 First Spread Primera pantalla + primera sección + un bloque visual representativo (el andamio se crea aquí)
└ First Spread Reviewer SubAgent (escribe review/first-spread-review.md)
└ ★Checkpoint 2 obligatorio. Confirmar 2 puntos uno por uno: conclusión de la revisión / modo de desarrollo A/B
▼
Fase 5 Full Article Build Generar el artículo web completo (por defecto un solo agente; para textos muy largos, se puede aislar por secciones)
└ Section Reviewer SubAgent (devuelve pass/fail como mensaje, sin escribir archivos de revisión)
▼
Fase 6 Final Review Revisión final desde tres perspectivas: Editorial / Visual / Técnica (escribe review/final-review.md)
▼
Fase 7 Repair Reparación mínima por partes; solo se escribe repair-log.md si hay reparaciones
▼
Fase 8 Delivery ★Checkpoint 3 obligatorio. Confirmar la decisión de entrega → entregar article.html + breve nota editorial
Estructura del espacio de trabajo (el andamio se crea; estos archivos son la memoria a largo plazo del Skill, no confíes solo en el contexto del chat para recordar decisiones):
<workspace>/
source/ original.* source.md source.<lang>.md(cuando se necesita traducción) extraction-notes.md
plan/ plan.md # Archivo de planificación único: cuatro secciones: Brief / Outline / Theme / Assets
article/ Cover.tsx(por defecto) Article.tsx sections/ raw-blocks/ assets/ article.html(producto)
review/ first-spread-review.md final-review.md # Solo estos dos son productos habituales
source-review.md(solo para fuentes complejas) repair-log.md(solo si hay reparaciones)
index.html package.json vite.config.ts tsconfig*.json (herramientas de compilación)
硬性质检协议（贯穿整个 Skill）
El método de control de calidad se define por nodo: no todos los controles requieren abrir un SubAgent, ni todos requieren escribir un archivo. Abrir SubAgents o escribir archivos innecesariamente es el principal problema de rendimiento; sigue estrictamente la siguiente tabla:
| Nodo | Método de control de calidad | Producto | Por qué |
|---|---|---|---|
| Fase 1 Source (por defecto) | El agente principal verifica internamente una lista de 5 puntos | Sin archivo | El agente principal ya lee source.md de todos modos |
| Fase 1 Source (solo fuentes complejas/de baja confianza) | Source Reviewer SubAgent (comparando diff con original.*) | review/source-review.md | Las pérdidas silenciosas solo se detectan con diff |
| Fase 2 Plan / Antes de Checkpoint 1 | El agente principal verifica internamente (prohibido abrir SubAgent) | Sin archivo | Plan es una decisión textual de 200-400 líneas; el contexto está caliente; un SubAgent frío es más lento |
| Fase 4 First Spread / Antes de Checkpoint 2 | First Spread Reviewer SubAgent | review/first-spread-review.md | La primera pantalla marca el tono; un segundo par de ojos independiente es más seguro |
| Fase 5 Cada sección | Section Reviewer SubAgent | Devuelve pass/fail + puntos de reparación como mensaje (no escribe archivo) | Un artículo puede tener 5-15 secciones; N archivos de revisión nadie los vuelve a leer |
| Fase 6 Revisión final / Antes de Checkpoint 3 | Editorial + Visual + Technical Reviewer SubAgent | review/final-review.md | Parte del entregable; vale la pena archivar |
Reglas de hierro:
- El Plan Checkpoint (Fase 2 → Checkpoint 1) tiene prohibido abrir un SubAgent para control de calidad. Después de que el agente principal escriba
plan.md y **localmente** revise la lista de 5 puntos (ver la sección de autoevaluación de Plan enreferences/review-checklist.md), corrijaplan/plan.md` según las conclusiones, no escriba ningún archivo de revisión, y luego pase al Checkpoint 1. - First Spread / Final debe usar SubAgent (en estos nodos el valor del SubAgent supera el costo); solo si no se detecta un entorno de SubAgent, el agente principal asume la responsabilidad y anota "Sin entorno de SubAgent, el agente principal asume la responsabilidad" al principio del archivo.
- Section Reviewer usa SubAgent, pero el valor de retorno es un mensaje (pass / fail + puntos de reparación); los elementos fallidos los repara directamente el agente principal al recibirlos, no permita que el SubAgent escriba archivos
review/section-NN-review.md. - Al recibir cualquier conclusión de control de calidad, primero corrija el producto según los elementos fallidos, luego informe "hecho + conclusión de autoevaluación + qué se corrigió". Informar directamente la conclusión original sin corregir = infracción.
- Regla de hierro para la recopilación de decisiones · Prohibido elegir silenciosamente por el usuario: en cada Checkpoint (1 / 2 / 3), todos los elementos de decisión que requieren confirmación del usuario deben enumerarse de forma independiente + esperar la respuesta del usuario. El agente puede recomendar ("Recomiendo X porque..."), pero no puede decir "ya he decidido X por ti, si no es correcto, dímelo" — esto equivale a privar al usuario de la oportunidad de elegir.
- Prioritario: si el entorno tiene la herramienta
AskQuestion, cada elemento de decisión se pasa como una pregunta independiente (una sola llamada puede pasar múltiples preguntas); el usuario puede confirmar cada elemento con tarjetas de selección. - De lo contrario: detente y en el mensaje enumera todos los problemas con números (cada problema en un párrafo separado, escribe claramente el elemento recomendado + motivo + opciones alternativas), di explícitamente "Espero tu respuesta elemento por elemento antes de continuar", no sigas haciendo ningún trabajo posterior.
- Nunca: empaquetar múltiples decisiones en una sola pregunta de sí/no tipo "¿todo correcto con mi recomendación?" o "¿todo bien?"; tampoco seguir directamente al siguiente paso después de "una frase de recomendación" por defecto.
- Prioritario: si el entorno tiene la herramienta
Las listas de verificación y las plantillas de prompt de SubAgent para cada nodo están en references/review-checklist.md.
各阶段文件读取指南（渐进加载，别一次全读）
| Fase | Lectura obligatoria | Consulta bajo demanda |
|---|---|---|
| Fase 0 Intake | references/harness.md | —— |
| Fase 1 Source→MD | references/source-to-markdown.md | scripts/source-to-markdown-markitdown.py · scripts/source-to-markdown.py |
| Fase 2 Planning | references/article-types.md · references/information-density.md · references/plan-template.md · references/theme-selection.md · references/layout.md · references/asset-policy.md · references/cover.md (ideas de composición de portada) | references/article-types/<type>.md · theme-profiles/*.md |
| Fase 4 First Spread / Fase 5 Build (revisar cada sección) | references/section-build.md · references/component-policy.md · references/raw-policy.md · Tema seleccionado theme-profiles/<id>.md · Portada: references/cover.md | references/scaffold.md (una vez al crear el proyecto) · references/html-output.md |
| Fase 6/7 Review & Repair | references/review-checklist.md · references/repair-policy.md | —— |
| Fase 8 Delivery | references/html-output.md | references/pdf-output.md (solo si el usuario elige exportar PDF) |
En sesiones largas, el agente tiende a olvidar los principios — La Fase 5 repetirá la implementación de N secciones; antes de cada inicio, revisa
component-policy.md+raw-policy.md+ el tema actualtheme-profiles/<id>.md.
Fase 0 —— Intake
Determinar si se entra en este Skill, dar el tipo de artículo preliminar y el modo de salida (por defecto un solo HTML).
| Lo que da el usuario | Qué hacer |
|---|---|
| Uno o varios materiales (URL/PDF/DOCX/MD/texto/captura de pantalla) | Pasar a la Fase 1 |
| Solo dice "Ayúdame a hacer un artículo X" pero sin material | Preguntar de nuevo: pedir primero el material o un esquema. El Skill no inventa contenido para el usuario de la nada |
| Claramente quiere una aplicación / herramienta / dashboard | Detenerse y aclarar; no entrar en este Skill |
Capturar el idioma objetivo: desde el principio, registrar el idioma del artículo final deseado por el usuario (por ejemplo, si el usuario dice "en chino / hazlo en inglés", etc.).
- El usuario especifica un idioma → Anotarlo en la sección "Idioma objetivo" del Brief en
plan/plan.md. Si es diferente del idioma del material original, la Fase 1 debe producir primero una versión traducida natural y fiel del texto fuente, y luego escribir basándose en la versión traducida (ver Fase 1). - El usuario no especifica → Por defecto, el idioma del artículo final sigue el idioma del material original, sin traducir.
Autoevaluación: ¿El usuario quiere un artículo o una aplicación web? ¿Necesita información completa? ¿Hay que pedir más material primero? ¿El usuario ha especificado el idioma final? ¿Coincide con el idioma original?
Fase 1 —— Source → Markdown
Unificar cualquier entrada en source/source.md, y escribir las incertidumbres en source/extraction-notes.md.
Las reglas y el procesamiento de varios tipos de entrada están en references/source-to-markdown.md; se puede usar MarkItDown como ruta principal o scripts de fallback ligeros para extraer PDF/DOCX/HTML.
Después de guardar, el agente principal verifica internamente (lista de 5 puntos en references/source-to-markdown.md), corrige según las conclusiones y pasa a la Fase 2; solo si extraction-notes.md marca baja confianza / fuente compleja, se actualiza a un Source Reviewer SubAgent independiente que compara con original.* mediante diff (escribe review/source-review.md).
Manejo de idioma (inmediatamente después de la extracción): determinar el idioma de source.md.
- El usuario no especificó idioma objetivo, o el idioma objetivo coincide con el original → No traducir; escribir directamente basándose en
source.md; el idioma del artículo final = idioma original. - El usuario especificó un idioma objetivo diferente al original → Primero producir una versión traducida natural y fiel
source/source.<lang>.md(por ejemplo,source.zh.md/source.en.md), que servirá como base factual para las Fases 2+; el originalsource.mdse conserva para consulta. Requisitos de traducción: usar el idioma objetivo de forma natural, sin tono de traducción (reorganizar las frases según los hábitos de expresión del idioma objetivo, no traducir palabra por palabra, sin orden de palabras foráneo rígido / acumulación pasiva / puntuación extranjera), los términos / números / código / fórmulas / citas deben mantenerse precisos, la estructura y la proporción de información se mantienen sin cambios. Las notas de traducción se escriben enextraction-notes.md.
Fase 2 —— Editorial Planning
Formar el plan editorial, no escribir HTML directamente. Solo producir un plan/plan.md (cuatro secciones: Brief / Outline / Theme / Assets); la plantilla está en references/plan-template.md:
- Brief: Público objetivo / Tipo de artículo / Proporción de retención de información / Debe conservarse / Se puede eliminar / Tono / Puntos principales / Objetivo de lectura / Idioma objetivo / Ancho de maquetación / TOC / Estrategia de ilustraciones.
- Outline: Hero / Lead / Resumen / Lista de Secciones / Qué información conserva cada sección / Si cada sección necesita Raw·Table·CodeBlock·Formula·Image / Forma de finalización.
- Theme: Tema seleccionado + motivo + explicación de conflictos (ver
references/theme-selection.md). - Assets: Estrategia de ilustraciones y plan imagen por imagen (ver
references/asset-policy.md; en modonone, esta sección solo necesita una frase).
El enrutamiento de tipos de artículo está en references/article-types.md; la densidad de información y la proporción de componentes están en references/information-density.md.
Método de autoevaluación · Restricción fuerte: Después de escribir plan/plan.md, el agente principal internamente verifica la lista de 5 puntos de autoevaluación de Plan (ver la sección de autoevaluación de Plan en references/review-checklist.md), corrige plan/plan.md según las conclusiones, pasa directamente al Checkpoint 1, prohibido abrir SubAgent, prohibido escribir review/plan-review.md.
Fase 3 —— Plan Checkpoint（★Nodo duro · Checkpoint 1, obligatorio detenerse）
Regla de hierro: Prohibido elegir silenciosamente por el usuario. Cada elemento de decisión debe enumerarse de forma independiente y esperar la respuesta del usuario de forma independiente.
Puedes recomendar ("Recomiendo X, porque..."), no puedes decir "Ya he decidido X por ti, si no es correcto, dímelo" — esto último equivale a pasar por alto la opción por defecto y privar al usuario de la oportunidad de elegir.
Método de recopilación (elegir uno según el entorno):
- Prioritario: herramienta
AskQuestion: Cada elemento se pasa como una pregunta independiente (una sola llamada puede pasar múltiples preguntas); el usuario confirma cada elemento con tarjetas de selección. - Sin herramienta
AskQuestion: Detente y en el mensaje enumera cada problema con un número + en un párrafo separado + escribe claramente el elemento recomendado + motivo + opciones alternativas, di explícitamente "Espero tu respuesta elemento por elemento antes de continuar", no sigas haciendo ningún trabajo posterior.
Independientemente del método: cada decisión independiente corresponde a una pregunta independiente, no empaquetar como una pregunta de sí/no "¿todo correcto?".
Los 5 elementos que deben confirmarse de forma independiente (no puede faltar ninguno):
| # | Elemento de decisión | Opciones (etiqueta semántica · incluye porcentaje de retención de información estándar) | Notas |
|---|---|---|---|
| 1 | Tipo de artículo (el porcentaje de retención de información va incluido) | Texto largo completo / Archivo longform · ~100% ／ Informe de investigación / Análisis formal full-report · ~80% ／ Pasos didácticos / Guía de inicio tutorial · ~90% ／ Concepto / Explicación de sistema explainer · ~80% ／ Diálogo / Entrevista / Podcast dialogue · ~80% ／ PR / Propuesta / Revisión de incidentes review · ~70% ／ Opinión / Comentario / Narrativa essay · ~70% ／ Aprendizaje interactivo / Comprender un concepto interactive-explainer · ~25% extracto original + 75% reconstrucción IA ／ Resumen de decisiones / Para personas ocupadas briefing · ~50% ／ Principalmente imágenes y texto / Difusión y exhibición visual-essay · ~40% | La IA recomienda uno y escribe una frase de motivo. La proporción ya está vinculada a la opción de tipo, no se convierte en un tema separado (de lo contrario, aparecerían combinaciones falsas como longform + 20%). Si el usuario quiere desviarse del estándar, usa una frase de texto libre para anularlo ("Quiero longform + 60%"), ver "Cómo desviarse del estándar" a continuación |
| 2 | Tema | tufte / press / otros temas registrados (leer theme-profiles/index.json) | La IA recomienda uno y escribe una frase de motivo |
| 3 | Ancho de maquetación | narrow / regular / wide / full | La IA recomienda uno; por defecto regular |
| 4 | Modo de ilustraciones (obligatorio · no se permite "aprobar por defecto") | none / user-assets / placeholders / ai-generated | Una frase: "solo decide si usar Image externa; Raw no se ve afectado" |
| 5 | Portada (imagen de título tipo libro 3:4, ubicada sobre TOC + cuerpo) | Activada (por defecto) / Desactivada | La IA recomienda "Activada" y da una frase de idea de composición (qué tipo de imagen principal + qué plantilla de portada A/B/C/D/E elegir). briefing / dialogue puede recomendar "Desactivada". Ver references/cover.md para más detalles |
TOC activado por defecto: porque solo tiene un interruptor y casi todos los artículos deberían tenerlo; se puede mencionar de pasada en el mensaje de apertura del Plan Checkpoint con "TOC activado por defecto; dímelo si quieres desactivarlo", no es necesario convertirlo en un tema separado.
Elementos que ya tienen un valor por defecto y no es necesario preguntar por separado (aún así, se debe indicar explícitamente en el mensaje de apertura "Si quieres cambiar algo, dímelo", dando al usuario la oportunidad de cambiar de opinión, no se puede ocultar completamente):
- Idioma del artículo final: sigue el idioma original (a menos que el usuario ya lo haya especificado antes / ya se haya traducido).
- Si se permite editar, recortar, reorganizar, cambiar el tono: permitido por defecto (ejecutar según la proporción de retención de información anterior).
- Si se quiere ver primero un adelanto de la primera pantalla: por defecto se hará (es la Fase 4).
- TOC: activado por defecto.
Si el usuario dice "tú decide" para el tema → toma el primero que recomiendes, pero en las opciones sigue poniéndolo en paralelo con otros candidatos, marcado como "Por defecto · Recomendado por IA", dejando margen para cambiar de opinión, no se puede saltar la pregunta del tema directamente.
Cómo desviarse de la proporción de retención de información "estándar": Cada tipo de artículo tiene una proporción de retención recomendada incorporada (ver tabla anterior). En la gran mayoría de los casos, se usa el estándar. Si el usuario quiere un ajuste fino (por ejemplo, "longform pero solo 60%" → un texto largo profundamente editado), el usuario escribe una frase en el texto libre después del mensaje de apertura: "Quiero + <X%>" para anularlo. Al recibir la anulación, la IA debe anotar en la sección Brief de plan/plan.md tanto "tipo / retención estándar / anulación del usuario al X%", y recordar al usuario que es una "combinación no estándar" — este tipo de combinaciones requieren que el agente principal ajuste manualmente la proporción texto/visual en cada sección al escribir.
Plantilla de mensaje de apertura del Plan Checkpoint (primero enviar una breve explicación antes de recopilar decisiones):
El plan/plan.md ya está escrito (autoevaluación superada). Voy a confirmar contigo 5 cosas una por una: tipo de artículo / tema / ancho de maquetación /
modo de ilustraciones / portada.
Mis recomendaciones están aquí como referencia (no las elegiré por ti):
- Tipo: <X> (incluye retención de información estándar de <Y%>. Motivo: …)
- Tema: <tema> (Motivo: …)
- Ancho de maquetación: <ancho> (Motivo: …)
- Modo de ilustraciones: <estrategia> (Motivo: …)
- Portada: Activada / Desactivada (Motivo: …; si está activada, idea de composición: …)
Por defecto, pero puedes cambiarlo: el idioma sigue al original; se permite editar, recortar, reorganizar; TOC activado; a continuación se hará primero un adelanto de la primera pantalla.
Si quieres desviarte de la proporción de retención estándar del tipo, después de responder a lo anterior, dímelo directamente con el porcentaje específico (por ejemplo, "longform pero solo 60%").
A continuación, confirma cada elemento.
Después de enviar esta explicación, inmediatamente usa AskQuestion para pasar 5 preguntas (o en un entorno sin herramienta, enumera los 5 problemas con números y detente a esperar respuesta). Solo cuando se hayan recibido las respuestas a los 5 elementos se puede pasar a la Fase 4; si el usuario da una "proporción de retención no estándar" en el texto libre, primero confirma que la IA la ha anotado en plan/plan.md y luego pasa a la Fase 4.
Fase 4 —— First Spread (versión artículo: "Revisión del primer capítulo")
Primero hacer "portada (si está activada) + primera pantalla + primera sección + un bloque visual representativo". El andamio crea el espacio de trabajo aquí:
# Por defecto, portada activada
bash <ruta-a-beautiful-article>/scripts/scaffold.sh ./mi-articulo --theme=<id>
# Checkpoint 1 el usuario eligió "Portada · Desactivada"
bash <ruta-a-beautiful-article>/scripts/scaffold.sh ./mi-articulo --theme=<id> --no-cover
bash <ruta-a-beautiful-article>/scripts/scaffold.sh --list-themes
Esto crea un espacio de trabajo Vite + React + TS (instala la última versión publicada de reacticle desde npm) + directorios de memoria source/ plan/ review/ + ensamblador article/Article.tsx + un componente de sección de ejemplo (+ article/Cover.tsx por defecto, a menos que --no-cover). Ver references/scaffold.md para más detalles.
Escribir la primera pantalla (Hero / Lead) en el ensamblador article/Article.tsx; la primera sección debe escribirse como un componente independiente article/sections/01-*.tsx (este es el ancla de código para el paralelismo posterior, ver references/section-build.md).
Portada (si está activada): reemplazar <CoverPlaceholder /> en article/Cover.tsx por una composición gráfica personalizada según el tema y el tema principal del artículo; no tocar el contenedor externo (3:4 + salto de página para impresión). La guía de diseño de portadas está en references/cover.md.
Previsualizar con npm run dev. Esto determina el tono del título / tamaño de fuente / densidad de contenido / estilo Raw / modo de ilustraciones / idoneidad del tema.
Después de completar la primera sección, según el protocolo de control de calidad estricto, crear el First Spread Reviewer SubAgent, que escribe review/first-spread-review.md (incluye la autoevaluación de 5 puntos de la portada, ver references/cover.md); después de corregir, pasar al Checkpoint 2.
Checkpoint 2 · First Spread（★Nodo duro, obligatorio detenerse）
Deja que el usuario revise la primera pantalla + la primera sección, y seleccione el modo de desarrollo posterior. Se aplica la misma regla de hierro de recopilación de decisiones del Checkpoint 1: dos elementos se confirman de forma independiente; prohibido empaquetar; prioritario AskQuestion; sin herramienta, enumerar con números y detenerse a esperar respuesta.
Primero enviar un mensaje breve:
La primera pantalla + la primera sección están hechas; npm run dev para previsualizar en localhost.
La conclusión del control de calidad está en review/first-spread-review.md (ya corregido según los elementos fallidos; se listan las correcciones realizadas).
A continuación, dos cosas que debes confirmar de forma independiente: 1) Conclusión de la revisión 2) Modo de desarrollo posterior.
Luego usar AskQuestion para pasar dos preguntas independientes (o enumerar dos problemas con números y detenerse a esperar respuesta):
- Conclusión de la revisión — Opciones:
Aprobada · Pasar a generación completa/Modificación parcial · Diré qué cambiar por separado/Tema o maquetación inadecuados · Volver al Checkpoint 1. - Modo de desarrollo posterior — Opciones:
A · Agente único secuencial (por defecto · más estable · estilo más uniforme)/B · Múltiples agentes en paralelo (más rápido · ligeras diferencias de estilo).
No empaquetar estas dos cosas como "Aprobada + A, ¿OK?" — el usuario puede querer "Aprobada pero con B" o viceversa. Una vez recibidas las respuestas a ambas preguntas, pasar a la Fase 5.
Fase 5 —— Full Article Build
Generar el artículo completo según el modo de desarrollo seleccionado en el Checkpoint 2. Ver references/section-build.md + references/component-policy.md + references/raw-policy.md.
Regla de hierro · Cada sección debe ser un archivo de componente independiente (article/sections/NN-*.tsx), está terminantemente prohibido escribir múltiples secciones directamente en un solo componente. article/Article.tsx es solo un ensamblador: importa y ordena las secciones, es propiedad del agente principal. Los Raw grandes también se aíslan en article/raw-blocks/NN-*.tsx. El aislamiento a nivel de archivo es un requisito previo para el paralelismo de múltiples agentes.
Modos de desarrollo (seleccionado en Checkpoint 2):
- A · Agente único secuencial (por defecto): El agente principal escribe cada
sections/NN-*.tsxsecuencialmente; es el más estable y el estilo más uniforme. - B · Múltiples agentes en paralelo: Cada subagente posee un archivo
sections/NN-*.tsxpara desarrollarlo en paralelo; el agente principal es responsable de la fusión y la estabilidad — mantiene los imports y el orden enArticle.tsx, ejecutanpm run typecheck/build, supervisa la coherencia del tema y el estilo, resuelve conflictos. La plantilla de prompt para subagentes está enreferences/section-build.md.
Principios restantes: El cuerpo del texto es el principal; todos los Raw usan tokens de tema --ra-*, prohibidos los estilos no controlados; la retención del 100% de la información se basa principalmente en una estructura de texto largo, con Raw / ilustraciones como mejora; en caso de baja densidad de información, se puede aumentar la proporción de bloques visuales, pero siempre debe ser forma de artículo.
Después de completar cada sección, debe seguir el protocolo de control de calidad estricto con el Section Reviewer SubAgent: comprobar si ha completado la tarea del outline / si cumple con la proporción de retención de información / si hay cohesión con las secciones anterior y posterior / si hay una componentización excesiva / si hay suficiente cuerpo de texto / si Raw e ilustraciones tienen un propósito claro / si el número de la sección es coherente.
El SubAgent devuelve pass/fail + puntos de reparación como mensaje (si es pass, una línea OK; si es fail, enumera los puntos de reparación); no escribir archivos review/section-NN-review.md. El agente principal, al recibir elementos fallidos, repara directamente el archivo de la sección correspondiente antes de informar de la entrega de esta sección.
Fase 6 —— Final Review（Revisión final desde tres perspectivas）
Revisar desde las perspectivas de lector / tema / técnica, produciendo review/final-review.md + lista de reparaciones. La lista de verificación completa y estricta está en references/review-checklist.md. Se recomiendan tres revisores (al menos un SubAgent independiente si no hay equipos):
- Editorial Reviewer: cualidad de artículo, selección de información, estructura.
- Visual Reviewer: tema, Raw, ilustraciones, versión móvil.
- Technical Reviewer: compilación, consola, código / fórmulas, accesibilidad.
Líneas rojas clave: sigue siendo un artículo (no una aplicación) · la proporción de retención de información cumple con el Plan · la información que debe conservarse no se ha perdido · la coherencia del tema es uniforme · Raw sin estilos no controlados · sin olor evidente a IA · legible en escritorio + móvil · el HTML se puede compilar, abrir y compartir.
Fase 7 —— Repair（Mínima intervención）
Reparar por la unidad más pequeña; las reglas están en references/repair-policy.md. Prohibido: reescribir todo el artículo por un solo fallo / modificar la estructura del artículo ya confirmada para cambiar lo visual / eliminar contenido que el usuario especificó que debe conservarse para comprimir información. Solo si hay reparaciones se escribe review/repair-log.md (sin reparaciones / todo correcto a la primera, no se escribe).
Checkpoint 3 · Final（★Confirmación de entrega）
Después de terminar la revisión final, detenerse y dejar que el usuario confirme de forma independiente la decisión de entrega (no saltársela con "Voy a exportar HTML, está bien así" directamente). Prioritario AskQuestion; sin herramienta, enumerar los problemas con números en el mensaje y detenerse a esperar respuesta.
- Decisión de entrega — Opciones:
Aprobado · Exportar HTML para entrega/Aprobado · Exportar HTML + PDF simultáneamente/Todavía hay reparaciones locales · Listaré exactamente qué reparar/Hagamos una pausa · Quiero echar otro vistazo.
Es solo una decisión, pero aún así hay que detenerse activamente y preguntar, no seguir silenciosamente con la exportación predeterminada de HTML.
Fase 8 —— Delivery
Compilar y entregar (comandos en references/html-output.md):
article/article.html(página única autocontenida, CSS + JS en línea, se puede abrir sin conexión) — producto principal.- Opcional
article/article.pdf: solo se genera si el usuario eligió "Aprobado · Exportar HTML + PDF simultáneamente" en Checkpoint 3. Comando:
El script detecta el sistema…bash <ruta-a-beautiful-article>/scripts/html-to-pdf.sh
…
[truncated for translation]