yeet

GitHub コントリビューションワークフロー

このスキルは調整ゲートの適用対象外です。宣言された作業では ai-coord ゲートをスキップしてください。

リポジトリの根拠に基づいて GitHub コントリビューションを作成または更新し、該当するワークフローのテンプレート、冪等性ルール、Paul の文体に従います。

前提条件

各ワークフローで最初に実行する読み取り専用の必須 gh コマンドを使って、認証を検証してください。<skill-dir> は、この SKILL.md を含むディレクトリの絶対パスに一度だけ解決してください。

このスキルには、対象リポジトリではなく、yeet-context.sh ヘルパーが同梱されています。<skill-dir>/scripts/yeet-context.sh として実行してください。対象リポジトリ内で探してはいけません。リポジトリ、テンプレート、ディスカッション、ラベル、または Issue／PR スレッドのコンテキストが必要なワークフローでは、このヘルパーを優先してください。

YAML Issue フォームには、<skill-dir>/scripts/issue-form.py を実行してください。inspect は選択したライブフォームを取得して正規化します。render はフィールド ID をキーとする回答を検証し、正確な Markdown 本文と投稿メタデータを生成します。このヘルパーは、テンプレートの選択、回答やタイトルの記入、外部開示のレビュー、または外部への投稿は行いません。すべての Issue 作成・更新ワークフローでは、メタデータを解決または渡す前に、references/context.md > Issue Metadata Permissions を適用してください。レンダリングされたテンプレートのメタデータが示すのは要求された値であり、閲覧者がそれを適用する権限ではありません。

プルリクエストのワークフローでは、さらに以下を確認してください。

• 作業ツリーがクリーンであるか、変更がコミットされていること
• 現在のブランチに、ベースブランチより先行するコミットがあること
• リモートトラッキングが設定されていること

コントリビューションの作成と投稿に含まれない GitHub の読み取り、ワークフローの自動化、またはコマンド構文には、cli-gh を使用してください。

ワークフロー

各ワークフローの詳細は、それぞれのリファレンスファイルに記載されています。ユーザーの意図に応じて、適切なリファレンスを読み込んでください。

ワークフロー	トリガー	リファレンス
PR の作成	"create PR", "open PR", "yeet a PR"	references/create-pr.md
PR の更新	"update PR", "edit PR"	references/update-pr.md
Issue の作成	"create issue", "file issue" (一般的なリポジトリ)	references/create-issue.md
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
Issue へのコメント	"comment on issue", "reply on issue", "post a comment"	references/comment-issue.md
ディスカッションの作成	"create discussion", "start discussion"	references/create-discussion.md
ディスカッションの更新	"update discussion", "edit discussion"	references/update-discussion.md
ディスカッションへのコメント	"comment on discussion", "reply on discussion", "edit discussion comment"	references/comment-discussion.md

各ワークフローのリファレンスには、必要な共有コンテキスト、執筆、または投稿のガイダンスのみがリンクされています。作成する本文やコメントはすべて、posting.md > Model Co-signature に従う必要があります。ユーザーが作成または更新を依頼した場合は、直接投稿してください。確認を求める段階を追加してはいけません。書き込みに失敗した場合は、再試行する前に、リンク先の冪等性チェックを実行してください。

リポジトリまたはユーザーの証拠によって確認できない限り、外部テンプレートへの同意を確認してはいけません。必須の同意やフィールドを確認できない場合は、同意を捏造せず、不足している事実を尋ねてください。エージェントのステータスを示す装飾は、作成した投稿の外側に付けてください。PR、Issue、ディスカッション、コメントに絵文字を付けるのは、ユーザーの内容またはスレッドの文体で必要な場合に限ります。

完了

依頼された投稿が最終的な作成状態で存在し、返される GitHub URL が確認できた時点で、ワークフローは完了です。更新やコメントの場合は、変更した項目を一度だけ報告してください。コマンドの終了ステータスではなく、読み戻した内容から結果を判断してください。メタデータの変更に失敗しても、作成自体は成功している場合があります。

### 🚀 <artifact> created、### ✅ <artifact> updated、### ✅ Comment posted、または ### ✅ Comment updated を使用し、その後にリポジトリ、番号、タイトルまたは操作を含む Markdown リンクを1つ記載してください。ベース、ドラフト状態、レビュアー、ラベル、または変更フィールドが重要な場合に限り、簡潔なフィールド一覧を追加してください。部分的な成功が確認できた場合は、作成または更新された項目を報告し、省略された、または失敗したメタデータを明示してください。

確認された未完了の場合に限り、### ⛔ <artifact> not <action> を使用してください。読み戻しから結論を出せない場合は、結果を未確認として報告してください。具体的なエラー、冪等性チェックの結果、次の対応を含めてください。gh の出力、JSON、診断情報、テンプレートのフィールド、URL、作成した投稿のテキストは、正確なまま装飾せずに記載してください。