Claude Method — Guia completa

Claude Method — Guia completa

Que es, como funciona, y como mantenerlo. Ultima actualizacion: Abril 2026

Parte 1 — Para todo el equipo

Esta seccion explica el metodo en lenguaje sencillo, sin jerga tecnica. Pensada para Edu, Dani y Txell.

Que es Claude Method

Es el sistema de trabajo que hemos construido para que Claude nos ayude de la mejor manera posible. No es una app ni un plugin — es un conjunto de archivos, reglas y herramientas que le dicen a Claude:

• Quien eres (tu nombre, tu rol, en que trabajas)
• Que puede y que no puede hacer (guardrails, limites)
• Que errores debe evitar (footguns: cosas que ya nos han fallado antes)
• Como debe trabajar (reglas de commit, de documentacion, de coordinacion)

Sin esto, Claude es un asistente generico. Con esto, Claude es un miembro mas del equipo que conoce el proyecto, respeta las reglas y no repite errores pasados.

Por que existe un repo separado

Hasta ahora, todo este “metodo” vivia repartido entre el codigo de CreaRack y el workspace. El problema: si manana empezamos un proyecto nuevo, tendriamos que rehacer todo desde cero.

Con el repo claude-method tenemos el metodo empaquetado y reutilizable. Es como una plantilla: la copias al proyecto nuevo y ya tienes las bases.

Donde esta cada cosa

Regla simple: si algo serviria en un proyecto nuevo, va en claude-method. Si es solo de CreaRack, va en workspace o en CreaRack-Pro.

Como te afecta a ti

Si eres Edu o Dani (devs)

En el dia a dia no cambia nada. Seguis trabajando igual. La diferencia es que:

• Cuando descubrimos un error nuevo que Claude debe evitar (un footgun), se guarda y se propaga a todos
• Cuando mejoramos una regla de trabajo, todos la reciben
• Cuando alguien se incorpore al equipo, el setup es automatico

Si eres Txell (ops/negocio)

Tampoco cambia nada en tu dia a dia. Pero si algun dia Claude empieza a hacer algo raro que antes hacia bien, puede ser que se actualice el metodo y haya que sincronizar:

cd C:\dev\CreaRackSL-workspace
powershell -ExecutionPolicy Bypass -File C:/dev/claude-method/harness/claude-method-sync.ps1

Eso actualiza tu perfil con los ultimos cambios. Normalmente Edu lo hara por ti.

Que es un “footgun”

Literalmente “pistola apuntando al pie” — un error que parece inofensivo pero causa problemas. Ejemplo real:

“Si pones CONN_MAX_AGE distinto de 0 con el servidor Daphne, la base de datos se satura y la app cae.”

Esto le paso a Claude 4 veces antes de que lo documentaramos como footgun. Ahora lo sabe siempre y nunca mas lo vuelve a hacer.

Que es un “harness”

Imagina que Claude es un caballo. El harness (arnes) es lo que lo guia: las riendas, los limites del camino, las senales de “para” y “avanza”. Sin harness, el caballo va donde quiere. Con harness, va donde tu necesitas.

En la practica, el harness son:

• Reglas que le damos antes de que actue (guides): CLAUDE.md, memorias, contexto
• Controles que verifican despues de que actua (sensors): pre-commit hooks, tests, validadores

Parte 2 — Referencia tecnica

Esta seccion detalla la arquitectura, procedimientos y mantenimiento. Pensada para Edu y Dani.

Arquitectura del sistema

claude-method (repo generico)
    │
    │  powershell -ExecutionPolicy Bypass -File C:/dev/claude-method/harness/claude-method-sync.ps1
    ▼
CreaRackSL-workspace
    ├── docs/onboarding/shared-memory/   ← footguns, feedback, infra
    ├── agents/{dev,biz,ops,support}/    ← 15 agentes CreaRack
    ├── scripts/setup-claude-code.ps1    ← onboarding automatizado
    └── claude-method/harness/claude-method-sync.ps1          ← propagacion de cambios
            │
            │  claude-method-sync.ps1 (paso 3)
            ▼
    ~/.claude/projects/*/memory/
        ├── Edu:   C--dev-CreaRack-Pro/memory/
        ├── Dani:  C--dev-CreaRack-Pro/memory/
        └── Txell: C--dev-CreaRackSL-workspace/memory/

Repositorios

Componentes del metodo

📖 Para el detalle técnico de cada componente (las 8 capas del Harness · Reglas, Memorias, Hooks, MCP, Skills, Subagents, Bibliotecario, Routines), consulta [[crearack-tech—method—harness-guide]].

Esta guía se centra a partir de aquí en procedimientos operativos (qué hago cuando ocurre X) y en el histórico de sprints del Supercontexto.

Procedimientos

Procedimiento 1: Mejorar el metodo (genérico, sirve para cualquier proyecto)

Cuando: Descubres un nuevo patron, regla o herramienta que serviria en cualquier proyecto.

Si es un agente o skill nuevo en ~/.claude/ (s60, recomendado):

1. Crear el agente/skill localmente en ~/.claude/agents/<name>.md o ~/.claude/skills/<name>/SKILL.md
2. Ejecutar: pwsh -NoProfile -File C:/dev/claude-method/harness/claude-method-promote.ps1 -Type {agent|skill} -Name <name>
   → Detecta CREATE/UPDATE/IDENTICAL, valida frontmatter, copy + commit + push a claude-method/main
3. Los demás miembros lo reciben automáticamente en su próxima sesión Claude Code via el 4º hook SessionStart

Si es un cambio en harness/, workflow/, templates/ o shared-memory/:

1. Editar en C:\dev\claude-method\
2. git add + commit + push directo a main
3. Para harness/, no hay nada que propagar: el pre-commit de cada repo ejecuta los checks directamente desde claude-method/harness/, así que basta con que cada perfil tenga al día el git pull del arranque; para global-{agents,skills}/ se propaga solo en cada SessionStart desde s60; para shared-memory/, los devs lo reciben re-ejecutando setup-claude-code.ps1

Procedimiento 2: Anadir un footgun nuevo (memoria compartida)

Cuando: Claude comete un error tecnico que no deberia repetir.

Si es generico (aplica a cualquier proyecto Python/Django):

1. Crear claude-method/onboarding/shared-memory/footgun_nombre.md
2. Push claude-method
3. Los devs lo reciben re-ejecutando setup-claude-code.ps1 o copiándolo a mano
   (el 4º hook auto-sync s60 usa -SkipMemory para no pisar memorias locales divergentes)

Si es especifico de CreaRack (ej: pysnmp 7.x, SpinetiX):

1. Crear CreaRackSL-workspace/onboarding/shared-memory/footguns_nombre.md
2. Push workspace
3. Los devs lo reciben re-ejecutando setup-claude-code.ps1 (paso [3] copia las memorias específicas del workspace)

Procedimiento 3: Incorporar nuevo miembro (actualizado 2026-04-23)

Desde el cierre de Fase 3 del plan ampliado Supercontexto, el flujo es 1-comando en Windows Proxmox nuevas:

# PARTE DEL LEAD (Edu) - preparar accesos ---------------------------------

# 1. Invitar en GitHub:
#    CreaRackSL/CreaRack-Pro      → Write (Dev) / Read (COO)
#    CreaRackSL/CreaRackSL-workspace → Write (todos)
#    CreaRackSL/claude-method     → Read (basta para clonar)
#    https://github.com/orgs/CreaRackSL/people

# 2. Generar Bearer token personal
python -c "import secrets; print(secrets.token_hex(24))"

# 3. Anadirlo al secret MCP_TOKENS en Cloudflare Pages (formato: usuario:token,usuario2:token2,...)
#    Dashboard CF → Pages → workspace → Settings → Environment Variables → MCP_TOKENS
#    IMPORTANTE: redeploy CF Pages para que aplique (los cambios de env var solo aplican en el siguiente deploy)

# 4. Pasarle el token al dev por canal privado (Signal, 1Password). NUNCA por email ni en el repo.

# Detalle completo en: claude-method/onboarding/lead-checklist.md


# PARTE DEL NUEVO DEV (Dani/Txell) - ejecutar en su Windows Proxmox nueva ---

# claude-method es PRIVADO → gh CLI logueado primero (irm a raw.githubusercontent da 404)
gh auth status   # si no: gh auth login → GitHub.com → HTTPS → navegador
gh api repos/CreaRackSL/claude-method/contents/onboarding/bootstrap-profile.ps1 -H "Accept: application/vnd.github.raw" | Out-File -Encoding utf8 "$env:TEMP\bootstrap-profile.ps1"

& $env:TEMP\bootstrap-profile.ps1 `
    -DevName "Dani" `
    -DevRole "Dev" `
    -BibToken "<bearer-token-recibido>" `
    -GitUserName "Dani" `
    -GitUserEmail "dfuentes@esfericlabs.com" `
    -GitHubUsername "dfuentes-esfericlabs"

# El script:
# 1. Verifica prereqs (git, node, pnpm, pwsh 7+, gh, bash, claude, docker).
# 2. Crea C:\dev\ y clona los 3 repos del equipo.
# 3. Invoca setup-claude-code.ps1 con los params correctos.
# 4. Instala hooks (4 checks) en CreaRack-Pro y CreaRackSL-workspace.
# 5. Muestra guia final con smoke tests.


# SMOKE TEST del lead -----------------------------------------------------

# En la primera sesion con el dev nuevo:
claude mcp list   # debe mostrar: workspace: Connected
claude            # Pregunta: "Ejecuta bib_stats() y dime el resultado"
# Resultado esperado: contadores >3000 nodos

La documentacion completa de onboarding por perfil esta en la wiki del workspace:

• workspace.crearack.com/wiki/workspace/onboarding/onboarding-edu
• workspace.crearack.com/wiki/workspace/onboarding/onboarding-dani
• workspace.crearack.com/wiki/workspace/onboarding/onboarding-txell

Procedimiento 4: Sincronizar perfiles

Cuando: Se ha mejorado el metodo o se han anadido memorias compartidas.

cd C:\dev\CreaRackSL-workspace

# Ver que cambiaria (sin modificar nada)
powershell -ExecutionPolicy Bypass -File C:/dev/claude-method/harness/claude-method-sync.ps1 -DryRun

# Aplicar cambios a todos
powershell -ExecutionPolicy Bypass -File C:/dev/claude-method/harness/claude-method-sync.ps1

# Aplicar solo a un perfil
powershell -ExecutionPolicy Bypass -File C:/dev/claude-method/harness/claude-method-sync.ps1 -Staff "Dani"

Procedimiento 5: Nuevo proyecto con Claude Method

# 1. Copiar CLAUDE.md template
cp C:\dev\claude-method\templates\CLAUDE.md.template mi-proyecto\CLAUDE.md
# Editar: nombre, stack, equipo, comandos

# 2. Instalar el git hook (los checks corren desde claude-method\harness, no se copian)
cd mi-proyecto
bash C:/dev/claude-method/harness/install_hooks.sh

# 3. Copiar fitness tests
cp C:\dev\claude-method\harness\fitness_template.py mi-proyecto\tests\test_architecture_fitness.py

# 4. Crear agentes
mkdir mi-proyecto-workspace\agents\dev
cp C:\dev\claude-method\agents\TEMPLATE.md mi-proyecto-workspace\agents\dev\backend.md

# 5. Onboarding
cp C:\dev\claude-method\onboarding\setup-claude-code.ps1 mi-proyecto-workspace\scripts\

Guia paso a paso: claude-method/guides/QUICK_START.md

Mantenimiento

Frecuencia de actualizacion

Que NO actualizar en claude-method

• Agentes especificos de CreaRack (van en workspace)
• Footguns especificos (pysnmp, CONN_MAX_AGE — van en workspace)
• Features, endpoints, modelos de CreaRack (codigo del producto)
• Contenido de la wiki (especifico del producto)

Verificacion de salud

# Ver estado de memorias de un perfil
cd C:\dev\CreaRack-Pro && claude   # -> /memory

# Ver si el harness funciona
git commit --allow-empty -m "test"  # deberia mostrar [OK] Harness checks passed

# Ver si la Biblioteca responde
# En Claude Code: "ejecuta bib_stats()"

# Ver si sync esta al dia
powershell -ExecutionPolicy Bypass -File C:/dev/claude-method/harness/claude-method-sync.ps1 -DryRun  # deberia decir "nada que sincronizar"

FAQ

P: Si actualizo el metodo, Dani y Txell lo reciben automaticamente? R: Sí, desde la sesión 60 (13-05-2026) — el 4º hook SessionStart ejecuta claude-method-sync.ps1 -SkipHook -SkipMemory automáticamente en cada arranque de sesión Claude Code. Pulea claude-method y propaga global-agents/ + global-skills/ a ~/.claude/. Cierra el Gap 1 del propagador. Excepción: las memorias compartidas (shared-memory/) se siguen propagando manualmente — el sync automático usa -SkipMemory para no pisar memorias locales divergentes. Si añades una memoria nueva genérica, los devs la reciben re-ejecutando setup-claude-code.ps1 o copiándola a mano.

P: Y al revés — si Dani crea un agente local, cómo lo subo al método central? R: Con claude-method-promote.ps1 (s60, cierra Gap 2). Una línea: pwsh C:/dev/claude-method/harness/claude-method-promote.ps1 -Type {agent|skill} -Name <slug>. Detecta CREATE/UPDATE/IDENTICAL, valida frontmatter (name: + description: obligatorios), copia al central + commit + push. Los demás miembros lo reciben en su próxima sesión via el 4º hook. Convención humana: antes de invocar, pregúntate “¿esto es transversal o solo del proyecto?” — si es del proyecto, va en <repo>/.claude/skills/, no en el central.

P: Si Dani tiene una memoria personal que yo no tengo, se borra al sincronizar? R: No. El sync solo copia archivos que existen en shared-memory. Las memorias personales de cada dev no se tocan.

P: Puedo usar claude-method sin workspace? R: Si. Para proyectos pequenos, copia solo CLAUDE.md template + harness. Los agentes y la Biblioteca son opcionales.

P: El repo claude-method necesita su propio CLAUDE.md? R: Si, ya lo tiene. Dice que todo el contenido debe ser generico y sin referencias a proyectos especificos.

P: Que pasa si Dani y yo tenemos memorias que se contradicen? R: Las memorias compartidas (shared-memory) son iguales para todos. Las personales son privadas. Si hay contradiccion, la shared-memory es la fuente de verdad.

Parte 3 — Sprint Supercontexto (Abril 2026)

Este sprint añadió tres capas de “guardarraíles” para que la Biblioteca (el grafo de conocimiento del proyecto) no se desincronice del código.

Fase 1 — Foto en vivo del proyecto

Pagina /biblioteca/pulse en el workspace (https://workspace.crearack.com/biblioteca/pulse) que muestra cada 60 segundos: actividad 24h, salud del grafo, alertas, tareas en vuelo, commits 7 dias, docs desactualizados y bypasses del hook.

Al arrancar cada sesion de Claude Code, un hook SessionStart sincroniza un archivo project_hot_cache.md en la memoria local del dev. Asi Claude entra “caliente” a cada sesion, sabiendo el estado actual sin necesidad de preguntar.

Requisito: variable de usuario BIB_MCP_TOKEN con un Bearer token valido (el setup la guarda automaticamente si pasas -BibToken a setup-claude-code.ps1).

Fase 2 — Cinturon de seguridad antes de commitear codigo

El hook pre-commit ejecuta dos checks:

1. Arquitectural (pre_commit_check.py): LOC, SQL injection, |safe, settings criticos.
2. Biblioteca (bib_report_check.py): si staged incluye archivos de codigo MODIFIED sin bib_report_change previo en los ultimos 10 minutos, bloquea el commit con instrucciones.

Bypass puntual: BIB_SKIP=1 git commit -m "..." + documentar motivo. El bypass queda registrado automaticamente en /biblioteca/pulse (tarjeta “Bypasses BIB_SKIP · 7d”).

Flujo del dia a dia:

1. Editar codigo normalmente.
2. git add <archivos>.
3. Antes de git commit: Claude ejecuta bib_report_change(file_path=..., change_type="modified") por cada archivo tocado.
4. git commit pasa.

Si se te olvida, el hook bloquea con instrucciones claras. No es un castigo, es una red de seguridad.

Fase 3 — Escriba: vigilante diario de docs desactualizados

Un cron diario (GitHub Actions .github/workflows/drift-cron.yml, 04:15 UTC) consulta el endpoint POST /api/biblioteca/drift-run. Calcula que documentos de la Wiki/Documentation estan desactualizados — basado en la regla “si el codigo que el doc documenta fue reportado con bib_report_change despues de la ultima vez que el doc se actualizo, es drift”.

Durante los primeros dias corre en dry-run (variable DRIFT_DRY_RUN=1 en GitHub Actions). Cuando Edu confirma que los falsos positivos son aceptables, se pone a 0 y empieza a generar una alerta rolling en el panel.

Widget “Docs desactualizados” en Pulse muestra total + top 5 con lag en dias y nodos afectados.

Fase 4 — Rollout a Dani y Txell

Ver claude-method/onboarding/lead-checklist.md para los pasos manuales del lead del proyecto antes de invitar a un nuevo dev al sistema (accesos, tokens, secrets, personalizacion del template).

Parte 4 — Sprint Supercontexto (Abril 2026) · Wiki auto-mantenida

El Sprint Supercontexto (abril 2026) evolucionó a un sistema Supercontexto completo en 12 sesiones: wiki que se mantiene sola mediante bibliotecarios latentes (Ingest post-merge + Curator diario + Lint diario + Utility diario) + sistema de continuidad multi-sesion (STATE+LOG+NEXT).

Fases 0-6 del roadmap Supercontexto

Plan ampliado (abril 2026, post-roadmap)

MCP tools wiki (10) añadidos en el sprint

wiki_create_page, wiki_update_page, wiki_archive_page, wiki_log_event, wiki_lint_check, wiki_archive_answer, wiki_curator_review, wiki_lint_bulk, wiki_lint_contradictions, wiki_utility_recompute.

Crons activos en GitHub Actions del workspace (5)

Sistema de continuidad (Regla 19)

Proyectos multi-sesión con alcance grande usan el patrón STATE + LOG + NEXT:

• public/supercontext/STATE.md — estado vivo (fase actual, progreso, bloqueos, decisiones acumuladas).
• public/supercontext/LOG.md — bitácora append-only de cada sesión.
• public/supercontext/briefings/NEXT.md — prompt literal para retomar en la siguiente sesión.

Regla operacional: toda sesión que toque el proyecto multi-sesión lee STATE+NEXT al arrancar y actualiza los 3 al cerrar. El patrón permite trabajar sin perder contexto entre sesiones separadas días.

Scripts clave añadidos

Endpoints clave añadidos al workspace

Véase también

• [[crearack-tech—method—harness-guide]]
• [[crearack-tech—guides—agent-rules]]
• [[ia-tech—metodo—glossary]]