port-github-app-to-origin

GitHub App を Origin App に移植する

アプリのコードベース内で実行してください。出力されるのは、チーム向けの移植ブリーフと、そのまま送信できる「Cursor へのフィードバック」セクションです（references/brief.md）。このスキルが行うのは計画のみです。ブリーフを読んだ後にユーザーから依頼がない限り、コードの作成や変更は行いません。ドキュメントと最初に確認すべきルールについては、origin-api スキルに従ってください。追加のルールは次の2つです。

1. 質問せず、コードから見つけてください。 アプリが何を使用しているか、ソースを読んで確認してください。見つからない項目は、チームへの質問にしてください。
2. フィードバックには、チームのコードではなくユースケースを記載してください。 ブリーフ内のチーム向けセクションでは file:line を引用してもかまいませんが、「Cursor へのフィードバック」には、アプリが必要とする機能と、そのために Origin に不足しているものだけを、Origin の用語で記載してください。ファイルパス、モジュール名、フレームワークの詳細、リポジトリ名は記載しないでください。

確認する項目

各項目について file:line を記録し、確認したものの見つからなかった項目も記載してください。

• 宣言されている権限とイベント。マニフェストまたはチェックイン済みのインフラストラクチャコードから確認してください。どちらもない場合は、呼び出し内容から推定してください。
• アプリが処理するすべての Webhook イベントと、各ハンドラーが読み取るすべてのペイロードフィールド。ログに記録するだけのフィールドも含めてください。
• すべての REST 呼び出しと GraphQL 呼び出しについて、コードが渡すパラメーターとフィルター、読み取るレスポンスフィールド、各 Webhook のたびに実行されるかループ内で実行されるか、およびページネーションの方法を記録してください。
• 認証：JWT アルゴリズム、インストール後にアプリがインストール ID を取得する方法、トークンの有効期限への対応、ユーザーサインインの有無とその目的、アプリが git をクローンまたはプッシュするかどうか。
• Webhook レシーバー：署名の検証方法、検証時に生の本文を使用できるかどうか、配信の重複を排除する方法。
• フレームワークまたはライブラリがアプリに代わって行う呼び出し。Probot のレシーバー、トークンキャッシュ、設定ローダー、Octokit App によるインストールとリポジトリの一覧取得、アプリ認証ライブラリなどです。依存関係のドキュメントを読み、こうした呼び出しには「from <dependency>」と記載してください。

マッピング方法

概要には仕様全体が必要ですが、openapi.yaml と llms-full.txt はそれぞれ数百キロバイトあり、全体をコンテキストに読み込むには大きすぎます。可能であれば、作業ツリーを上書きしたり、ファイルを残したりしないよう、アプリのリポジトリ外の一時的な場所にローカル保存し、検索して一致する箇所だけを読みます。

• openapi.yaml の x-origin-scopes: は、各オペレーションのスコープを示します。operationId はその1行上にあります。
• openapi.yaml の x-origin-webhook-events: は、各 Webhook ペイロードスキーマに、そのペイロードを配信するイベントのスラッグを示します。
• llms-full.txt の ### <Endpoint name> と ### <Payload type> の見出しから、それぞれのエンドポイントまたはペイロードのフィールドをドット区切りのパスで記述したセクションが始まります。見出しから次の ### までを読みます。

後で個別の質問に答えるときは、まず llms.txt を参照し、該当するセクションだけを取得します。

• 名前が一致しても、それは候補であり、答えではありません。コードが渡す値や読み取る値と照らし合わせながら、オペレーションの説明、パラメーター、レスポンスフィールドを確認します。コードが依存するパラメーターやフィールドが存在しない場合、それは回避策または不足であり、一致とはみなしません。
• /issues/{n}/… 配下にある GitHub のプルリクエスト関連呼び出し（コメント、ラベル）は、Origin ではプルリクエストのエンドポイントにあります。実際の Issue に対してコードがこれらを使う場合は、references/brief.md の「Where GitHub features live on Origin」を参照します。
• Origin に GraphQL はありません。各クエリを REST 呼び出しに分割し、呼び出し数を記録します。
• 要求するスコープは、列挙したオペレーションの x-origin-scopes.scopes の和集合です。GitHub マニフェストは翻訳しないでください。
• GitHub のイベントとアクションの各ペアが「Events」で対応するスラッグは、最大1つです。アクションはスラッグの一部です。スラッグがないペアは、Origin のイベントではありません。
• コードが読み取る各ペイロードフィールドについて、それがペイロード内にあるか、ペイロードを囲む配信エンベロープ内にあるか（アクションは event.type に含まれます）、追加の読み取りが必要か（オペレーション名とイベントあたりの呼び出し回数も記載）、他のフィールドから算出できるか、または存在しないかを記録します。ペイロードはスナップショットです。REST リソースにはあるものの、ペイロードにないフィールドには追加の読み取りが必要です。
• ドキュメントに記載のない機能は、現時点では利用できません。チームに確認してください。ドキュメントで動作が肯定も否定もされていない場合は、質問を記載し、その動作を確認するステップをエンドツーエンドテストに加えます。GitHub での動作と同じだと決めつけないでください。

完了前の確認事項

Origin に関するすべての主張に、保存したドキュメント内の参照先を付けます。不足事項には、そのコストを明記したフィードバック項目を設けます。フィードバックからチーム内部の情報が明らかにならないようにします。概要では、ネイティブ機能かミラーかという問いを明示します。