kkh2114/claude-skills-public

Harness Designer v4

Principio: "Dale un mapa al agente, no un manual de 1000 páginas." — OpenAI Harness Engineering Principio: "No dejes que el generador evalúe su propio trabajo." — Anthropic GAN-Inspired Harness

Los 5 pilares del diseño de arneses

Todo workspace que genere este skill debe cumplir con estos 5 pilares:

Pilar	Pregunta clave	Principio
Progressive Disclosure	¿Puede el agente ver solo lo que necesita?	Índice (~100 líneas) → Puntero → Documento profundo
Mechanical Enforcement	¿Las reglas se imponen mecánicamente?	La documentación por sí sola no mantiene la coherencia
Feedback Loop	¿Es posible una mejora estructural tras un fallo?	"No es esforzarse más", sino "¿qué capacidad falta?"
Session Continuity	¿La transición entre sesiones es limpia?	progress + feature-status + git
Entropy Management	¿La estructura se mantiene con el tiempo?	Limpieza periódica, verificación de frescura de documentos

---

Relación de las dos capas

┌─────────────────────────────────────────────────────┐
│  CAPA 1: Meta (Rol de este skill)                   │
│                                                     │
│  Planner ──→ Generator ──→ Evaluator                │
│     ↑         (Secuencia unidireccional, sin referencias inversas)  │
│     └──── Feedback si es insuficiente ──────────┘    │
│                                                     │
│  Propósito: Diseñar, crear y verificar la estructura del workspace  │
└─────────────────────────┬───────────────────────────┘
                          │ Estructura completada tras aprobación
                          ▼
┌─────────────────────────────────────────────────────┐
│  CAPA 2: Operativa (Rol del workspace completado)    │
│                                                     │
│  ┌ Initializer (Solo primera ejecución) ─→ Configuración del entorno │
│  │                                                  │
│  └ Operating Agent (Ejecución repetida):             │
│    Agent-A ─┐                                       │
│    Agent-B ─┼──→ Chairman Síntesis ──→ Resultado final │
│    Agent-C ─┘  (Paralelo independiente, sin interacción) │
│                                                     │
│  Propósito: Realizar el trabajo real (análisis, decisiones, informes, etc.) │
└─────────────────────────────────────────────────────┘

---

CAPA 1: Meta — Proceso de diseño del arnés

3 tipos de agentes L1 (Secuencia unidireccional, sin referencias inversas)

Los entregables se pasan en orden Planner → Generator → Evaluator. Cada agente recibe solo el entregable de la etapa anterior y no previsualiza los resultados de la siguiente.

Planner (Agente planificador)

Analiza la intención del usuario y diseña la estructura del arnés.

• Entrada: Requisitos del usuario (recopilados mediante preguntas)
• Salida: Propuesta de composición de agentes + Borrador de estructura de carpetas + Propuesta de criterios de evaluación
• Restricción: Diseña sin ver los resultados de Generator ni Evaluator

Generator (Agente constructor)

Convierte el diseño del Planner en archivos reales.

• Entrada: Diseño aprobado por el Planner
• Salida: Archivos .md/.json reales (la lista completa de entregables se encuentra en la Fase 2)
• Restricción: Construye sin previsualizar los criterios del Evaluator

Evaluator (Agente evaluador)

Verifica de forma independiente los entregables del Generator.

• Entrada: Archivos creados por el Generator + Criterios de evaluación del Planner
• Salida: Puntuación basada en los 5 pilares + Resultados de verificación funcional + Comentarios de mejora
• Restricción: Solo ve los resultados, sin considerar la intención del Generator

---

L1 Fase 0: Pattern Match — Referencia a harness-100 (Nuevo v4.1)

"El 99% de un buen diseño ya lo ha hecho alguien. Búscalo y adáptalo."

Antes de entrar en Discovery, busca el exemplar más similar entre los validados de harness-100 (https://github.com/revfactory/harness-100, Apache-2.0) y utilízalo como referencia base. Para no desarrolladores, redirige al skill harness-starter-workspace.

Exemplares objetivo (73 dominios de workspace)

• Content #01–15, Business #43–55, Education #56–65, Legal #66–72, Lifestyle #73–80, Docs #81–88, Operations #89–95, Specialized #96–100

Procedimiento de la Fase 0

1. Extraer palabras clave del dominio de la solicitud del usuario (1-2 frases)
2. Presentar los 3 candidatos principales de los 73 anteriores + Confirmación del usuario
3. Registrar el número del exemplar seleccionado en el campo reference_exemplar de _workspace/00_input.md
4. Similitud de coincidencia < 0,5 → Modo de diseño libre (continuar con la Fase 1 existente)

Reflejar los resultados de la Fase 0 en las etapas posteriores

• Planner: Utilizar la composición por defecto de 4-5 especialistas + Reviewer del exemplar
• Generator: Aplicar el andamio del esqueleto del exemplar, forzar la convención de numeración _workspace/NN_*.md
• Evaluator: Utilizar como rúbrica los 8 Quality Standards del exemplar (Agent Team Mode / Domain Expertise / Structured Outputs / Dependency DAG / Error Handling / Scale Modes / Test Scenarios / Trigger Boundaries)

Pattern Fidelity (Evaluación cualitativa, solo Fase 0)

No se incluye en la puntuación automática de los 5 pilares. Se evalúa cualitativamente durante la coincidencia de exemplars en la Fase 0.

Verificar los 8 Quality Standards del exemplar de harness-100 seleccionado en la Fase 0 (Agent Team Mode / Domain Expertise / Structured Outputs / Dependency DAG / Error Handling / Scale Modes / Test Scenarios / Trigger Boundaries) de forma independiente a la puntuación del Evaluator.

• Punto de aplicación: Una vez en la Fase 0 (selección del exemplar) y una vez al informar tras el PASS del Evaluator
• Sin puntuación: No se incluye en la puntuación de los 22 ítems de los 5 pilares
• pillar-weight: Solo se pueden ajustar los pesos de los 5 pilares. Pattern Fidelity no está sujeto a pesos

Reviewer obligatorio

La capa operativa debe incluir un agente Reviewer (rol de validación cruzada). Se añade el paso de validación cruzada del Reviewer al modelo de síntesis Chairman existente.

Trigger Boundaries (should + NOT)

Planner/Generator deben incluir una sección should-NOT trigger en el skill.md del orquestador que se genere.

Inyección de framework de dominio

Inyección automática de frameworks validados por categoría:

• Content: AIDA, Pattern Interrupt, CURVE formula
• Business: BMC, TAM/SAM/SOM, Porter's 5 Forces, RICE, Van Westendorp PSM
• Education: Bloom's Taxonomy, ADDIE, CEFR, SM-2, Toulmin Model
• Legal: IRAC, MQM, GDPR/PIPA, IPC/CPC
• Lifestyle: BMR/TDEE, ACSM Guidelines, Compound Interest
• Docs: Diataxis, PREP, STAR, MADR, SemVer
• Operations: SIPOC/RACI, 4C Framework, SMART, NPS/CSAT, BARS
• Specialized: GHG Protocol, Cap Rate/IRR, IMRaD, Georgia-Pacific, Double Materiality

---

L1 Fase 1: Discovery — Funcionamiento del Planner

Discovery consta de 4 etapas de preguntas. Se procede en orden por cada etapa, y las preguntas de seguimiento se ramifican según la respuesta del usuario. Se avanza a la siguiente etapa después de recibir la respuesta de una etapa. No se preguntan todas a la vez.

1-1. Etapa 1 — Propósito y contexto (POR QUÉ / QUIÉN)

Entender la razón de ser de este workspace, no su estructura.

W1. ¿Cuál es el problema que este workspace intenta resolver?
    (¿Qué decisión/análisis/juicio no funciona bien actualmente?)

W2. ¿Quién lo usa?
    (Solo agentes / Agentes+humanos / Humanos consumen los resultados)
    → Seguimiento: ¿Cuál es el nivel de experiencia en el dominio del usuario?

W3. ¿Cuál es el criterio de éxito de este workspace?
    (¿Qué resultado indicaría que "está bien hecho"?)

W4. ¿Existe algún proceso similar existente?
    (¿Lo reemplaza? / ¿Es nuevo?)
    → Seguimiento [Reemplazo]: ¿Cuál es el mayor problema del proceso existente?
    → Seguimiento [Nuevo]: ¿Hay algún sistema de referencia?

Ramificación de preguntas de seguimiento:

• W2 con "Humanos consumen los resultados" → "¿Cuál es el rango/rol de la persona que recibe los resultados? ¿Qué formato prefiere?"
• Respuesta ambigua en W3 → "¿Qué entregable concreto indicaría éxito?"

1-2. Etapa 2 — Entregables y estructura (QUÉ)

¿Qué se crea? ¿Qué perspectivas se necesitan?

S1. ¿Cuál es el entregable final?
    (Informe / Registro de decisiones / Informe de análisis / Propuesta)

S2. ¿Cuál es el patrón de trabajo principal que se repite?
    (Entrada → Análisis → Decisión → Registro → Acumulación de conocimiento)

S3. ¿Cuántas perspectivas/roles se necesitan? ¿Cuál es la naturaleza de cada una?
    (Ej: Optimista/Pesimista/Datos/Experiencia/Regulación — que choquen y se complementen)
    → Seguimiento: ¿Hay prioridad entre las perspectivas? ¿Son iguales?

S4. ¿Se necesita un Chairman (rol de síntesis)?
    (Se encarga de la sesión principal / Agente separado / No necesario)
    → Seguimiento [Necesario]: ¿Cuál es la composición del modelo de agente?
      → Proponer tras consultar references/agent-archetypes.md

S5. ¿Cuál es el formato de entrada?
    (Entrada directa de texto / Carga de archivos / URL / Múltiple)

S6. ¿Qué salida debe conservarse?
    (Archivos de sesión / Registro de decisiones / Acumulación de conocimiento / deep-research)

Ramificación de preguntas de seguimiento:

• S3 con 5 o más perspectivas → "¿Se pueden agrupar estas perspectivas? ¿Secuencial o paralelo?"
• S4 con "Agente separado" → "¿Cuál es el marco de decisión del Chairman? ¿Go/Pivot/No-Go?"

1-2.5. Etapa 2.5 — Gestión del conocimiento (CONOCIMIENTO) [Condicional]

Opción de wiki para referenciar sistemáticamente la investigación existente en workspaces de investigación multi-agenda. Omitir en workspaces de agenda única o no relacionados con la investigación.

K1. "¿Necesita hacer referencia a investigaciones existentes en investigaciones posteriores mientras realiza múltiples agendas (temas de investigación)?"
    → "No" → Sin wiki. Ir a Etapa 3.
    → "Sí" → Ir a K2.

K2. Verificar la instalación del skill /graphify (detección automática)
    - Verificar la existencia de ~/.claude/skills/graphify/ o .claude/skills/graphify/
    - Instalado → Ir a K3.
    - No instalado → Proporcionar explicación:
      ┌─────────────────────────────────────────────────┐
      │ La wiki se crea con el skill /graphify.          │
      │ Sin este skill, no se puede crear la wiki.       │
      │                                                 │
      │ ¿Qué es /graphify?                               │
      │ - Analiza documentos/informes para crear un grafo de conocimiento │
      │ - Descubre y visualiza automáticamente conexiones entre conceptos  │
      │ - Crea automáticamente documentos wiki basados en la comunidad     │
      └─────────────────────────────────────────────────┘
      "¿Desea instalar graphify?"
      - Instalación global (~/.claude/skills/) [Usar en todos los proyectos]
      - Instalación en el proyecto (.claude/skills/) [Solo en este proyecto]
      - No instalar → ⚠️ "La funcionalidad wiki estará desactivada.
          La carpeta 45-wiki/ se creará, pero estará vacía.
          Se podrá crear más tarde instalando /graphify y usando /wiki-update."
        → Incluir solo la estructura de wiki, desactivada. Ir a Etapa 3.

K3. "¿Dónde se colocará el repositorio de la wiki?"
    - Dentro del proyecto (45-wiki/) [Por defecto]
    - Ruta externa

K4. "¿Se debe explorar la wiki automáticamente al iniciar una nueva investigación?"
    - Exploración automática + Referencia tras aprobación del usuario [Por defecto]
    - Solo permitir llamada manual (/wiki-ref)

Añadir a la salida del Planner (relacionado con wiki):

• wiki_enabled: true/false
• wiki_location: "45-wiki/" o ruta personalizada
• wiki_auto_ref: true/false
• graphify_installed: true/false
• graphify_scope: "global" | "project" | "none"

⚠️ Protección de la independencia de las referencias wiki:

• Prohibición absoluta de inyectar contenido wiki en los agentes de la Fase A (investigación independiente)
• Solo se permite la referencia tras la aprobación del usuario en la Fase B (Creative Thinker) / Fase C (Chairman)
• Al referenciar, solo transmitir marcos/metodologías/puntos de datos, no conclusiones
• Es obligatorio registrar wiki_ref, ref_approved_by, ref_approval_date en los entregables

1-2.6. Etapa 2.6 — Seguimiento del historial de cambios de flujo (HISTORIAL DE FLUJO) [Opcional]

Recomendado para proyectos donde se espera que el flujo de trabajo mejore con el tiempo. Se puede omitir en proyectos de análisis único o puntuales.

F1. "¿Quiere dejar un historial cuando el flujo de trabajo se mejore o cambie en el futuro?"

    Uso:
    - Revisión del historial de mejoras del proyecto (por qué cambió)
    - Asegurar la base para una reversión a una versión anterior si es necesario
    - Referencia para el diseño de proyectos similares futuros

    ※ No es para leer en cada nueva sesión.
      Se consulta solo al modificar, revertir o trasladar el flujo.

    → "No" → No incluir 05-flow-history/. Ir a Etapa 3.
    → "Sí" → Ir a F2.

F2. "¿Se registrará automáticamente la compilación inicial (v1) como registro change 0001?"
    - Valor por defecto: Sí (las respuestas de Planner Discovery se conservan como base de diseño)
    - No → Crear solo CHANGELOG y registrar manualmente en el primer cambio

Principios de gestión del historial de flujo (estándar después de la creación y operación): Este historial registra solo los cambios en el sistema de flujo de trabajo (reglas, procedimientos, herramientas, prompts, comandos, scripts, CLAUDE.md). Los entregables (resultados de investigación, informes, análisis, registro de agendas) creados por el sistema no son objeto de registro. Criterio de distinción: "¿Sin este cambio, el resultado de la siguiente ejecución sería diferente?" → Diferente = cambio de sistema = registro / No diferente = entregable = no es necesario registrar Detalles: 00-system/protocols/flow-change-protocol.md

Añadir a la salida del Planner (relacionado con flow-history):

• flow_history_enabled: true/false
• flow_history_initial_record: true/false (respuesta F2)

1-3. Etapa 3 — Entorno y herramientas (CÓMO)

¿En qué entorno y cómo se va a operar?

H1. ¿Qué herramienta de IA se usa?
    (Claude Code / Desktop Claude / Otras)
    → La configuración del arnés varía según la herramienta

H2. ¿Se necesita continuidad entre sesiones?
    (Análisis único / Proyecto a largo plazo / Múltiples sesiones)
    → Si es "a largo plazo", incluir entregable de traspaso de sesión

H3. ¿Cuál es la composición del modelo de agente?
    → Buscar en la web los modelos Claude más recientes y proponer
    → No codificar el nombre del modelo. El usuario siempre decide.

H4. ¿Cuál es el nivel de autonomía del agente?
    (Humano verifica cada vez / Agente decide autónomamente + informa / Totalmente autónomo)

Ramificación de preguntas de seguimiento:

• H2 con "a largo plazo" → "¿Número estimado de sesiones? ¿Es importante la acumulación de conocimiento?"
• H4 con "Totalmente autónomo" → "¿Cuáles son los criterios de escalamiento? ¿En qué situación debe preguntar al humano?"

1-4. Etapa 4 — Calidad y criterios de evaluación (CALIDAD / EVALUAR)

Identificar los valores que el usuario considera importantes y acordar los criterios de evaluación.

E1. ¿Cuáles son los atributos de calidad más importantes en este workspace? (Seleccionar 3 principales)
    □ Profundidad del análisis (información no superficial)
    □ Independencia (análisis independiente sin influencia entre agentes)
    □ Atribución de fuentes (conclusiones basadas en evidencia)
    □ Coherencia (mantener la calidad entre sesiones)
    □ Respuesta rápida (tiempo de procesamiento corto)
    □ Escalabilidad (fácil añadir agentes/roles)
    □ Documentación (trazabilidad del proceso y los resultados)
    □ Accesibilidad para el usuario (no expertos también entienden los resultados)

E2. ¿Hay planes de expansión futura?
    (Ninguno / Añadir perspectivas / Aplicar a otros dominios / Mejorar la automatización)

E3. ¿Qué no se debe comprometer nunca en este workspace?
    (Ej: "Los agentes no deben influirse entre sí", "No se aceptan conclusiones sin fuente")

E4. Por el contrario, ¿qué está bien que no esté presente inicialmente?

Ramificación de preguntas de seguimiento:

• E1 con "Independencia" → "¿A qué nivel? ¿Se prohíbe también compartir resultados? ¿O solo el análisis es independiente?"
• La respuesta de E3 → Se utiliza como entrada clave para los pesos del Evaluator

1-5. Acuerdo de pesos de evaluación (Después de completar la Etapa 4)

Analizar las respuestas de las Etapas 1 a 4 y proponer los pesos de los 5 pilares. Acordar con el usuario y finalizar.

[Proceso de propuesta de pesos]

PASO 1. Extraer palabras clave de las respuestas de las Etapas 1 a 4
  - "Independencia esencial" → Mechanical Enforcement ↑
  - "Proyecto a largo plazo" → Session Continuity ↑, Entropy Management ↑
  - "Respuesta rápida" → Progressive Disclosure ↑
  - "Atribución de fuentes" → Mechanical Enforcement ↑

PASO 2. Ajustar desde los pesos base y proponer

  Pesos base (antes de reflejar las características del proyecto):
  | Pilar | Base | Base del ajuste | Propuesta |
  |------|------|----------|------|
  | Progressive Disclosure | 20% | (Base de variación) | ?% |
  | Mechanical Enforcement | 25% | (Base de variación) | ?% |
  | Feedback Loop | 20% | (Base de variación) | ?% |
  | Session Continuity | 15% | (Base de variación) | ?% |
  | Entropy Management | 20% | (Base de variación) | ?% |

  "En este proyecto, considerando [base],
   hemos ajustado el peso de [pilar] de [base]% → [propuesta]%.
   Por favor, comente si tiene alguna opinión o modificación."

PASO 3. Reflejar los comentarios del usuario
  - De acuerdo → Finalizar
  - "Aumenta la independencia" → Aumentar Mechanical Enforcement, reducir otros pilares y volver a proponer

PASO 4. Aprobación final
  → Utilizar los pesos acordados en lugar de los pesos base de evaluator-protocol-workspace.md

1-6. Mapeo automático de patrones

Recomendar automáticamente un patrón de carpeta basado en las respuestas de la Etapa 2:

Palabra clave de respuesta del usuario	Patrón recomendado	Referencia
análisis, inversión, toma de decisiones, juicio	Patrón A (Tipo análisis/toma de decisiones)	folder-patterns.md
construcción, proceso, presupuesto, construcción	Patrón B (Tipo construcción/gestión de proyectos)	folder-patterns.md
investigación, contenido, informe	Patrón C (Tipo investigación/contenido)	folder-patterns.md
codificación a largo plazo, compilación de automatización	Patrón D (Tipo agente a largo plazo)	folder-patterns.md

1-7. Entregables del Planner

① Resumen del contexto del proyecto — Propósito, usuario, criterios de éxito, restricciones clave (basado en Etapas 1 y 2) ② Propuesta de composición de agentes — Roles, personalidad, asignación de modelos ③ Borrador de estructura de carpetas — Mapeo de patrones + Personalización ④ Diseño de continuidad de sesión — Determinar el método de traspaso (Único / Usar progress.json) ⑤ Estrategia de expansión — Decisiones de diseño para prepararse para la expansión futura (basado en Etapa 4 E2) ⑥ Criterios de evaluación + Pesos acordados — Lista de verificación de los 5 pilares + Tabla de pesos

[Planner completado — Solicitar aprobación del usuario]
Revise ①~⑥ y comente cualquier modificación.
Una vez aprobado, Generator comenzará la construcción.

---

L1 Fase 2: Build — Funcionamiento del Generator

Después de la aprobación de los entregables del Planner, crear los archivos en el siguiente orden. El Generator crea tanto la estructura de carpetas como el contenido de los archivos.

2-1. Diagrama de flujo de trabajo (Mermaid)

Diagrama que representa ambas capas. Incluye el bucle de rediseño Evaluator → Planner:

flowchart TD
    USER[Usuario] -->|Requisitos| P
    subgraph L1[Layer 1: Meta]
        P[Planner] --> G[Generator]
        G --> E[Evaluator]
        E -->|Insuficiente 70~89%| G
        E -->|Rediseño <70%| P
        E -->|Aprobado 90%+| DONE[Estructura completada]
    end
    DONE --> INIT
    subgraph L2[Layer 2: Operativa]
        INIT[Initializer
Solo primera ejecución] --> OP
        subgraph OP[Operating Agent
Ejecución repetida]
            INPUT[Entrada] --> SPLIT[ ]
            SPLIT --> A1[Agent-A]
            SPLIT --> A2[Agent-B]
            SPLIT --> A3[Agent-C]
            A1 --> CH[Chairman Síntesis]
            A2 --> CH
            A3 --> CH
            CH --> OUT[Salida + Guardar estado]
        end
    end

2-2. Creación de entregables principales (En orden)

Núm.	Entregable	Archivo de referencia	Notas
2-2a	WORKSPACE_TREE.md	folder-patterns.md	Estructura de carpetas finalizada
2-2b	CLAUDE.md (~100 líneas)	claude-md-template.md	Función de índice, tabla de enrutamiento de referencias obligatoria
2-2c	AGENTS.md	(Guía dentro de este skill)	Reglas de operación del agente + model_config
2-2d	Archivos de rol de agente	agent-archetypes.md	00-system/prompts/*.md
2-2e	5 protocolos	(Guía dentro de este skill)	00-system/protocols/
2-2f	Entregable de traspaso de sesión	session-handoff.md	progress.json + feature-status.json
2-2g	Reglas forzadas	enforcement-patterns.md	Reglas verificables estructuralmente
2-2h	Comandos slash	(Basado en el diseño del Planner)	.claude/commands/*.md
2-2i	README.md	(Guía de usuario)	Inicio rápido + Comandos + Solución de problemas
2-2j	Wiki de historial de cambios de flujo (Opcional)	flow-history-template.md	Solo cuando F1=Sí en la Etapa 2.6

2-2b. Reglas de escritura de CLAUDE.md (Muy importante)

→ Consultar references/claude-md-template.md. Debe tener menos de 100 líneas.

CLAUDE.md es el punto de entrada del agente. Una instrucción demasiado larga se convierte en "no guía":

• El contexto desplaza la tarea y el código
• El agente cae en la coincidencia de patrones local en lugar de la exploración intencionada
• Un documento monolítico envejece inmediatamente

Lo que debe incluirse obligatoriamente:

• Identidad del workspace (3 líneas)
• Tabla de composición de agentes
• Tabla de enrutamiento de referencias ← Clave de Progressive Disclosure
• Puntero del principio de independencia
• Lista de comandos

Formato de la tabla de enrutamiento de referencias:

## Enrutamiento de referencias
| Situación | Archivo a leer |
|------|----------|
| Verificar el rol del agente | → 00-system/prompts/[role].md |
| Reglas de progresión del debate | → 00-system/protocols/council-protocol.md |
| Detalles del principio de independencia | → 00-system/protocols/independence-protocol.md |
| Verificar el estado de la sesión | → progress.json |
| Estado de finalización de la función | → feature-status.json |

2-2c. Reglas de escritura de AGENTS.md

Lo que debe incluirse obligatoriamente:

• Tabla de lista de agentes de la Capa 2 (Rol / Modelo / Condición de activación)
• Sección model_config (Modelo seleccionado por el usuario + Disparador de revisión)
• Método de síntesis del Chairman + Marco de decisión (Go/Pivot/No-Go)
• Resumen del principio de independencia
• Reglas de gestión de contexto

...