Maison

Skill

Git et contrôle de version

yeet

paulrberg/agent-skills

Utilisé pour les workflows GitHub PR/problème/discussion : créer/mettre à jour des PR ou des problèmes, publier des commentaires, lancer des discussions ; les déclencheurs incluent yeet.

...Développer tout

Heure mise à jour 26 août 2026

# automation # github # git # open-source # pull-requests # Git & Version ControlProductivity & Workflow # issues

À propos de yeet

yeet facilite les workflows de contribution au code source basés sur GitHub, en couvrant la création et la mise à jour de demandes de pull et d’issues, l’ajout de commentaires ainsi que le lancement de discussions. Son principe directeur est l’analyse sémantique plutôt que l’opération mécanique : il vise à comprendre l’intention et le contexte d’une modification avant de générer un titre, une description ou de choisir un modèle, tout en maintenant un ton conversationnel et informel dans tout le contenu généré.

Cette compétence couvre un ensemble de workflows distincts, chacun documenté dans son propre fichier de référence chargé en fonction des intentions de l’utilisateur. Cela inclut la création et la mise à jour de demandes de pull, la création et la mise à jour d’issues (avec des références spécifiques pour signaler des bugs concernant Claude Code, Codex CLI et Sablier), l’ajout de commentaires sur les issues ainsi que la création de discussions. Des schémas communs tels que la validation de l’authentification, les avertissements, la syntaxe HEREDOC, l’analyse sémantique, le ton à adopter, la normalisation des plateformes, la gestion des erreurs et les liens vers des fichiers sont regroupés dans un fichier de référence commun.

Avant d’agir, yeet valide les prérequis. La première commande gh en lecture seule requise dans chaque workflow sert également à valider l’authentification, et il privilégie un outil d’aide scripts/yeet-context.sh pour recueillir des informations sur le répertoire, les modèles, les discussions, les étiquettes ou le contexte d’une issue/demande de pull. Les workflows liés aux demandes de pull comportent des prérequis supplémentaires : l’arbre de travail doit être propre ou les modifications doivent avoir été commitées, la branche actuelle doit contenir des commits antérieurs à ceux de la branche de base, et le suivi distant doit être configuré.

Utilisez-le lorsque vous contribuez à des répertoires GitHub et que vous souhaitez des demandes de pull, des issues, des commentaires ou des discussions bien rédigés et adaptés au contexte, plutôt que du texte générique. Il est déclenché par des expressions telles que « créer une demande de pull », « ouvrir une demande de pull », « envoyer une demande de pull via yeet », « signaler un problème », « commenter sur un problème » ou « lancer une discussion ». Pour des informations détaillées sur la syntaxe, les paramètres et les schémas des commandes GitHub CLI, il fait appel à la compétence cli-gh associée, se concentrant lui-même sur l’orchestration des workflows et la génération de contenu sémantique.

FAQ

Quels workflows GitHub yeet prend-il en charge ?

La création et la mise à jour de demandes de pull et d’issues, l’ajout de commentaires sur les issues ainsi que la création de discussions, en plus de références spécifiques pour signaler des problèmes concernant Claude Code, Codex CLI et Sablier.

Quel est le contrôle effectué avant d’ouvrir une demande de pull ?

Vérification que l’arbre de travail est propre ou que les modifications ont été commitées, que la branche actuelle contient des commits antérieurs à ceux de la branche de base, et que le suivi distant est bien configuré.

Comment se connecte-t-il à GitHub ?

Il utilise la première commande gh en lecture seule requise dans chaque workflow pour valider l’authentification, sans nécessiter d’étape de connexion distincte.

Qu’est-ce qui rend le contenu généré par yeet particulier ?

Il met l’accent sur l’analyse sémantique, en comprenant l’intention et le contexte d’une modification avant d’écrire des titres ou des descriptions, tout en maintenant un ton conversationnel et informel dans tous les résultats.

Gère-t-il lui-même la syntaxe détaillée des commandes GitHub CLI ?

Non. Pour des informations détaillées sur la syntaxe, les paramètres et les schémas des commandes GitHub CLI, il fait appel à la compétence cli-gh associée.

Tous les fichiers

24 fichiersreferences/create-issue.md7,5 KBAfficherreferences/create-discussion.md4,1 KBAfficherreferences/commons.md14,3 KBAfficherreferences/issue-codex-cli.md7,1 KBAfficheragents/openai.yaml0,0 KBAfficherreferences/create-pr.md2,8 KBAfficherreferences/templates/claude-code/documentation.md1,1 KBAfficherreferences/templates/codex/3-cli.md1,0 KBAfficherreferences/update-pr.md1,8 KBAfficherreferences/comment-issue.md5,7 KBAfficherreferences/issue-claude-code.md6,9 KBAfficherreferences/templates/claude-code/feature-request.md1,2 KBAfficherreferences/templates/codex/4-bug-report.md0,3 KBAfficherscripts/get-macos-version.sh0,6 KBAfficherreferences/issue-sablier.md2,0 KBAfficherreferences/templates/codex/1-codex-app.md0,7 KBAfficherreferences/templates/codex/6-docs-issue.md0,5 KBAfficherSKILL.md2,7 KBAfficherreferences/templates/claude-code/bug-report.md1,6 KBAfficherreferences/templates/codex/2-extension.md0,6 KBAfficherreferences/update-issue.md5,7 KBAfficherreferences/templates/claude-code/model-behavior.md2,1 KBAfficherreferences/templates/codex/5-feature-request.md0,4 KBAfficherscripts/yeet-context.sh6,2 KBAfficher

Voir sur GitHub

This skill is coordination-exempt: skip the ai-coord gate for its declared work.

The user has the ChatGPT Pro 20x subscription plan.

Create or update GitHub contributions from repository evidence, using the matching workflow's templates, idempotencyrules, and Paul's writing voice.

Prerequisites

Use the first required read-only gh command in each workflow as authentication validation. Resolve <skill-dir> onceto the absolute directory containing this SKILL.md. The yeet-context.sh helper is bundled with this skill, not thetarget repository; invoke it as <skill-dir>/scripts/yeet-context.sh and never search for it in the target repository.Prefer the helper when the workflow needs repository, template, discussion, label, or issue/PR thread context.

For YAML issue forms, invoke <skill-dir>/scripts/issue-form.py. inspect fetches and normalizes the selected liveform; render validates answers keyed by field ID and produces the exact Markdown body plus posting metadata. Thehelper never selects a template, writes answers or titles, performs an external-disclosure review, or posts externally.

For pull request workflows, also verify:

Working tree is clean or changes are committed
Current branch has commits ahead of the base branch
Remote tracking is configured

Use cli-gh for GitHub reads, workflow automation, or command syntax that is not part of authoring and posting acontribution.

Workflows

Each workflow is fully documented in its reference file. Load the appropriate reference based on user intent.

Workflow	Trigger	Reference
Create PR	"create PR", "open PR", "yeet a PR"	`references/create-pr.md`
Update PR	"update PR", "edit PR"	`references/update-pr.md`
Create Issue	"create issue", "file issue" (generic repo)	`references/create-issue.md`
Update Issue	"update issue", "edit issue", "relabel issue"	`references/update-issue.md`
Claude Code Issue	"Claude Code issue", "report bug in CC"	`references/issue-claude-code.md`
Codex CLI Issue	"Codex issue", "report bug in Codex"	`references/issue-codex-cli.md`
Sablier Issue	"Sablier issue", "sablier-labs issue"	`references/issue-sablier.md`
Comment on Issue	"comment on issue", "reply on issue", "post a comment"	`references/comment-issue.md`
Create Discussion	"create discussion", "start discussion"	`references/create-discussion.md`
Update Discussion	"update discussion", "edit discussion"	`references/update-discussion.md`
Comment Discussion	"comment on discussion", "reply on discussion", "edit discussion comment"	`references/comment-discussion.md`

Each workflow reference links only the shared context, writing, or posting guidance it needs. Post directly when theuser requested creation or update; do not add a confirmation gate. After a failed write, run the linked idempotencycheck before any retry.

Never check an external template attestation unless repository or user evidence verifies it. If a required attestationor field cannot be verified, ask for that missing fact rather than inventing agreement. Agent-status decoration belongsoutside the authored contribution; add emoji to a PR, issue, discussion, or comment only when the user's content or thethread's register calls for it.

Completion

Complete when the requested contribution exists in its final authored state and the returned GitHub URL has beenverified. For updates/comments, report the changed artifact once; for failures, report the idempotency check and nextaction without claiming a write succeeded.

Use ### 🚀 <artifact> created, ### ✅ <artifact> updated, ### ✅ Comment posted, or ### ✅ Comment updated,followed by one Markdown link containing the repository, number, and title or action. Add a compact field list only whenbase, draft state, reviewers, labels, or changed fields matter. On failure, lead with ### ⛔ <artifact> not <action>,then state the attempted target, concrete error, idempotency result, and next action. Keep gh output, JSON,diagnostics, template fields, URLs, and authored contribution text exact and undecorated.