Redacción guiada por spec: por qué supera al ChatGPT genérico

Redactar documentos complejos y regulados — políticas, narrativas de controles, informes CAPA, paquetes de autorización — con una interfaz de chat genérica es tentador: pegas un prompt y obtienes un borrador. El problema es la consistencia, la estructura y el cumplimiento. Los prompts puntuales no imponen flujos de trabajo, no ejecutan comprobaciones y no dan al modelo forma de corregirse. La redacción guiada por spec en Rakenne le da la vuelta: los skills definen flujos de trabajo, cargan referencias y usan herramientas de extensión para que el agente pueda validar, corregir y mantener la calidad. Este artículo explica por qué ese enfoque es mucho mejor que el “prompting habitual en ChatGPT” y muestra ejemplos concretos y comparativas de salida.

Por qué guiado por spec gana al prompting ad hoc

En resumen: la redacción guiada por spec da al LLM una spec (workflow + referencias + estructura) y herramientas (extensiones) para comprobar y corregirse. El prompting genérico no.

Cómo los skills Rakenne implementan la redacción guiada por spec

En Rakenne cada skill es un paquete pequeño que el agente pi puede activar. Suele incluir:

1. SKILL.md — Nombre, descripción (cuándo usarlo) y un workflow: pasos ordenados (p. ej. definir alcance → cargar referencia → redactar → validar).
2. Referencias — Archivos Markdown (normas, listas de criterios, esquemas) que el agente carga cuando el skill está activo, para que el borrador siga alineado con la autoridad.
3. Herramientas de extensión (opcional) — Herramientas TypeScript registradas en el agente (extension.ts) que ejecutan comprobaciones deterministas sobre el documento (cobertura, gates lógicos, completitud). El agente las invoca, lee el resultado y revisa hasta que las comprobaciones pasen.

El contexto del proyecto (tipo de documento, dominio, glosario) vive en AGENTS.md en el workspace, así que cada conversación en ese proyecto tiene el mismo alcance.

A continuación usamos skills reales de Rakenne para ilustrar workflows, comprobaciones y autocorrección, y luego comparamos las salidas.

Ejemplo 1: Política de medicación HIQA (workflow + referencia)

Skill: HIQA Designated Centre Medication . Redacta una política de medicación para centros designados en Irlanda alineada con los estándares HIQA.

Workflow en el skill:

1. Definir alcance — Tipo de centro, autoadministración frente a medicación administrada, procedimientos existentes.
2. Cargar referencia — Leer references/hiqa-nssbh.md para el NSSBH Theme 3 (cuidado seguro, seguridad de medicación).
3. Redactar — Producir una política que cubra: pedido, almacenamiento, prescripción, administración, autoadministración, hojas MAR, errores/incidentes, eliminación, formación, revisión.
4. Referencia cruzada — Alinear con notificación de incidentes y planificación de cuidados/apoyo.

El archivo de referencia detalla los ocho temas HIQA y las expectativas de gobernanza para que el agente no adivine.

Rakenne (con el skill): El agente sigue el workflow, incorpora el NSSBH Theme 3 y los textos de gobernanza relacionados desde la referencia y produce una política con secciones nombradas (pedido, almacenamiento, administración, errores, formación, etc.) y alineación explícita con “NSSBH Theme 3” y contexto “designated centre”.

ChatGPT genérico: Podrías pedir: “Escribe una política de medicación para una residencia en Irlanda.” El modelo suele devolver una “política de medicación” genérica aplicable en cualquier sitio: “revisión periódica”, “personal apropiado” vagos, sin vínculo con HIQA o NSSBH. No hay garantía de que el Theme 3 (o almacenamiento, MAR, errores, eliminación) quede cubierto de forma sistemática ni paso integrado de “cargar referencia y luego redactar”.

Ejemplo 2: Narrativas de control SOC 2 (workflow + herramientas de validación)

Skill: SOC 2 Control Narrative Author . Construye documentación SOC 2 con narrativas de control, mapeo TSC y marcadores de evidencia.

Workflow:

1. Alcance — Qué categorías TSC (Security siempre; opcionalmente Availability, PI, Confidentiality, Privacy).
2. Narrativas de control — Para cada criterio en alcance (CC1–CC9, A1, PI1, C1, P1–P8): narrativa + referencia de evidencia.
3. Evidencia — Añadir marcadores de evidencia por narrativa.
4. Validar — Ejecutar las extensiones y corregir hasta que pasen.

Herramientas de extensión:

• check_trust_services_criteria_coverage — Asegura que cada criterio TSC en alcance tenga narrativa y referencia de evidencia; señala criterios no mapeados.
• soc2_narrative_reliability_check — Aplica la rúbrica SOC 2 Reliability: señala frases vagas (“revisado periódicamente”, “la dirección mantiene la seguridad”) y exige especificidad (quién, cómo, cuándo, dónde, tecnología nombrada).

Rakenne (con el skill): El agente redacta las narrativas y ejecuta ambas herramientas. Si CC4 no tiene referencia de evidencia o la narrativa dice “el acceso se revisa periódicamente”, las herramientas devuelven FAIL con hallazgos concretos. El agente revisa (añade evidencia, especifica “trimestralmente por el equipo de seguridad vía informe de acceso IdP”) y reejecuta hasta PASS.

ChatGPT genérico: Pides “narrativas de control SOC 2 para Security”. Suele salir texto que habla de “controles” y “políticas” pero no cubre sistemáticamente CC1–CC9, no mapea cada criterio a narrativa + evidencia y usa justo el tipo de lenguaje vago que la rúbrica rechaza (“revisado periódicamente”, “controles apropiados”). No hay comprobación automatizada; huecos y vaguedad solo aparecen al preparar la auditoría.

Ejemplo 3: Informe CAPA (workflow + gates lógicos)

Skill: CAPA Report . Informes de acción correctiva y preventiva para no conformidades (ISO 9001 / ISO 13485).

Workflow:

1. No conformidad — Hallazgo, alcance, contención.
2. Causa raíz — Completar una sección 5 Whys (Why 1 … Why 5). No proponer acciones hasta que esté hecho.
3. Gate — Ejecutar root_cause_logic_gate sobre el documento. Solo continuar cuando pase.
4. Acciones correctivas / preventivas — Acciones, responsables, fechas límite.
5. Implementación — Registrar completado.
6. Verificación de eficacia — Fijar una fecha futura para la verificación. Ejecutar verification_of_effectiveness_timer antes de cerrar; no cerrar hasta que pase.

Herramientas de extensión:

• root_cause_logic_gate — Comprueba que exista sección Causa raíz / 5 Whys y al menos cinco niveles why distintos. Falla si el documento pasa a “soluciones” antes de un 5 Whys correcto.
• verification_of_effectiveness_timer — Asegura que exista fecha de verificación de eficacia y que sea en el futuro. Evita cerrar la CAPA antes de que la verificación esté programada.

Rakenne (con el skill): El agente redacta la no conformidad y la causa raíz. Si solo tiene tres niveles why o salta a “formaremos al personal”, el gate devuelve FAIL con “Niveles why detectados: 3/5. Complete un análisis 5 Whys antes de proponer soluciones.” El agente añade Why 4 y Why 5, reejecuta el gate y sigue con las acciones. Antes de cerrar debe fijar una fecha de eficacia futura; si pone “2025-01-15” y hoy es después, el timer falla y el agente debe fijar una fecha futura.

ChatGPT genérico: Pides “una CAPA para un hallazgo de auditoría sobre control documental”. A menudo obtienes un párrafo de causa y una lista de acciones de golpe — sin 5 Whys impuesto, sin gate y sin comprobación de que la verificación de eficacia esté programada en el futuro. El resultado parece plausible pero no pasaría una revisión ISO 9001/13485 estricta.

Ejemplo 4: Paquete de autorización FedRAMP (workflow + comprobación de completitud)

Skill: FedRAMP Authorization Package . SSP, anexos, SAP, SAR, POA&M.

Workflow (simplificado): Categorizar sistema → descripción del sistema → límite de autorización → flujos de datos → implementaciones de controles (con referencia de baseline) → anexos SSP → Validar con fedramp_package_completeness_check. Corregir y reejecutar hasta PASS. Sub-workflows separados para SAP/SAR y POA&M, usando la misma herramienta para señalar controles faltantes, secciones de anexo faltantes o ítems POA&M sin plan de remediación o vencidos sin justificación.

Rakenne (con el skill): El agente sigue el workflow, carga las referencias de baseline y anexos, redacta las secciones y ejecuta la comprobación de completitud. Los huecos (p. ej. controles no implementados sin justificación, sección PIA faltante) se reportan; el agente los rellena y revalida.

ChatGPT genérico: Pides “un SSP FedRAMP para un producto SaaS”. Obtienes un relato largo que puede parecer un SSP pero no sigue la estructura FedRAMP real, la implementación control a control ni la lista de comprobación de anexos. No hay forma de verificar cobertura de baseline o completitud de anexos; descubres los huecos después a mano.

Resumen: mismo modelo, resultados distintos

El LLM subyacente puede ser el mismo. La diferencia está en cómo se usa:

• Prompting genérico: Una vez o ida y vuelta sin flujo fijo, sin referencias cargadas por el skill, sin herramientas de validación. La salida es genérica, la estructura se desvía y el modelo no puede “comprobar y corregir” de forma fiable.
• Guiado por spec en Rakenne: Los skills definen workflow, referencias y extensiones. El agente sigue el workflow, carga las referencias correctas, redacta y luego ejecuta herramientas que devuelven PASS/FAIL y hallazgos concretos. Corrige hasta que las comprobaciones pasen y mantiene la estructura y calidad deseadas.

Para documentos complejos y regulados — políticas, narrativas de control, CAPAs, paquetes de autorización — la redacción guiada por spec con workflows y herramientas de validación no es un pequeño avance; es la diferencia entre “quizá suficiente” y “listo para auditoría y repetible”.

Para probarlo: elige un skill Rakenne para tu dominio, crea un proyecto con ese workflow y compara la salida estructurada y validada con lo que obtienes de un solo prompt en ChatGPT.