n8n:community-pr-readiness-check

コミュニティ PR のレビュー準備状況チェック

PR 番号またはブランチ名を指定すると、人によるレビューの準備ができているかを判断し、適切な後続アクションを実行します。

判定フロー

1. Bot が作成者（n8n-cat-bot / aikido-autofix）→ クリーンアップのみを実行し、レビューは行いません。下記の「内部自動化 PR」を参照してください。
2. 自動却下の条件に該当（誤字のみ／承認されていない新規ノード／価値が低い）→ 対応パス D — クローズ に進み、該当するテンプレートを使用します。
3. すべてのチェックに合格（readyForReview === true）→ 対応パス B — チームに振り分け に進みます。
4. 1 つ以上のチェックに不合格 → 対応パス A（タイトルが軽微な修正のみの場合）に進んでから、C — コメントを投稿 に進みます。

ステップ 1 — PR を特定する

ブランチ名が指定された場合は、先に PR 番号を調べます。

gh pr view <branch> --repo n8n-io/n8n --json number --jq .number

ステップ 2 — 取得と前処理

gh pr view <number> --repo n8n-io/n8n \
  --json number,title,body,author,headRefName,headRefOid,files,isDraft,state,labels

内部自動化 PR（Bot が作成者）

author.login が n8n の内部 Bot（n8n-cat-bot / app/n8n-cat-bot または aikido-autofix / app/aikido-autofix）のいずれかである場合、PR 全体をスキップし、以下のクリーンアップ操作を実行します。JSON 出力は絶対に行わないでください。

1. PR のラベルを付け替えます（両方の Bot が対象）。community を n8n team に変更します。

   gh pr edit <number> --repo n8n-io/n8n --remove-label community --add-label "n8n team"
   

2. 関連付けられた Linear チケットを更新します（ステップ 5 に従って GHC-XXXX を抽出します）。
   • n8n-cat-bot — キャンセルします。利用可能な Linear MCP の課題更新ツールを使い、state: "Canceled" を指定します。ラベルは指定しません。
   • aikido-autofix — Dev Platform に振り分けます。利用可能な Linear MCP の課題更新ツールを使い、team: "Developer Platform"、state: "Triage" を指定します。ラベルは指定しません。

複数の PR を処理する場合、スキップした PR は出力から除外します。単一の PR を処理する場合は、1 行のメモを出力します（例：Skipped & cleaned up #30591 (n8n-cat-bot): relabeled to n8n team, cancelled GHC-8398.）。

重複処理の防止

PR に triage:in-progress がすでに付いている場合、別のレビュアーが振り分け作業の途中です。二重処理を避けるため、処理を中断します。1 行のメモを出力し（例：Skipped #30205: already has triage:in-progress）、次の PR に進みます。チェックを実行せず、ラベルも変更せず、Linear にも触れないでください。

ユーザーが、処理が止まっている triage:in-progress 付き PR の再処理を明示的に依頼した場合（例：前回の実行がクラッシュした場合）、ユーザーが手動でラベルを解除し、再実行できます。

それ以外の場合 — 処理中に設定

既存の triage:* 状態ラベルがあれば削除してから triage:in-progress を追加します。これにより、以前 triage:needs-info または triage:tests-needed として差し戻された PR を再レビューする場合も、状態が 1 つだけになるという不変条件を保てます。

gh pr edit <number> --repo n8n-io/n8n \
  --remove-label "triage:pending" \
  --remove-label "triage:needs-info" \
  --remove-label "triage:tests-needed" \
  --remove-label "triage:complete" \
  --add-label "triage:in-progress"

これらの triage:* ラベルのうち、実際に付いているものは 1 つだけです。ラベルが見つからないと --remove-label はエラーになるため、それぞれの削除を個別に呼び出す（または一括で実行してエラーを無視する）必要があります。その後、ラベルを追加します。PR に付けられる triage:<state> ラベルは常に 1 つです。このスキルは終了前に triage:in-progress を最終状態に置き換えます（reference/label-flow.md を参照）。

併せて取得するもの（並行して実行）

# cubic-dev-ai PR review comments (for check E)
gh api --paginate "repos/n8n-io/n8n/pulls/<number>/comments" \
  --jq '.[] | select(.user.login == "cubic-dev-ai[bot]") | {body: .body, path: .path}'

# n8n-assistant issue comments (for the Linear ticket reference)
gh api --paginate "repos/n8n-io/n8n/issues/<number>/comments" \
  --jq '[.[] | select(.user.login == "n8n-assistant[bot]" or .user.login == "n8n-assistant") | .body] | join("\n")'

ステップ 2.5 — 自動却下の判定

CONTRIBUTING.md に従い、次の 3 種類の PR はレビューせず、直ちにクローズします。

• 誤字のみの PR — 差分がスペルや文法の修正のみで、ロジックやテストが含まれていないもの。
• 新規ノードの PR — n8n チームが明示的に引き受けることに合意している場合を除き、新しいノードを追加するもの。
• 価値が低い／自動化された PR — 差分が空白、書式、並べ替えのみの変更、説明のない大量の名前変更や依存関係の更新、バッジ／コメントのみの調整、または一括スクリプトによる投稿であり、機能変更やその根拠がないもの。慎重に判定してください。

いずれかに該当する場合は checks.AutoReject を設定し、対応 D に直接進みます。各パターンの詳細なルールと確認方法については、reference/checks.md を参照してください。

ステップ 3 — 準備状況のチェックを実行する

AutoReject が null の場合に実行します。それぞれの詳細なルールは reference/checks.md を参照してください。

• A. CLA — cla-signed ラベルが付いていること。
• B. タイトル — Conventional Commit の正規表現に一致すること。正式なルールは .github/pull_request_title_conventions.md にあります。
• C. 説明 — .github/pull_request_template.md のすべてのセクション見出しとチェックリスト項目が、PR の本文に含まれていること。テンプレートはチェック時に読み込まれるため、変更は自動的に反映されます。
• D. テスト — ソースロジックの変更に対応するテストファイルがあること（fix には、バグを対象とした回帰テストが必要です）。docs/ci/chore/build の PR は対象外です。
• E. cubic-dev-ai — 未解決のコメントがないこと（"Addressed in commit" マーカーがあれば解決済みです）。
• F. 関連する Issue またはフォーラムのディスカッション — fix の PR には GitHub Issue へのリンクが必要です。feat／refactor／perf の PR には Issue または community.n8n.io のトピックへのリンクが必要です。docs/ci/chore/build/test は対象外です。
• G. サイズ — files 内のファイルごとの additions の合計（ロックファイルと生成ファイルは除く）が 1000 以下で、論理的な変更が 1 つであること。Oversized を設定します。

ステップ 4 — 担当チームを特定する

変更ファイルの一覧を使って node .github/scripts/owners/owners.mjs を実行し、最も適合する GitHub チームを Linear チームに対応付けます。完全な対応表、サブエージェントへのフォールバック手順、ラベルのルールについては、reference/teams.md を参照してください。

ステップ 5 — Linear チケットを抽出する

n8n-assistant は、すべてのコミュニティ PR に This PR has been added to our internal tracker as "GHC-XXXX" を含むコメントを残します。n8n-assistant のコメント本文を連結した文字列から \bGHC-\d+\b を検索し、最初に一致したものを取得します。

n8n-assistant のコメントがない場合（自動化が導入される前の古い PR）、linearTicket は null です。

ステップ 5b — 関連する Issue チケットを見つけ、重複を検出する

PR の本文には、Fixes #NNNN／Closes #NNNN／Resolves #NNNN（または https://github.com/n8n-io/n8n/issues/NNNN へのリンク）が記載されていることがよくあります。これらの Issue には通常、それぞれ独自の GHC チケットがあるか、すでにチームに振り分けられています。PR が Issue を参照している場合、その Issue チケット が信頼できる情報源になります。アクションパスは PR をそのチケットにリンクし、（準備ができたら）PR 自体のレビュー用チケットをキャンセルします。アクションパスが処理できるよう、関連チケットと重複する PR をここに示します。

関連する Issue チケット

1. PR の本文から、\b(?:fix(?:es)?|close[sd]?|resolve[sd]?)\s+#?(\d+)\b（大文字と小文字を区別しない）に一致する Issue 番号、または github\.com/n8n-io/n8n/issues/(\d+) に一致する URL をすべて抽出します。重複は除外します。
2. 各 Issue 番号について、利用可能な Linear MCP の Issue 検索ツールを使って Linear を検索します（クエリ github.com/n8n-io/n8n/issues/<num>、上限 50）。結果は、description に正確な URL https://github.com/n8n-io/n8n/issues/<num> が含まれる Issue に絞り込みます。n8n-assistant ボットは、作成するすべてのコミュニティ Issue チケットの説明にこの URL を埋め込むため、一致の信頼性は高いです。デフォルトの上限である 50 を使い、それより小さい値にしないでください。query は updatedAt 順の部分文字列検索なので、issues/<num> はより大きな Issue 番号にも一致します（たとえば 123 を検索すると 1234 にも一致します）。そのため、正確なチケットが結果のどこにあってもおかしくありません。上限を小さくすると、該当チケットが気付かれないまま除外される可能性があります。結果が 50 件に達した場合は、正確な一致が見つかるか、結果をすべて取得し終えるまで cursor を使ってページネーションします。
3. 一致するチケット ID（例：GHC-1234、またはその後振り分け先が変更されている場合は NODE-5678、CAT-3338）を収集します。キャンセル済み／重複チケットも含めます。追跡可能性を確保するうえで、リンクは依然として有用です。

結果は JSON の relatedIssueTickets として出力します。Fixes／Closes／Resolves の参照がない場合は、relatedIssueTickets: [] を返します。リンク付けアクション自体はステップ 7 にあります（「PR をその Issue チケットにリンクする」を参照）。

重複する PR

PR がイシューを参照している場合、別のコントリビューターが同じイシューに対する PR をすでにオープンしていることがあります。3 つのシグナルから重複候補を収集します。いずれかが該当した場合、アクションパスではこの PR をクローズするかどうかを尋ねます（パス D、重複テンプレート）。参照されている各イシュー番号について実行します。

# Other open PRs mentioning the same issue
gh pr list --repo n8n-io/n8n --state open \
  --search "#<num> in:body" --json number,title,author

# PRs cross-referenced / linked on the GitHub issue itself
gh api --paginate "repos/n8n-io/n8n/issues/<num>/timeline" \
  --jq '[.[] | select(.event=="cross-referenced") | .source.issue
         | select(.pull_request) | {number, title}]'

また、該当する Linear イシューチケット（上記の検索結果）に、PR へのリンクがすでに links／添付ファイルに含まれているか確認します。すべてのシグナルからレビュー対象の PR を除外し、PR 番号で重複を排除して、結果を JSON の duplicatePRs として出力します（該当がない場合は []）。

Step 6 — JSON を出力

{
  "readyForReview": <true if all passing checks allow merge, false otherwise>,
  "messageForUser": "<Short message to the contributor listing what they need to address. 'N/A' if ready.>",
  "team": "<Linear team name (from reference/teams.md), or 'Engineering' as fallback>",
  "linearTicket": "<GHC-XXXX or null>",
  "relatedIssueTickets": [<"GHC-1234" | "NODE-5678" | ...>],
  "duplicatePRs": [<{ "number": <int>, "title": "<string>" }, ...>],
  "checks": {
    "AutoReject": <"typo-only" | "new-node" | "low-value" | null>,
    "CLA": <bool>,
    "Title": <bool>,
    "Description": <bool>,
    "TestsNeeded": <bool>,
    "TestsIncluded": <bool>,
    "CubicIssues": <true if unresolved cubic issues exist, false otherwise>,
    "LinkedIssueOrDiscussion": <true if the §1 issue/forum link is present or the type is skipped>,
    "Oversized": <true if the filtered per-file additions sum > 1000 and the work is separable>
  }
}

readyForReview が true になるのは、AutoReject が null であり、CLA、Title、Description、LinkedIssueOrDiscussion がすべて true、CubicIssues と Oversized が両方とも false で、さらに TestsNeeded が false または TestsIncluded が true の場合に限られます。AutoReject が設定されている場合、readyForReview は常に false です。

まず JSON を出力し、その後、以下の適切なアクションパスを実行します。

Step 7 — アクションパス

各プロンプトについて、ユーザーに質問します（記載された選択肢を提示します）。分析のみを行うサブエージェントはステップ 6 の後に処理を止め、呼び出し元にステップ 7 の実行を委ねます。

PR をイシューチケットにリンクする

B および C から呼び出され、relatedIssueTickets が空でない場合に実行します。参照先のイシューチケットを信頼できる情報源とし、Linear のリンク機能を使って PR を紐付けます。relatedIssueTickets 内の各チケットについて、Linear MCP の issue-update ツールを呼び出します。

id    = <issue ticket>
links = [{ url: "https://github.com/n8n-io/n8n/pull/<pr>",
           title: "Community PR #<pr>" }]   # append-only — existing links are preserved

続いて、PR の準備状況に応じた文面でコメントを投稿します（Linear MCP の comment ツール、issueId = <issue ticket>）。

• 準備完了 + 割り当て（パス B）： 「リンクされたコミュニティ PR # により、このイシューが解決される可能性があります。」
• 未準備（パス C）： 「このイシューを解決する可能性のあるコミュニティ PR（#）が進行中ですが、現在もトリアージ中です。」

ステータスとチケットのクローズ処理はパスによって異なり、以下の B および C で説明します。

A — 軽微なタイトル修正

タイトルの問題が、決定論的な変換で修正できる場合、その問題は軽微です。

• 先頭または末尾の空白。
• 要約の最初の文字の大文字・小文字が不適切。
• 末尾のピリオド。
• 大文字・小文字が混在した revert: を小文字にする必要がある（変更は不要で、フラグを立てるだけです）。

失敗しているチェックが Title のみ（または Title と CubicIssues のみ）で、問題が軽微な場合は、修正案を提示して Apply proposed / Edit before applying / Skip を尋ねます。以下を使って適用します。

gh pr edit <number> --repo n8n-io/n8n --title "<new title>"

その後、Title を再評価し（この時点で合格）、B または C に進みます。重大なタイトルの問題（誤ったタイプ、タイプの欠落、コロンがない、ハイフン付きのスコープ）にはコントリビューターの判断が必要です。A はスキップして C に進みます。

B — チームにトリアージする（readyForReview === true）

まず重複を確認します。 duplicatePRs が空でない場合は、重複 PR（番号＋タイトル）を提示し、この PR を重複としてクローズするか尋ねます。Yes の場合は D（重複テンプレート）に進みます。No の場合は、以下の B に進みます。

移動先の状態：NODES の場合は Review、それ以外のすべてのチームでは Triage です。PR の解決済みオーナー team に基づきます。ラベルの組み合わせについては reference/teams.md を参照してください。

relatedIssueTickets が空でない場合 — Issue チケットが信頼できる唯一の情報源です。 次のように尋ねます。「PR のレビュー準備ができました。Issue チケット <relatedIssueTickets> にリンクし、状態を に移動して、PR 自体のチケット <linearTicket> をキャンセルしますか？」 選択肢：Yes, link and triage / No, leave as-is。Yes の場合：

1. 各関連チケットについて、「PR を Issue チケットにリンクする」（準備完了時のバリアント）を実行します。
2. Linear MCP の Issue 更新ツールを使って、関連する Issue チケットすべての状態を移動します（id = <issue ticket>、state = <destination>）。NODES の場合は Review、それ以外の場合は Triage です。
3. PR 自体のレビューチケットをキャンセルします。Linear MCP で Issue を更新し、id = linearTicket、state = "Canceled" と指定します（linearTicket が null の場合はスキップします）。
4. GitHub PR ラベルを適用します（Linear の更新が成功した場合のみ）。これにより、レビュアーが引き続き PR を見つけられます。

   gh pr edit <number> --repo n8n-io/n8n \
     --remove-label "triage:in-progress" \
     --remove-label "status:pending-assignment" \
     --add-label "team:<slug>" \
     --add-label "status:team-assigned" \
     --add-label "triage:complete"
   

それ以外（関連する Issue チケットがない場合）— 従来の手順を変更せずに使用します。 次のように尋ねます。「PR のレビュー準備ができました。Linear チケット <linearTicket> をチーム <team> に割り当て、状態を に移動しますか？」 選択肢：Yes, assign and triage / No, leave as-is。Yes の場合：

# 1. Linear — call the available Linear MCP issue-update tool with:
#      id     = linearTicket
#      team   = <team>
#      state  = <destination>
#      labels = <computed labels>
# 2. GitHub (only if Linear succeeded) — see reference/label-flow.md
gh pr edit <number> --repo n8n-io/n8n \
  --remove-label "triage:in-progress" \
  --remove-label "status:pending-assignment" \
  --add-label "team:<slug>" \
  --add-label "status:team-assigned" \
  --add-label "triage:complete"

従来の手順では、PR 自体のレビューチケットはキャンセルされず、追跡チケットとして残ります。linearTicket が null の場合は、トリアージの前に新しい Linear チケットを作成するかどうかを尋ねます（n8n-assistant より前の古い PR が該当します）。それ以外の場合は B をスキップして、ユーザーに尋ねます。

C — コントリビューターにコメントを投稿する（readyForReview === false、自動却下なし）

relatedIssueTickets が空でない場合は、「PR を Issue チケットにリンクする」（未準備時のバリアント）を実行します。PR のリンクを追加し、「作業中で、トリアージ中です」というコメントを投稿します。各 Issue チケットの状態は変更せず、PR 自体のレビューチケットもキャンセルしないでください — PR はまだ準備できていないため、作業中であることだけを示します。（任意で duplicatePRs をユーザーに提示できますが、ここではクローズしないでください — クローズは B から実行する D のアクションです。）

messageForUser には、コントリビューターが対応する必要のある不合格チェックをすべて記載します。リンク済みの Issue／フォーラムトピックがない場合（チェック F — fix では GitHub Issue を、feat／refactor では community.n8n.io のトピックを作成するかリンクするよう依頼）と、PR が大きすぎる場合（チェック G — 作業を分割できる場合は、目的を絞った複数の PR に分割するよう依頼）も含めてください。

messageForUser を表示し、Post as-is / Edit before posting / Skip のいずれかを尋ねます。投稿する場合：

gh pr comment <number> --repo n8n-io/n8n --body "<final message>"

その後、適切な終了トリアージラベルを適用します — 優先順位は triage:tests-needed > triage:needs-info とし、リンク済みの Issue／フォーラムトピックがない場合や PR が大きすぎる場合は triage:needs-info に分類します。reference/label-flow.md を参照してください。Skip の場合は、次のループで処理されるよう、PR を triage:in-progress のままにします。

A ですでに唯一の不合格チェックに対応していて、PR の準備ができている場合は、C 全体をスキップして、代わりに B を実行します。

D — PR をクローズする

レビューせずに PR をクローズする場合に使用します。よくある理由は次の 3 つです。

1. 自動却下（AutoReject が設定されている）— 誤字のみ、承認されていない新しいノード、または価値が低い変更／自動生成された変更。
2. 重複 — duplicatePRs が空でない（別のオープン中の PR が同じ変更に対応している）ことを、パス B の重複チェックで確認済みの場合。テンプレートでは duplicatePRs の #<other-pr> を使用します。
3. 対象範囲外／複数変更の同梱 — 無関係な修正が複数含まれており分割すべき場合、または n8n チームが対応を見送った範囲の場合。

「クローズしてコメント／クローズ前に編集／スキップ」のいずれかを選択します。以下のテンプレートから 1 つ選び、コントリビューターや詳細に合わせて調整してください。

誤字のみ：

ご投稿ありがとうございます！コントリビューションガイドに記載のとおり、誤字修正のみの PR は受け付けていません。機能を変更せずにレビューの負担が増えるうえ、スペルチェックのルールでほとんどのケースを自動的にカバーできるためです。今回はクローズします。誤字修正と関連するロジックの変更を組み合わせた PR であれば、ぜひご投稿ください。🙏

新しいノード：

ご投稿ありがとうございます！チームが明示的に対象として合意していない限り、n8n ではコアモノレポへの新しいノードの追加を受け付けていません。代わりにコミュニティノードとして公開してください。全面的にご自身で管理でき、こちらの長いレビュー待ち行列も避けられます。コントリビューションガイドに従い、この PR はクローズします。

価値が低い変更／自動生成された変更：

PR を作成いただきありがとうございます！PR はすべて手動でレビューしているため、コントリビューションガイドに記載のとおり、明確な機能上のメリットがある変更のみを受け付けています。今回の変更では動作が変わらない（または対応可能な理由が示されていない）ため、レビュー待ち行列を適切に保つためにクローズします。実際の修正や改善が目的であれば、まず問題を説明する issue またはフォーラムのトピックを作成してください。喜んで確認します。🙏

別の PR との重複：

ご投稿ありがとうございます！この変更は、レビューがより進んでいる # ですでに対応中です。レビュー待ち行列を整理するため、こちらの PR はクローズし、もう一方の PR を優先します。不足している点があれば、そちらでぜひコメントしてください。

変更の同梱／対象範囲外：

ご投稿ありがとうございます！コントリビューションガイドに記載のとおり、1 つの PR につき変更は 1 つに絞っていただくようお願いしています。この PR には無関係な修正が 件含まれています。それぞれを個別の PR として再度投稿し、テンプレートに記入したうえで、回帰を防ぐユニットテストを追加してください。それまでの間、この PR はクローズします。🙏

クローズ操作（理由にかかわらず共通）：

gh pr comment <number> --repo n8n-io/n8n --body "<final message>"
gh pr close <number> --repo n8n-io/n8n
gh pr edit <number> --repo n8n-io/n8n \
  --remove-label "triage:in-progress" \
  --remove-label "status:pending-assignment" \
  --add-label "status:internal-closed" \
  --add-label "triage:complete"

linearTicket が設定されている場合は、利用可能な Linear MCP の issue 更新ツールを使ってチケットもキャンセルしてください（id=linearTicket、state="Canceled"）。gh pr close で PR がすでにクローズされていると報告された場合（コントリビューターが先にクローズした場合）も、コメント、ラベル、チケットのキャンセルはそのまま実行してください。

注意事項

• ドラフト PR — すべての指摘事項を報告しますが、PR がドラフトであることも明記してください。
• すでにマージ済みまたはクローズ済み — その旨を伝え、チェックをスキップしてください（トリアージラベルは適用しないでください）。
• すでにコメントした PR の再レビュー — GitHub Timeline API を使って、最後にこのスキルを使用してからコントリビューターが活動したかどうかを確認してください。reference/re-review.md を参照してください。
• ラベルの状態遷移 — 常に triage:<state> ラベルを 1 つだけ付けます。遷移については reference/label-flow.md に記載されています。