z-scripts-karpathy-suite

Plugin z-scripts-karpathy-suite from marketplace z-scripts-karpathy in FDL32/orquestador-de-agentes. Commands read from the repo's manifest — yesterday.

Skills (49)

• adopt-existing-project

  Adecuar un proyecto Python YA EXISTENTE (legacy o con motor viejo embebido) al motor portable, orquestando las skills y scripts existentes en el orden correcto. Usar cuando se incorpora un repo con codigo previo como repo_destino. No usar para un destino nuevo o limpio (ver setup-agent-system) ni pa

• audit-autonomous-ticket-batch

  Auditoria aislada (contexto fresco, solo lectura) de un batch autonomo de tickets ya cerrado o parado, que re-deriva el PREDICATE de 9 condiciones comando a comando, audita las paradas y la recuperacion del ejecutor y propone, sin ejecutarlo, el cierre de sesion. Usar cuando un batch de orchestrate-

• audit-git-publication

  Auditoria dry-run de si un repo_destino puede publicarse en Git sin secretos, PII, artefactos privados ni deuda sin decision, con classify_publication.py y doble pasada de verificacion y refutacion. Usar cuando se prepara la primera publicacion de un repo_destino o una revision de su exposicion. No

• audit-pipeline-codeonly

  Meta-auditoria de una cadena de tickets del motor cerrada en CODE-ONLY MODE (worktree _dev, cierre commit-directo sin bus), con evidencia por commits y bloques de cierre del workspace, aterrizaje en origin/main y costuras entre tickets. Usar cuando termina una cadena ejecutada con orchestrate-pipeli

• audit-pipeline

  Meta-auditoria retrospectiva de un pipeline multi-ticket ya cerrado en un repo_destino con bus, que re-deriva cada closeout desde git, tests y bus en doble pasada A/B y emite informe y decision artifact. Usar cuando el pipeline de un repo_destino ha cerrado y ya no quedan tickets ejecutables. No usa

• backlog-admit

  Alta de un ticket nuevo como fila de backlog.md con el recibo mecanico BACKLOG-ADMISSION-RECIBO que emite backlog_db_compare.py y contrasta check_backlog_admission.py. Usar cuando el PASO 0 del protocolo de hallazgos decide que la senal merece una fila nueva, antes de commitear el alta. No usar para

• backlog-triage

  Planificador pre-pipeline de solo lectura que reconcilia el backlog con git, clasifica la aptitud de cada ticket, propone un DAG de grupos y recomienda por cual empezar; solo escribe su informe y su JSON. Usar cuando hay que decidir que pipeline o batch autonomo lanzar sobre el backlog vivo. No usar

• builder-implement-from-plan

  Implementa en orden las tareas de un work_plan aprobado como rol builder, bajo el contrato de ejecucion de orchestrator_launch_builder (identidad y paridad del contrato, preflight, tests, gates focales, commit segun delivery_authority y handoff canonico al Manager). Usar cuando el controlador indica

• builder-run-quality-gates

  Ejecutar los quality gates que corresponden al deliverable_type del work_plan activo mediante run_gates_dispatch.py. Usar cuando el Builder termino un cambio sustancial y necesita validarlo antes de pedir review. No usar para autorizar el handoff, porque un exit 0 no autoriza BUILDER_EXIT ni READY_F

• builder-self-audit

  Auditoria obligatoria del Builder antes de reportar una tarea como completada, que cubre tipo de archivo, completitud multi-archivo, regresion y gates globales. Usar cuando el Builder va a declarar terminada su entrega. No usar para ejecutar solo los gates (ver builder-run-quality-gates) ni para la

• builder-write-deliverable

  Generar un deliverable markdown (no codigo) a partir de su descripcion, output_path y acceptance criteria del work_plan. Usar cuando el ticket es documental y el ciclo no debe invocar ruff ni pytest. No usar para implementar codigo (ver builder-implement-from-plan).

• code-audit

  Auditoria sistematica de codigo Python que detecta dead code, deuda tecnica y archivos inactivos con vulture, deadcode, ruff y git log. Usar cuando se quiere un censo de codigo muerto o deuda antes de limpiar o refactorizar. No usar para auditar la suite de tests (ver test-audit) ni para revisar el

• create-agent-skill

  Meta-skill para crear una micro-skill nueva siguiendo el estandar Agent Skills (frontmatter validado, triggers, workflow). Usar cuando se necesita una skill nueva para una accion concreta y repetible. No usar para editar a mano una skill existente ni para un contrato de gobierno (los prompts de prom

• deep-research

  Produce por escrito el contexto estructurado previo a un work_plan (estado actual, gaps de conocimiento, alternativas). Usar cuando el Manager o el usuario pide investigar antes de planificar un WP complejo. No usar para un WP que ya tiene work_plan aprobado (ver builder-implement-from-plan) ni para

• doc-optimization

  Protocolo medir, mover y verificar para trasladar contenido de un fichero siempre-cargado (CLAUDE.md, AGENTS.md y sus @imports) a una referencia, con guard de no-degradacion de sus consumidores. Usar cuando el cierre transitivo de lo siempre-cargado supera alguno de los gates absolutos por-backend d

• escalate-to-motor

  Contrato de redaccion de un escalado destino a motor como ficha FP en el buzon backlog_inbox del WORKSPACE DEL MOTOR, con recibo reejecutable, procedencia por claim y condicion de rechazo declarada. Usar cuando un repo_destino detecta un defecto, deuda o propuesta que pertenece al motor y no al dest

• graphify

  Construye un grafo de conocimiento persistente del codebase para explorarlo con poco consumo de tokens. Usar cuando el proyecto supera 30 ficheros fuente o 5.000 palabras, o es la segunda sesion sobre el mismo codigo. No usar para proyectos pequenos donde leer los ficheros sale mas barato; si el gra

• grill-work-plan

  Interroga una peticion ambigua, una pregunta a la vez y con respuesta recomendada, para fijar la terminologia antes de crear el work_plan. Usar cuando el requisito del usuario tiene terminos difusos que cambiarian el plan. No usar para un requisito que ya es preciso (ver manager-create-work-plan).

• local-audit

  Genera un snapshot rapido y estructurado del estado del repositorio (version, estado del agente, salud, skills) con scripts/local_audit.py. Usar cuando arranca una sesion o antes de comparar con otro repositorio. No usar para auditar la salud del sistema tras un cambio (ver system-health-audit) ni p

• manager-create-work-plan

  Crea el work_plan estructurado que ejecutara el Builder, con fases, tareas, riesgos y criterios de aceptacion medibles. Usar cuando el usuario pide una funcionalidad o un cambio y el Manager debe formar el contrato. No usar para revisar una entrega (ver manager-review-implementation) ni si el requis

• manager-orchestrator-loop

  Skill minima que apunta al nucleo del proceso Manager-Builder por contract_id y sha256, SIN herramienta. Usar cuando un Manager necesita orquestar un objetivo con bucles de revision adversarial sobre una estrategia, sobre cada plan y sobre el prompt del ejecutor, en CUALQUIER sistema. No usar para d

• manager-resolve-escalation

  Resuelve un bloqueo o una escalacion del Builder con una decision documentada, clasificando el bloqueo y comparando opciones con sus trade-offs. Usar cuando el Builder queda BLOCKED dentro del ticket. No usar para escalar al motor un hallazgo detectado desde un destino (ver escalate-to-motor).

• manager-review-implementation

  Revisar cambios de codigo contra arquitectura del proyecto. Usar cuando el Builder entrega una implementacion (fase MANAGER_REVIEW de un ticket). No usar para cerrar tickets de Contract Formation en status frozen (ver validate_contract_formation.py) ni para auditar el contrato antes del Builder (ver

• manager-session-closeout

  Cierre de sesion del Manager que propone learnings, los clasifica como local, generalizable o dudoso y prepara el puente de mejora continua hacia el motor. Usar cuando termina un WP o una sesion relevante y hay que capturar lo aprendido con validacion humana. No usar para cerrar un proyecto entero (

• memory-consolidate

  Consolida de forma determinista observations.jsonl, deduplicando, filtrando ruido y archivando entradas antiguas, sin LLM ni cron. Usar cuando se cierra la sesion tras session_close_observations o cuando observations.jsonl ha crecido mucho. No usar para escribir observaciones nuevas (ver session-clo

• orchestrate-autonomous-ticket-batch

  Ejecutor autonomo que consume el DAG de backlog-triage y cierra el maximo de tickets con barreras duras por ticket, delegando cada uno en el pipeline canonico del modo detectado; crea commits, mueve filas al archivo, escribe bus, ledger y memoria, puede publicar con push y nunca se audita a si mismo

• orchestrate-destination-batch

  Orquesta en un lote secuencial varios repo_destino hasta un estado de publicacion explicito, uno a uno, clasificandolos con batch_destination_controller.py, conduciendo Contract Formation y el pipeline por ticket con los prompts canonicos y dejando un manifest global reanudable. Usar cuando hay que

• orchestrate-pipeline-codeonly

  Pipeline multi-ticket del motor en CODE-ONLY MODE que muta codigo en la worktree _dev, con work_plan, STRATEGY y AUDIT por ticket, dos revisiones (la segunda en contexto fresco) y cierre por commit directo sin bus. Usar cuando el ticket tiene delivery_authority repo_motor, se trabaja en la worktree

• orchestrate-pipeline

  Coordinar por chat un pipeline multi-ticket en repo_destino usando Manager, Builder, reviews y cierre canonico. Usar cuando se orquesta el pipeline por-ticket en modo destino con bus vivo (bootstrap -> builder -> review -> cierre por bus). No usar para el modo motor code-only (ver orchestrator_pipel

• project-finalize

  Cierre profesional de un proyecto o fase importante con auditoria, limpieza, documentacion, versionado y verificacion final. Usar cuando el usuario pide dejar el repo listo para entrega, handoff o mantenimiento. No usar para cerrar una sesion de trabajo (ver manager-session-closeout) ni para publica

• refactor-manager

  Dirige una refactorizacion segura de codigo Python en 5 fases (analisis, plan, refactor, validacion, iteracion) con los cambios aprobados antes de ejecutarse. Usar cuando hay que reestructurar codigo sin cambiar su comportamiento. No usar para un fix puntual (ver systematic-debugging) ni para una fu

• repo-compare

  Compara el proyecto local con un repositorio de GitHub para detectar funcionalidades portables de alto valor, partiendo de AUDIT.md como contexto local. Usar cuando recibes una URL de GitHub y quieres saber que merece adoptarse. No usar para evaluar el propio repo (ver local-audit) ni sin un repo co

• scaffold-python-project

  Crea la estructura completa de un proyecto Python nuevo con seguridad integrada. Usar cuando se arranca un proyecto desde cero. No usar para un proyecto que ya existe (ver adopt-existing-project o secure-existing-project).

• secure-existing-project

  Aplica la arquitectura de seguridad privada/publica a un proyecto Python existente con credenciales expuestas (fallback por convencion, no la solucion final). Usar cuando un proyecto ya existente guarda secretos en el arbol. No usar para un proyecto nuevo (ver scaffold-python-project) ni cuando keyr

• session-close-full-audit

  Auditoria adversarial previa al cierre canonico de una sesion, que encadena tres auditorias de salud y una pasada adversarial sobre el codigo generado; el cierre lo ejecuta agent_controller.py --session-close y en modo FINAL tambien registra follow-ups y propone memoria. Usar cuando se cierra una se

• session-close-observations

  Genera observaciones curadas al final de una sesion para la memoria auto-mejorable, que luego se filtran y pueden promoverse a observations.jsonl. Usar cuando se completa un WP, se cierra una sesion larga o se descubre un patron o una decision arquitectonica. No usar para consolidar la memoria (ver

• setup-agent-system

  Instalar o sincronizar un repo_destino para usar el motor externo orquestador_de_agentes con link portable, perfil host-project y preflight verificable. Usar cuando se instala el sistema en un destino nuevo, se sincroniza uno ya instalado, o se verifica su enlace al motor. No usar para un proyecto Y

• suite-optimization

  Juez que lee la evidencia de run_history.jsonl y propone, o aplica, UN piloto de optimizacion de la suite del motor sin relajar asserts ni tocar barreras git reales (salvo una mejora de fixture demostrablemente segura), distinguiendo coste eliminable de coste re-atribuido. Usar cuando la suite canon

• system-health-audit

  Auditoria periodica de salud de las tres capas (repo_motor, repo_destino e integracion) tras cambios, con un recolector determinista que junta la evidencia y el agente que la audita en solo lectura. Usar cuando hubo cambios en el motor o en un repo_destino y hay que saber si el sistema sigue sano de

• systematic-debugging

  Proceso riguroso de cuatro fases para diagnosticar y corregir errores, priorizando la investigación de causa raíz y limitando los intentos iterativos ciegos a un umbral estricto. Usar cuando un error no es trivial y la causa no es obvia a primera vista. No usar para typos o fallos de linter (corrige

• test-audit

  Audita la suite de tests para hallar cobertura de bajo valor, acoplamiento a la implementacion y tests duplicados sin bajar la confianza real. Usar cuando la suite es lenta o sospechas de tests cosmeticos. No usar para borrar tests que fallan en la baseline (puede ser un bug de producto) ni para aud

• test-driven-development

  Metodologia Red/Green/Refactor que escribe el test primero, el codigo minimo despues y refactoriza, para cumplir los requisitos sin regresiones. Usar cuando se implementa logica nueva o se corrige un bug determinista reproducible. No usar para PoC exploratorios, tareas solo documentales ni refactors

• version-changelog

  Gestiona versiones semanticas y CHANGELOG.md siguiendo Keep a Changelog y SemVer 2.0 (bump, entrada y etiqueta git). Usar cuando se cierra una fase del work_plan o antes de publicar o entregar. No usar para el cierre completo del proyecto (ver project-finalize).

• agent-execution-mode

  Skill minima que apunta al nucleo de los 3 modos de ejecucion multiagente (Tradicional, 4 capas, Intermedio) por contract_id y sha256, SIN herramienta. Usar al arrancar una sesion que orqueste trabajo sobre tickets del backlog, o para cambiar de modo en caliente a mitad de conversacion. No usar para

• agents-md-intake-triage

  Protocolo de admision que un agente corre ANTES de anadir contenido nuevo a AGENTS.md o CLAUDE.md (motor o repo_destino): barrido anti-duplicado sobre las superficies de documentacion, clasificacion por funcion y clase, regla de aterrizaje (ninguna adicion entra directa a la cuspide) y gate de presu

• orchestrate-child-dispatch-multiticket-multibackend-unlimited

  Gobierno EXPERIMENTAL que anade al ejecutor autonomo el dispatch real padre/hijo por ticket (Capa 0 -> Manager-hijo -> Builder/Revisor) sobre MAS DE UN backend (Claude Code, Kilo, OpenCode), con lock sostenido del SO anti split-brain, registro de identidad Builder!=Revisor verificable por transporte

• repo-audit

  Auditoria multifase multiagente de un repo (dead code, legacy, seguridad, proceso) con bucle adversarial de verificacion antes de proponer limpieza. Usar cuando el repo ha crecido y hace falta un censo repetible antes de limpiar/refactorizar a escala. No usar para un solo archivo ya identificado (ve

• revisor-independent-review

  Revision adversarial independiente del trabajo del Builder. Usar para Persona-2 (Revisor): el Revisor revisa con su propio modelo, nunca el mismo que el Builder. Triggers: /revisor-review, /verify.

• session-hop

Similar plugins