搭子.skill (Partenaire)

Que fait 搭子.skill (Partenaire) ?

Mon Claude Code et mon Codex sont les meilleurs amis du monde.

Aperçu

Utilisez ce skill pour exécuter un workflow de codage à deux agents : Claude Code est l'agent de planification, de polish et de revue à haute valeur ; Codex est l'orchestrateur externe et le principal implémenteur. Gardez l'utilisation de Claude Code ciblée car il peut être facturé via l'API.

Préférez une session Claude Code de longue durée pour les tâches petites et moyennes : demandez à Claude le plan, laissez Codex l'implémenter, puis renvoyez le résumé du diff et les fichiers clés à la même session Claude pour le polish UI/interaction et la revue finale /codex:review. Cela évite de payer Claude pour reconstruire le même contexte de projet et donne à Claude suffisamment de continuité pour améliorer le travail.

Le Partenaire n'est pas une excuse pour déléguer. L'utilisateur reste le propriétaire, Codex reste responsable des preuves dans le dépôt, et Claude Code est traité comme un collaborateur de grande valeur dont la sortie doit être vérifiée.

Flux par défaut

1. Ancrez-vous dans le dépôt cible.

   • Entrez dans le répertoire concret du projet, pas dans la racine agent-workbench.
   • Exécutez git status --short avant de démarrer Claude Code.
   • Identifiez si la tâche est un nouveau projet, riche en fonctionnalités, riche en UI, une simple revue, ou du débogage.

2. Démarrez une session Claude Code pour la boucle de réflexion coûteuse.

   • Pour la planification : démarrez Claude Code dans un PTY et définissez un objectif.
   • Utilisez claude --permission-mode plan --name <task-name> par défaut.
   • Dans la session interactive, envoyez /goal <condition d'achèvement claire>.
   • Demandez à Claude Code un plan d'implémentation concret, des critères d'acceptation et des conseils UI/interaction.
   • Gardez cette même session ouverte pour les passes de polish et de revue ultérieures lorsque la tâche n'est pas trop importante.
   • Ne démarrez pas une session de revue claude -p séparée simplement parce que Codex a terminé l'implémentation. Cela dépense des tokens pour un contexte à froid et affaiblit la continuité de Claude.

3. Implémentez principalement avec Codex.

   • Convertissez le plan de Claude Code en une courte liste de contrôle.
   • Effectuez les modifications de code directement dans Codex, en utilisant les motifs existants du dépôt.
   • Exécutez la vérification la plus rapide et pertinente après les modifications risquées.
   • Tenez Claude Code à l'écart des modifications mécaniques en masse, des corrections de lint répétitives et des longues boucles de commandes, sauf si l'utilisateur le demande.

4. Renvoyez l'état implémenté à la même session Claude Code pour le polish.

   • Utilisez cela particulièrement pour l'UI frontend, la qualité de l'interaction, le ressenti du produit, l'accessibilité et les états limites.
   • Envoyez une charge utile délimitée. Utilisez references/handoff-template.md si possible : le plan original, la liste des fichiers modifiés, git diff --stat, la sortie des tests/vérifications, les risques, les questions ouvertes, et seulement les extraits de fichiers clés ou les fichiers complets dont Claude a besoin.
   • Demandez des résultats priorisés, pas des réécritures générales.
   • Codex applique les correctifs acceptés et relance les vérifications.

5. Effectuez la revue finale à partir de la même session Claude Code.

   • Dans Claude Code, utilisez /codex:review lorsque disponible.
   • Traitez les résultats comme des problèmes de bug/risque/test d'abord, les suggestions de style ensuite.
   • Codex corrige les résultats bloquants, relance les vérifications et rapporte l'état final.
   • Terminez par un Reçu de Session Partenaire afin que l'utilisateur puisse vérifier si le contexte de Claude Code a été réutilisé.

Stratégie de session

• Tâche petite ou moyenne : gardez une session Claude Code ouverte pour plan -> polish -> /codex:review.
• Considérez une nouvelle session Claude Code comme coûteuse. N'en ouvrez une que lorsqu'il n'y a pas de session réutilisable, que la session précédente est irrécupérable, ou que l'utilisateur demande explicitement une nouvelle passe Claude.
• Si la même session Claude reste bloquée sur une invite, une attente d'autorisation ou un état inactif, essayez d'abord de continuer ou de reprendre la même session avec un message délimité. Ne démarrez pas une revue de remplacement à froid à moins que la valeur ne dépasse clairement le coût du contexte.
• Tâche volumineuse ou diff énorme : divisez les sessions seulement après que Codex produit un transfert compact contenant le plan, les fichiers modifiés, les décisions clés, les risques connus et les résultats des vérifications.
• Si la même session Claude devient lente, confuse ou lourde en contexte, fermez-la et redémarrez avec un transfert délimité seulement après avoir signalé le compromis sur les tokens.
• Ne sautez pas la phase de polish Claude pour le travail UI/frontend, sauf si l'utilisateur demande explicitement une boucle minimale plus rapide.
• Si /codex:review se bloque, expire ou reste coincé dans une invite d'autorisation, enregistrez cela comme un résultat de surveillance, arrêtez le sous-processus/session bloqué, et continuez avec une vérification côté Codex.
• Si Claude Code ne produit aucun polish exploitable, ne continuez pas à l'inviter aveuglément. Capturez le résultat vide/faible, exécutez la vérification Codex et signalez la limitation.
• claude -p n'est pas le chemin Partenaire par défaut. Utilisez-le uniquement pour des questions ponctuelles bon marché où la perte de contexte de la session précédente est acceptable.

Politique de permissions

• Par défaut, utilisez --permission-mode plan pour la planification et des permissions normales pour la revue d'implémentation.
• Utilisez le mode skip/bypass uniquement lorsque l'utilisateur demande explicitement skip, 最高权限, 全部允许, bypass, ou lorsque le travail se trouve dans un arbre de travail intentionnellement isolé.
• Pour le mode skip, démarrez Claude Code avec claude --permission-mode bypassPermissions --name <task-name> ou claude --dangerously-skip-permissions --name <task-name>.
• Avant toute session skip, indiquez le chemin du dépôt, le statut git actuel, la portée visée et la condition d'arrêt.
• Ne laissez jamais le mode skip commiter, pousser, déployer, envoyer des messages, publier ou toucher aux secrets, sauf si l'utilisateur donne une instruction explicite distincte.
• Ne traitez jamais skip comme une permission d'ignorer les preuves du dépôt. skip modifie les permissions de Claude Code, pas le devoir de vérification du Partenaire.
• Gardez les modifications de visibilité du dépôt, les tags de release, la publication dans un registre et les annonces externes derrière une instruction de publication explicite distincte.

Règles d'acheminement

• Acheminez vers Claude Code : planification architecturale, stratégie d'implémentation, critique UI/interaction, revue finale Codex, compromis produits difficiles.
• Acheminez vers Codex : échafaudage, implémentation, modifications de code long contexte, tests, correctifs de build, inspection de dépôt, surveillance, résumés.
• Re-acheminer vers la même session Claude Code lorsque la qualité UI compte ou que la première implémentation passe techniquement mais a encore besoin de polish produit.
• Gardez Kimi Work/Kimi Code Goal séparé de /goal de Claude ; le précédent contexte "Goal mode" peut faire référence à Kimi, pas à Claude.

Porte de validation

Utilisez le cliquet de style Darwin dans references/darwin-ratchet.md lorsque vous améliorez ce workflow ou l'appliquez à une tâche substantielle :

• Modifiez une dimension du workflow à la fois : planification, implémentation, polish UI, revue, surveillance, permissions ou rapports.
• Exécutez des invites de test ou une mini-boucle réelle avant de déclarer une amélioration meilleure.
• Ne laissez pas le même agent être le seul créateur et le seul juge pour les modifications à haut risque.
• Ne conservez le changement que lorsque les preuves du dépôt s'améliorent. Si cela régresse, utilisez un revert révisable, pas git reset --hard.
• Arrêtez-vous lorsqu'une autre boucle d'invite produit un faible signal ou une amélioration attendue <1 point.

Surveillance

Pour les sessions Claude Code actives, lisez references/monitoring.md. Préférez cinq signaux plutôt que de vous fier uniquement au texte du chat :

1. Sortie PTY de la session Claude Code en cours.
2. Statut de session claude agents --json --cwd <repo>.
3. Structure du transcript JSONL de Claude, sans vider les corps de messages complets par défaut.
4. Fichiers de tâches optionnels sous ~/.claude/tasks/<sessionId>/.
5. Preuves du dépôt : git status --short, git diff --stat, et les vérifications de test/build pertinentes.

Contrat de sortie

Lorsque vous faites un rapport à l'utilisateur, incluez :

• Phase actuelle : planification, implémentation Codex, polish Claude, revue ou correctif final.
• Identifiant de session Claude Code lorsqu'il existe.
• Fichiers modifiés et vérifications exécutées.
• Résultats de la revue corrigés ou encore ouverts.
• Si le travail est prêt à être commité ; ne commitez pas par défaut.
• Toute anomalie de surveillance telle que session inactive, attente d'autorisation, sortie de revue vide, aucun diff ou vérification échouée.
• Un Reçu de Session Partenaire pour les workflows Claude Code non triviaux :

[Reçu de session partenaire]
phase: <planification | implémentation codex | polish claude | revue | correctif final>
claude_session: <sessionId ou aucun>
claude_session_reused: <oui | non | s.o.>
new_claude_p_sessions: <0 | nombre | inconnu>
codex_passes: <nombre de passes d'implémentation/correction>
checks: <commandes exécutées ou non>
anomalies: <aucune | attente autorisation | inactif | revue vide | échec vérification | autre>

N'inventez pas d'économies de tokens. Lorsque la télémétrie exacte des tokens n'est pas disponible, rapportez un comportement vérifiable à la place : même session Claude Code réutilisée, aucune nouvelle session claude -p fraîche, transfert délimité utilisé, vérifications réussies.