¿Qué hace Starter Harness Designer — Coding v1?
"Lo que el agente no logró no fue por falta de capacidad, sino por falta de entorno."
¿Para quién es este skill?
- Personas que crean su primer harness de codificación
- No desarrolladores / juniors que quieren armar un equipo de desarrollo
- Quienes desean comenzar rápidamente con plantillas probadas de full-stack, API o ML
Mantiene la misma filosofía de tres fases Planificador → Generador → Evaluador que el skill para expertos harness-designer-coding, pero redistribuye la complejidad de entrada y la precisión de salida a nivel principiante.
| Fase | Para expertos | Starter (este skill) |
|---|---|---|
| Planificador | 4 etapas de descubrimiento, preguntas abiertas | 3 preguntas de opción múltiple → emparejamiento con número de exemplar |
| Generador | Diseño → creación de archivos y estructura | Replicación de exemplar + sustitución |
| Evaluador | Validación independiente de 8 pilares | Lista de verificación ligera — solo omisiones de sustitución y referencias rotas |
Matriz de skills
│ Experto (diseño libre) │ Principiante (replicación de exemplar)
──────────────┼─────────────────────────────────────┼──────────────────────────────────────────
Espacio de │ harness-designer-workspace │ harness-starter-workspace
trabajo │ │
──────────────┼─────────────────────────────────────┼──────────────────────────────────────────
Codificación │ harness-designer-coding │ harness-starter-coding ★ (este skill)
Cuándo NO usar este skill
- Documentación, análisis, creación de contenido →
harness-starter-workspace - Usuarios avanzados que necesitan libertad arquitectónica →
harness-designer-coding - Microservicios empresariales → skill
enterprise
Flujo de ejecución (total 5–10 minutos)
1. [Planificador] 3 preguntas de opción múltiple (tipo de app, naturaleza de datos, escala)
2. [Planificador] Emparejamiento con número de exemplar + recomendación de Modo Escala + preselección
3. [Generador] Replicación de exemplar de harness-100
4. [Generador] Sustitución de nombre de proyecto, pila tecnológica y términos de dominio
5. [Evaluador] Lista de verificación ligera (10 segundos)
6. Notificación de finalización ("Ahora desarrolla así")
Fase 0: Coincidencia de Patrones (Planificador)
Pregunta 1 — ¿Qué quieres crear? (Opción múltiple)
| N.º | Tipo de app | Exemplar representativo |
|---|---|---|
| 1 | 🌐 Aplicación web full-stack (frontend + backend + BD) | #16-fullstack-webapp |
| 2 | 🔌 Solo servidor API | #18-api-designer |
| 3 | 📱 App móvil (iOS/Android) | #17-mobile-app-builder |
| 4 | 🗃️ Pipeline de datos / ETL | #27-data-pipeline |
| 5 | 🤖 App de IA/LLM / RAG | #41-llm-app-builder |
| 6 | 🧪 Experimentos ML / entrenamiento de modelos | #31-ml-experiment |
| 7 | 🎨 Sistema de diseño (basado en shadcn) | #36-design-system |
| 8 | 🔐 Auditoría de seguridad / pruebas de penetración | #28-security-audit |
| 9 | 🚀 Solo CI/CD / infraestructura | #20-cicd-pipeline |
| 10 | ♻️ Modernización de legado / refactorización | #22-legacy-modernizer |
Pregunta 2 — ¿Cuál es la escala? (Opción múltiple → determina automáticamente el Modo Escala)
| Escala | Modo Escala | Agentes asignados |
|---|---|---|
| MVP / prototipo de 1 persona | Single | Solo el agente más esencial |
| Equipo pequeño / < 1 mes | Reduced | 3 personas (arquitecto + desarrollador principal + QA) |
| Mediano / producción | Full | 5 personas (arquitecto + frontend + backend + QA + DevOps) |
Pregunta 3 — ¿Nombre del proyecto?
Basado en el nombre de la carpeta. No se pregunta la pila tecnológica — se utiliza la pila predeterminada del exemplar (el usuario puede cambiarla más tarde si es necesario).
Pila predeterminada (sin sustitución):
- Full-stack: Next.js + Prisma + SQLite
- API: FastAPI o Express
- Móvil: React Native (Expo)
- Datos/ML: Python + pandas + scikit-learn
- RAG: Next.js + Vercel AI SDK + pgvector
Pregunta 4 — ¿Quieres registrar el historial de cambios? (Opcional, sí/no)
"¿Quieres crear un espacio para registrar qué cambió y por qué cuando mejores este harness más adelante?"
- sí → Se crean automáticamente la wiki
05-flow-history/y el archivo00-system/protocols/flow-change-protocol.md(la compilación inicial se registra como cambio 0001). Referencia:~/.claude/skills/harness-designer-workspace/references/flow-history-template.md - no → No se crea (se puede agregar manualmente más tarde)
Propósito: retrospectiva de mejoras de flujo, fundamentos para reversiones, referencia al crear otros harness similares. Para prototipos de 1 a 2 semanas, se recomienda no.
Principio de gestión: Este historial solo registra cambios en el sistema de flujo de trabajo (prompts, protocolos, plantillas, comandos, CLAUDE.md).
No registra los productos generados por el sistema (código, resultados de compilación, registros de despliegue).
Criterio de distinción: "Si este cambio no hubiera ocurrido, ¿el resultado de la próxima ejecución sería diferente?"
→ Sería diferente = cambio del sistema = registrar / No sería diferente = producto = no es necesario registrar
Detalles: 00-system/protocols/flow-change-protocol.md
Fase 1: Selección de Preselección (pesos de evaluación)
| Preselección | Descripción | Recomendación automática |
|---|---|---|
| [Equilibrado] (predeterminado) | Todos los criterios de calidad iguales | Valor predeterminado |
| [Calidad primero] | OWASP, pruebas, Reviewer con peso 2x | Auditoría de seguridad, pagos, salud, finanzas |
| [Velocidad primero] | Escala=Single, pruebas mínimas | Hackatones, prototipos individuales |
La selección se registra en _workspace/00_input.md.
Fase 2: Generador — Replicación y sustitución de exemplar
Etapa de replicación (retroceso automático)
Detecta automáticamente la presencia de gh para elegir la mejor forma de descarga. Funciona igualmente con solo git.
EXEMPLAR="{NN}-{nombre-del-exemplar}" # Resultado del emparejamiento del Planificador (ej.: 16-fullstack-webapp)
BASE="ko/$EXEMPLAR/.claude"
if command -v gh &>/dev/null && gh auth status &>/dev/null 2>&1; then
# ── Método A: GitHub CLI (gh) ──────────────────────────────
echo "📡 Descargando con gh api..."
FILES=$(gh api "repos/revfactory/harness-100/git/trees/main?recursive=1" \
--jq ".tree[] | select(.path | startswith(\"$BASE/\")) | select(.type==\"blob\") | .path")
mkdir -p .claude/agents .claude/skills
while IFS= read -r filepath; do
rel="${filepath#$BASE/}"
dest=".claude/$rel"
mkdir -p "$(dirname "$dest")"
gh api "repos/revfactory/harness-100/contents/$filepath" \
--jq '.content' | base64 -d > "$dest"
echo " ✅ $dest"
done <<< "$FILES"
else
# ── Método B: git sparse checkout (cuando no hay gh) ─────
echo "📡 Descargando con git sparse checkout..."
TMP=$(mktemp -d)
git clone --depth 1 --filter=blob:none --sparse \
https://github.com/revfactory/harness-100.git "$TMP"
git -C "$TMP" sparse-checkout set "$BASE"
mkdir -p .claude
cp -r "$TMP/$BASE/." .claude/
rm -rf "$TMP"
echo " ✅ sparse checkout completado"
fi
| Condición | Método usado | Herramientas necesarias |
|---|---|---|
gh instalado + autenticado | Método A (gh api) | gh |
Solo git disponible | Método B (sparse checkout) | git |
| Ninguno o falla | Método C (Claude genera directamente tras confirmación del usuario) | Ninguna |
Si ambos métodos A y B fallan, Claude informa directamente al usuario:
⚠️ No se pudo obtener la plantilla desde GitHub.
Causa:
ghygitno están disponibles o no hay conexión a Internet.En este caso, Claude puede escribir los archivos del harness directamente consultando la descripción del exemplar. Sin embargo, dado que no es una plantilla real validada sino una recreación de la estructura por Claude, puede haber diferencias de calidad.
¿Deseas continuar?
- Sí → Claude genera los archivos
.claude/directamente (basado en exemplar-index.md)- No → Detenerse aquí. Vuelve a intentarlo después de conectar a Internet o instalar git.
Si el usuario elige Sí: lee la descripción del exemplar correspondiente en references/exemplar-index.md y escribe directamente la estructura de CLAUDE.md, agents/, skills/.
Si el usuario elige No: se detiene inmediatamente, indica cómo reintentar y finaliza.
Estructura después de la finalización:
.claude/
├── CLAUDE.md
├── agents/
│ ├── architect.md — Requisitos, arquitectura, BD, diseño de API
│ ├── frontend-dev.md — React/Next.js (eliminado según Escala)
│ ├── backend-dev.md — API, BD, Autenticación
│ ├── qa-engineer.md — Pruebas, revisión de código (Revisor)
│ └── devops-engineer.md — CI/CD, infraestructura (eliminado según Escala)
└── skills/
├── {orchestrator}/skill.md
├── component-patterns/skill.md
└── api-security-checklist/skill.md
- Eliminar archivos de agente según el Modo Escala:
- Single → Solo el arquitecto (o el más relevante)
- Reduced → Arquitecto + desarrollador principal + QA
- Full → Los 5 completos
- Crear carpeta
_workspace/. Convención de numeración de artefactos:00_input.md— Entrada del usuario organizada01_architecture.md— Diseño arquitectónico02_api_spec.md— Especificación de API03_db_schema.md— Esquema de BD04_test_plan.md— Plan de pruebas05_deploy_guide.md— Guía de despliegue06_review_report.md— Informe de revisión
Reglas de sustitución
| Original | Sustitución | Notas |
|---|---|---|
| Nombre del harness | Nombre del proyecto del usuario | 16-fullstack-webapp → mi-app-todo |
| Pila tecnológica (Next.js/Prisma, etc.) | Mantener por defecto | Solo se reemplaza si el usuario lo especifica |
| Palabras clave de activación | Palabras clave del dominio | "todo app" → palabra clave del proyecto |
_workspace/NN_*.md | Mantener | No cambiar nunca la convención de numeración |
| Inyección de OWASP, SOLID, DORA | Mantener absolutamente | Esencial para la especialización del dominio |
| Tabla de Modos Escala | Mantener | Conservar definiciones de Full/Reduced/Single |
Protocolo SendMessage | Mantener | Mecanismo de comunicación entre agentes |
Principios de Comportamiento del Agente de Codificación (inspirados en Karpathy, inserción obligatoria)
Después de la replicación del exemplar, debes agregar la siguiente sección al final de .claude/CLAUDE.md (no se permite sustituir, es objeto de conservación):
## Principios de Comportamiento del Agente de Codificación (inspirados en Karpathy)
Todos los agentes de codificación cumplen los siguientes 4 principios al trabajar.
Los detalles se encuentran en el skill karpathy-guidelines (activación automática).
1. Piensa antes de codificar — Especifica suposiciones, pregunta si hay ambigüedad, ofrece alternativas
2. Simplicidad primero — Solo lo solicitado. No se permiten abstracciones ni funciones especulativas
3. Cambios quirúrgicos — Modifica solo las líneas solicitadas. No se permite mejorar código circundante
4. Ejecución orientada a objetivos — Criterios de éxito verificables → bucle → confirmación
Agregar a la lista de verificación ligera del Evaluador el elemento "Sección de los 4 principios Karpathy presente en CLAUDE.md".
Lista de elementos no sustituibles
- Nombres de marcos: OWASP Top 10, SOLID, DDD, Test Pyramid, DORA Metrics, CWE Top 25, Star/Snowflake Schema, SHAP/LIME, Great Expectations
- Protocolos: SendMessage, TaskCreate, TaskUpdate
- Convenciones de carpetas:
_workspace/,src/, prefijo numérico - Definiciones de Modos Escala
- Estructura de 3 Escenarios de Prueba (Normal / Existente / Error)
- Modificaciones automáticas de bkit: Los principios Karpathy, OWASP Top 10, DORA Metrics, Modos Escala no deben ser modificados por sugerencias de agentes bkit (code-analyzer, pdca-iterator, etc.)
- Elementos de bucle: Criterios de finalización (condición de terminación), orden de revisión del Revisor (qa-engineer), formato de decisión del informe de revisión — no se permite sustituir ni eliminar (el bucle solo funciona si hay Meta + Verificación + condición de terminación)
Simplificación de términos (para explicación al usuario)
| Técnico | Texto sencillo |
|---|---|
| architect | diseñador |
| frontend-dev | desarrollador frontend |
| backend-dev | desarrollador backend |
| qa-engineer | revisor de calidad |
| devops-engineer | responsable de despliegue |
| Dependency DAG | lista de tareas en orden |
| Scale Mode | tamaño del equipo |
Los archivos internos mantienen el término técnico; solo en la conversación con el usuario se usa el texto sencillo.
Fase 3: Evaluador — Lista de verificación ligera
Verificación automática (10 segundos)
- Existe
.claude/CLAUDE.md - El número de archivos en
agents/coincide con el Modo Escala (Single=1, Reduced=3, Full=5) - Se incluye el rol de Revisor (qa-engineer)
- Existe
skills/<orchestrator>/skill.md - Al menos 1 skill de extensión de agente (component-patterns o api-security-checklist)
- Se creó la carpeta
_workspace/+ plantillas de artefactos numerados - Se conservan los nombres de marcos como OWASP, SOLID (verificar con grep que coincida el conteo original)
- Existe la sección
should-NOTde Límites de Activación - Existe la tabla de Modos Escala
- Existe la sección de 3 Escenarios de Prueba (Normal / Existente / Error)
- 0 ocurrencias del nombre original del exemplar (ej.:
16-fullstack-webapp) - (si la pregunta 4 fue sí) Se crearon la carpeta
05-flow-history/y el archivo00-system/protocols/flow-change-protocol.md - En orchestrator skill.md existen criterios de finalización (condiciones de terminación) verificables
- El artefacto del Revisor (review_report) tiene un formato que incluye decisión de aprobado / necesita modificación
En caso de fallo
- Omisión de sustitución → El Planificador vuelve a preguntar
- Pérdida de marcos → Replicar exemplar de nuevo y luego sustituir
- 3 fallos → Indicar cambio al skill para expertos
harness-designer-coding
Fase 4: Notificación de finalización (informe en texto sencillo para no desarrolladores)
✅ ¡El harness de codificación está listo!
📁 Ubicación: /mi-app-todo/.claude/
👥 Equipo de desarrollo (Modo Reduced, 3 personas):
- Diseñador (architect): estructura de BD y API
- Desarrollador backend: Next.js API + Prisma
- Revisor de calidad (qa): pruebas y revisión de código
🛠️ Pila predeterminada: Next.js + Prisma + SQLite (se puede cambiar)
🚀 Cómo usarlo:
1. En Claude Code, pide algo como "Crea la función de inicio de sesión para la app todo"
2. El equipo trabaja en orden:
Diseñador → Desarrollador backend → Revisor de calidad
3. Resultados: _workspace/01_architecture.md ~ 06_review_report.md
4. Código fuente: se genera en la carpeta src/
🔒 Seguridad y calidad incorporadas:
- Lista de verificación OWASP Top 10 aplicada automáticamente
- Revisión de código basada en principios SOLID
- 3 escenarios de prueba (normal, archivo existente, error)
🔄 Cómo funciona el equipo (bucle):
El equipo opera en un bucle de "Objetivo (Meta) → Implementación → Revisión (Check) → Finalizar al aprobar".
El informe del último revisor de calidad (06_review_report.md) es el resultado de la verificación.
Si no te gusta el resultado, vuelve a pedir con más detalles —
esa decisión final es tu papel (bucle externo).
📘 Próximos pasos:
- Si quieres ampliar el equipo a 5 personas, agrega frontend y responsable de despliegue (Modo Full)
- Para personalización avanzada, usa el skill harness-designer-coding
Material de referencia
- exemplar-index.md — 27 exemplars de codificación + Modos Escala + índice de marcos
- Original: https://github.com/revfactory/harness-100 (Apache-2.0)
- Variante para expertos:
harness-designer-coding - Variante para espacios de trabajo:
harness-starter-workspace