Hogar

Skill

Git y control de versiones

yeet

paulrberg/agent-skills

Úsese para flujos de trabajo de GitHub PR/issue/discussion: crear o actualizar PRs e issues, publicar comentarios y iniciar discusiones; entre los desencadenantes se encuentra yeet.

...Expandir todo

Tiempo actualizado 26 de agosto de 2026

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

Acerca de yeet

yeet facilita los flujos de trabajo para contribuciones de código abierto basados en GitHub, abarcando la creación y actualización de solicitudes de pull request e issues, la publicación de comentarios y el inicio de discusiones. Su principio rector es el análisis semántico en lugar de la operación mecánica: busca comprender la intención y el contexto de un cambio antes de generar un título, una descripción o seleccionar una plantilla, y mantiene todo el contenido generado en un tono conversacional e informal.

Esta herramienta abarca un conjunto de flujos de trabajo distintos, cada uno documentado en su propio archivo de referencia que se carga según la intención del usuario. Estos incluyen la creación y actualización de PRs, la creación y actualización de issues (con referencias específicas para reportar errores en Claude Code, Codex CLI y Sablier), la publicación de comentarios en issues y la creación de discusiones. Patrones comunes como la validación de autenticación, las advertencias, la sintaxis HEREDOC, el análisis semántico, el tono, la normalización de la plataforma, el manejo de errores y los enlaces a archivos se encuentran en un archivo de referencia compartido.

Antes de actuar, verifica los requisitos previos. La primera orden gh de solo lectura necesaria en cada flujo de trabajo también sirve como validación de autenticación, y prefiere utilizar el archivo auxiliar scripts/yeet-context.sh para recopilar información sobre el repositorio, la plantilla, la discusión, las etiquetas o el contexto del hilo de issue/PR. Los flujos de trabajo relacionados con solicitudes de pull request tienen requisitos adicionales: el árbol de trabajo debe estar limpio o los cambios deben haber sido guardados, la rama actual debe tener commits más recientes que la rama base, y debe estar configurada la seguimiento remoto.

Úsala cuando contribuyas a repositorios de GitHub y desees PRs, issues, comentarios o discusiones bien redactados y conscientes del contexto, en lugar de textos genéricos. Se activa con frases como “create PR”, “open PR”, “yeet a PR”, “file issue”, “comment on issue” o “start discussion”. Para obtener información detallada sobre la sintaxis de las órdenes de GitHub CLI, sus flags y patrones, hace referencia a la herramienta relacionada cli-gh, manteniendo su enfoque en la orquestación de flujos de trabajo y la generación de contenido semántico.

Preguntas frecuentes

¿Qué flujos de trabajo de GitHub admite yeet?

La creación y actualización de solicitudes de pull request e issues, la publicación de comentarios en issues y el inicio de discusiones, además de referencias específicas para reportar issues en Claude Code, Codex CLI y Sablier.

¿Qué verifica antes de abrir una solicitud de pull request?

Que el árbol de trabajo esté limpio o que los cambios hayan sido guardados, que la rama actual tenga commits más recientes que la rama base, y que esté configurada la seguimiento remoto.

¿Cómo se autentica yeet con GitHub?

Utiliza la primera orden gh de solo lectura necesaria en cada flujo de trabajo como validación de autenticación, en lugar de un paso de inicio de sesión separado.

¿Qué hace único el contenido generado por yeet?

Da prioridad al análisis semántico, comprendiendo la intención y el contexto de un cambio antes de redactar títulos y descripciones, y mantiene toda la salida en un tono conversacional e informal.

¿Maneja por sí mismo la sintaxis detallada de GitHub CLI?

No. Para obtener información detallada sobre la sintaxis de las órdenes de GitHub CLI, sus flags y patrones, hace referencia a la herramienta relacionada cli-gh.

Todos los archivos

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

Ver en 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.