Communitygithub.com

ship-pr

Autorise la création de branches, la mise en scène, les commits, les pushs, la création ou mise à jour de PR et les réponses aux commentaires nécessaires pour préparer une PR à la fusion, sans autoriser la fusion elle-même.

Qu'est-ce que ship-pr ?

Cette compétence (skill) permet à un agent IA de préparer automatiquement une Pull Request (PR) pour fusion, de la création de la branche jusqu'à la demande d'autorisation de fusion finale. Elle est utile pour automatiser les workflows de code review et de CI/CD, en garantissant que seules les PR prêtes (revues, vérifications vertes, commentaires traités) avancent. Elle s'appuie sur des scripts shell et des commandes CLI comme `gh` et est conçue pour fonctionner avec des agents comme Claude Code ou Codex via un worker dédié (`pr_worker`). Le flux inclut la vérification d'une politique spécifique au dépôt, la gestion des commentaires, la surveillance des événements de PR, et la résolution automatique de conflits mécaniques.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add conn-castle/agent-outbox

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait ship-pr ?

Invoquer cette compétence autorise la création de branches, la mise en scène, les commits, les pushs, la création ou mise à jour de PR et les réponses aux commentaires éligibles nécessaires pour préparer une PR à la fusion. Elle n'autorise pas la fusion elle-même.

Si references/repo-specific-pr-policy.md existe, lisez-le avant de démarrer le workflow et traitez-le comme faisant autorité.

Entrées

Nécessite une cible de dispatch pr_worker et utilisez /dispatch-agent pour chaque dispatch. Relayer toute entrée supplémentaire de l'appelant dans chaque invite pr_worker.

Sauf si l'utilisateur réduit la portée, incluez l'intégralité de l'arbre de travail courant.

Workflow

  1. Créez une branche lorsque les normes du dépôt l'exigent. Commitez les modifications prévues, poussez, et créez ou réutilisez la PR. Dérivez son titre des modifications et remplissez assets/pr-body-template.md, en supprimant les sections inutilisées et les espaces réservés.

  2. Démarrez un watcher dans une session d'arrière-plan gérée. Maintenez-le en cours d'exécution jusqu'à ce que la PR soit fusionnée ou que le workflow s'arrête, puis arrêtez-le. S'il se termine après une panne de transport transitoire, récupérez l'état faisant autorité et redémarrez-le avec le même journal d'ajout (append-only).

    bash <skill_dir>/scripts/watch-pr-events.sh \
      --repo <propriétaire/nom> \
      --pr <numéro-pr> \
      --log-file .agent-layer/tmp/ship-pr-events-<numéro-pr>.jsonl \
      --interval-seconds 300
    
  3. Récupérez la tête actuelle, les vérifications et la fusibilité avec gh. Lisez les commentaires avec cette commande sans état ; n'inférez jamais l'état actuel à partir du journal du watcher :

    bash <skill_dir>/scripts/read-pr-comments.sh \
      --repo <propriétaire/nom> \
      --pr <numéro-pr>
    

    Envoyez pr_worker pour les retours non résolus avec la PR, la tête et references/address-pr-comments.md exacts ; pour une vérification obligatoire ayant échoué, fournissez également sa preuve et references/fix-ci.md. Le worker édite l'arbre local mais ne commite, ne pousse ni ne poste de réponses. Résolvez les conflits mécaniques automatiquement.

    La PR est prête à être fusionnée uniquement lorsque :

    • La PR est fusible à sa dernière tête.
    • Au moins un réviseur agent ou humain a posté des retours sous forme de révision formelle ou de commentaire.
    • Chaque vérification obligatoire et porte du dépôt est verte.
    • Chaque commentaire éligible a une réponse validée.
    • Si la politique facultative du dépôt existe, chaque critère de fusion qu'elle définit est rempli.

    Si aucun réviseur agent ou humain ne poste de retours dans les 10 minutes suivant la création de la PR, arrêtez-vous et signalez qu'aucun retour n'a été reçu. Si prêt, passez à l'étape 5. Sinon, traitez la totalité du lot actionnable avant de commiter.

  4. Commitez et poussez les correctifs acceptés. Postez chaque réponse proposée par le worker une par une : répondez nativement aux commentaires en ligne ; pour les commentaires de conversation ou les résumés de révision, postez un commentaire de ticket liant la source. Relancez la commande de commentaire et corrigez toute réponse manquante ou non prise en charge. Revenez à l'étape 3 jusqu'à ce que ce soit prêt. Si seules les vérifications ou les révisions sont en attente, attendez le watcher.

  5. Demandez une autorisation de fusion à usage unique pour la PR et la tête exactes. Signalez toute conclusion substantielle, un résumé concis de la disposition des commentaires et une preuve de l'état de préparation.

  6. Après autorisation, récupérez à nouveau la tête, les vérifications, la fusibilité et les commentaires. Confirmez que l'arbre local est complet et que chaque commentaire éligible a une réponse postée prise en charge. Si quoi que ce soit a changé, revenez à l'étape 3 et obtenez une nouvelle autorisation pour la tête de PR résultante ; sinon, fusionnez.

  7. Confirmez que le checkout est propre, passez à la branche par défaut, avancez-la rapidement et supprimez les branches ou les worktrees créés par ce workflow. Préservez l'état et signalez tout nettoyage qu'il est dangereux d'effectuer.

Skills associés