搭子.skill / Partner

¿Qué hace Partner?

Mi Claude Code y Codex son los mejores del mundo.

Resumen

Usa este skill para ejecutar un flujo de trabajo de codificación con dos agentes: Claude Code es el agente de planificación, pulido y revisión de alto valor; Codex es el orquestador externo y el implementador principal. Mantén el uso de Claude Code enfocado, ya que puede facturarse a través de la API.

Prefiere una sola sesión larga de Claude Code para tareas pequeñas y medianas: pídele a Claude el plan, deja que Codex lo implemente, y luego devuelve el resumen del diff y los archivos clave a la misma sesión de Claude para el pulido de UI/interacción y la revisión final con /codex:review. Esto evita pagar a Claude para reconstruir el mismo contexto del proyecto y le da a Claude la continuidad suficiente para mejorar el trabajo.

Partner no es una excusa para delegar. El usuario sigue siendo el dueño, Codex sigue siendo responsable de la evidencia en el repositorio, y Claude Code es tratado como un colaborador de alto valor cuyo resultado debe ser verificado.

Flujo predeterminado

1. Fijarse en el repositorio objetivo.

   • Entra en el directorio concreto del proyecto, no en la raíz de agent-workbench.
   • Ejecuta git status --short antes de iniciar Claude Code.
   • Identifica si la tarea es desde cero, pesada en funcionalidades, pesada en UI, solo de revisión, o de depuración.

2. Iniciar una sesión de Claude Code para el bucle de pensamiento costoso.

   • Para planificación: inicia Claude Code en una PTY y establece un objetivo.
   • Usa claude --permission-mode plan --name <nombre-de-tarea> por defecto.
   • En la sesión interactiva, envía /goal <condición de finalización clara>.
   • Pídele a Claude Code un plan de implementación concreto, criterios de aceptación y guía de UI/interacción.
   • Mantén esta misma sesión abierta para las pasadas posteriores de pulido y revisión cuando la tarea no sea demasiado grande.
   • No inicies una sesión separada solo de revisión con claude -p solo porque Codex ha terminado la implementación. Eso gasta tokens en un contexto de inicio en frío y debilita la continuidad de Claude.

3. Implementar principalmente con Codex.

   • Convierte el plan de Claude Code en una lista de verificación corta.
   • Realiza los cambios de código directamente en Codex, usando los patrones existentes del repositorio.
   • Ejecuta la verificación relevante más rápida después de ediciones riesgosas.
   • Mantén a Claude Code fuera de ediciones mecánicas masivas, correcciones de lint repetitivas y bucles largos de comandos, a menos que el usuario lo solicite.

4. Devolver el estado implementado a la misma sesión de Claude Code para pulido.

   • Usa esto especialmente para UI de frontend, calidad de interacción, sensación del producto, accesibilidad y estados límite.
   • Envía un payload acotado. Usa references/handoff-template.md cuando sea posible: el plan original, la lista de archivos cambiados, git diff --stat, la salida de pruebas/verificaciones, riesgos, preguntas abiertas, y solo los fragmentos de archivos clave o archivos completos que Claude necesite.
   • Solicita hallazgos priorizados, no reescrituras amplias.
   • Codex aplica las correcciones aceptadas y vuelve a ejecutar las verificaciones.

5. Ejecutar la revisión final desde la misma sesión de Claude Code.

   • En Claude Code, usa /codex:review cuando esté disponible.
   • Trata los hallazgos primero como problemas de error/riesgo/prueba, y segundo como sugerencias de estilo.
   • Codex corrige los hallazgos bloqueantes, vuelve a ejecutar verificaciones e informa el estado final.
   • Termina con un Recibo de Sesión del Partner para que el usuario pueda verificar si el contexto de Claude Code fue reutilizado.

Estrategia de sesión

• Tarea pequeña o mediana: mantén una sesión de Claude Code abierta para plan -> pulido -> /codex:review.
• Trata una nueva sesión de Claude Code como costosa. Ábrela solo cuando no haya una sesión reutilizable, la sesión anterior sea irrecuperable, o el usuario solicite explícitamente una pasada nueva de Claude.
• Si la misma sesión de Claude se queda atascada en un mensaje, espera de permisos o estado inactivo, primero intenta continuar o reanudar la misma sesión con un mensaje acotado. No inicies en frío una revisión de reemplazo a menos que el valor supere claramente el costo del contexto.
• Tarea grande o diff enorme: divide las sesiones solo después de que Codex produzca una transferencia compacta que contenga el plan, los archivos cambiados, las decisiones clave, los riesgos conocidos y los resultados de las verificaciones.
• Si la misma sesión de Claude se vuelve lenta, confusa o con mucho contexto, ciérrala y reinicia con una transferencia acotada solo después de informar la compensación de tokens.
• No te saltes la fase de pulido de Claude para trabajo de UI/frontend a menos que el usuario solicite explícitamente un bucle mínimo más rápido.
• Si /codex:review se cuelga, agota el tiempo de espera o se queda atascado en un mensaje de permisos, registra eso como un hallazgo de monitoreo, detén el subproceso/sesión atascado y continúa con la verificación del lado de Codex.
• Si Claude Code no produce pulido procesable, no sigas preguntándole a ciegas. Captura el resultado vacío/de baja señal, ejecuta la verificación de Codex e informa la limitación.
• claude -p no es la ruta predeterminada de Partner. Úsalo solo para preguntas puntuales baratas donde perder el contexto de la sesión anterior sea aceptable.

Política de permisos

• Por defecto, usa --permission-mode plan para planificación y permisos normales para revisión de implementación.
• Usa omisión/salto solo cuando el usuario solicite explícitamente skip, 最高权限, 全部允许, bypass, o cuando el trabajo esté dentro de un worktree intencionalmente aislado.
• Para el modo de omisión, inicia Claude Code con claude --permission-mode bypassPermissions --name <nombre-de-tarea> o claude --dangerously-skip-permissions --name <nombre-de-tarea>.
• Antes de cualquier sesión con omisión, indica la ruta del repositorio, el estado actual de git, el alcance previsto y la condición de parada.
• Nunca permitas que el modo de omisión haga commit, push, despliegue, envíe mensajes, publique o toque secretos a menos que el usuario dé una instrucción explícita separada.
• Nunca trates skip como permiso para ignorar la evidencia del repositorio. skip cambia los permisos de Claude Code, no el deber de verificación de Partner.
• Mantén los cambios de visibilidad del repositorio, etiquetas de versión, publicación en registros y anuncios externos detrás de una instrucción de publicación explícita separada.

Reglas de enrutamiento

• Enrutar a Claude Code: planificación de arquitectura, estrategia de implementación, crítica de UI/interacción, Revisión final de Codex, compensaciones difíciles del producto.
• Enrutar a Codex: scaffolding, implementación, ediciones de código de contexto largo, pruebas, correcciones de compilación, inspección del repositorio, monitoreo, resúmenes.
• Enrutar de vuelta a la misma sesión de Claude Code cuando la calidad de la UI importe o la primera implementación pase técnicamente pero aún necesite pulido del producto.
• Mantén Kimi Work/Kimi Code Goal separado de /goal de Claude; el contexto anterior del "Modo Goal" puede referirse a Kimi, no a Claude.

Puerta de validación

Usa la trinqueta estilo Darwin en references/darwin-ratchet.md al mejorar este flujo de trabajo o aplicarlo a una tarea sustancial:

• Cambia una dimensión del flujo de trabajo a la vez: planificación, implementación, pulido de UI, revisión, monitoreo, permisos o informes.
• Ejecuta mensajes de prueba o un bucle mínimo real antes de considerar una mejora como mejor.
• No permitas que el mismo agente sea el único creador y el único juez para cambios de alto riesgo.
• Mantén el cambio solo cuando la evidencia del repositorio mejore. Si empeora, usa una reversión revisable, no git reset --hard.
• Detente cuando otro bucle de mensajes produzca baja señal o <1 punto de mejora esperada.

Monitoreo

Para sesiones activas de Claude Code, lee references/monitoring.md. Prefiere cinco señales en lugar de confiar solo en el texto del chat:

1. Salida PTY de la sesión de Claude Code en ejecución.
2. Estado de la sesión con claude agents --json --cwd <repo>.
3. Estructura de la transcripción JSONL de Claude, sin volcar los cuerpos completos de los mensajes por defecto.
4. Archivos de tarea opcionales bajo ~/.claude/tasks/<sessionId>/.
5. Evidencia del repositorio: git status --short, git diff --stat y verificaciones de pruebas/compilación relevantes.

Contrato de salida

Al informar de vuelta al usuario, incluye:

• Fase actual: planificación, implementación de Codex, pulido de Claude, revisión o corrección final.
• ID de sesión de Claude Code cuando exista.
• Archivos cambiados y verificaciones ejecutadas.
• Hallazgos de revisión corregidos o aún abiertos.
• Si el trabajo está listo para commit; no hagas commit por defecto.
• Cualquier anomalía de monitoreo como sesión inactiva, espera de permisos, salida de revisión vacía, ningún diff o verificación fallida.
• Un Recibo de Sesión del Partner para flujos de trabajo no triviales de Claude Code:

[Recibo de sesión del Partner]
fase: <planificación | implementación codex | pulido claude | revisión | corrección final>
claude_sesion: <sessionId o ninguno>
claude_sesion_reutilizada: <sí | no | n/d>
nuevas_sesiones_claude_p: <0 | cantidad | desconocido>
pasadas_codex: <número de pasadas de implementación/corrección>
verificaciones: <comandos ejecutados o no ejecutados>
anomalías: <ninguna | espera de permisos | inactividad | revisión vacía | verificación fallida | otra>

No fabriques ahorros de tokens. Cuando la telemetría exacta de tokens no esté disponible, informa el comportamiento verificable en su lugar: misma sesión de Claude Code reutilizada, ninguna sesión nueva de claude -p, transferencia acotada utilizada, verificaciones pasadas.