skilld
All skills
n8n-io avatar

/community-pr-readiness-check

@4349410 official
by n8n - Workflow Automationn8n-io/n8n206k stars
60,960

Checks if a community pull request is ready for human review. Verifies CLA signature, PR title format, description completeness, test coverage, and cubic-dev-ai issues, then triages to the right Linear team or recommends a close. Use when given a PR number or branch name to review, or when the user says /community-pr-readiness-check, or asks to check if a PR is ready for review.

  • 5 files
  • 44.1 KB
  • Updated 2 months ago
  • GitHub

Ask your Agent

Use this Skill: https://skilld.dev/gh/n8n-io/n8n/community-pr-readiness-check

This session only. Nothing lands on disk.

referenceteams.md

≈1.3k tokens on demand. Your agent reads this file only when SKILL.md points to it.

Community PR Readiness Check — teams and labels

Owner resolution, the GitHub-team → Linear-team → label mapping, and the Linear ticket label rules used when triaging.

Contents

  • Identifying the owning team
  • GitHub team → Linear team → GitHub label
  • Linear ticket label rules
    • Always-on label
    • Type label (based on PR title prefix)
    • Team-specific extra label
    • Worked examples

Identifying the owning team

Use the canonical owners script at .github/scripts/owners.mjs. It parses .github/OWNERS with last-match-wins semantics and returns allocations sorted by file count with a share percentage. Using the script keeps this skill consistent with whatever CI uses.

  1. Write the PR's changed file paths (from the files list) to a temp file, one per line:
    printf '%s\n' <path1> <path2> ... > /tmp/pr-<number>-files.txt
  2. Run the script:
    node .github/scripts/owners.mjs /tmp/pr-<number>-files.txt
  3. The script prints JSON of the form:
    {
  "totalFiles": 12,
  "allocations": [
    { "team": "@n8n-io/ai", "fileCount": 10, "share": 83, "files": [...] },
    { "team": "@n8n-io/catalysts", "fileCount": 2, "share": 17, "files": [...] }
  ]
}
    Allocations are already sorted by fileCount descending — take the first entry as the winning team.
  4. Clean up: rm /tmp/pr-<number>-files.txt.
  5. Strip the @n8n-io/ prefix from allocations[0].team — the GitHub team slug is nodes, iam, ai, etc. If allocations is empty (no file matched any rule, which is possible only if .github/OWNERS lost its catch-all), fall back to catalysts.
  6. Map the GitHub team slug to its Linear team name and PR label using the table below. The team field in the JSON output is the Linear team name. If the resolved GitHub team slug has no entry in the table, fall back to Engineering.

Sub-agent fallback: if node execution is denied by the sandbox, read .github/OWNERS directly and apply last-match-wins by hand. All the active rules fit on one screen.

GitHub team → Linear team → GitHub label

GitHub team (@n8n-io/…) Linear team GitHub team label
catalysts Catalysts team:cats
adore Adore team:adore
ai AI team:ai
nodes NODES team:nodes
design Design team:design
iam Identity & Access team:identity
ligo Lifecycle & Governance team:lifecycle
ai-assistant AI Assistant team:instance-ai
frontend Adore team:adore
qa-dx Developer Platform team:qa-dx
migrations-review Catalysts team:cats

The GitHub team label column is what gets applied to the PR after a successful Linear assignment (see reference/label-flow.md).

Linear ticket label rules

When calling the available Linear MCP issue-update tool to assign a ticket to a team, pass a labels array composed of three pieces:

Always-on label

  • GitHub — every community PR ticket carries this. In the Linear UI it renders as source > GitHub; the source prefix is a label-group parent, not part of the API name.

Type label (from PR title prefix)

PR title type Linear label
feat feature
fix bug
anything else (perf, refactor, docs, ci, chore, build, test, revert) enhancement

Pass the child label name only — Linear silently drops unknown labels, so don't include type > prefixes.

Team-specific extra label

Destination team Extra label
Catalysts Community PR
NODES community-pr
other teams (no extra)

Worked examples

  • feat PR going to Catalysts: ["GitHub", "feature", "Community PR"]
  • fix PR going to NODES: ["GitHub", "bug", "community-pr"]
  • perf PR going to AI: ["GitHub", "enhancement"]
  • chore PR going to Lifecycle & Governance: ["GitHub", "enhancement"]

Destination state

Destination team Linear state
NODES Review
any other team Triage

NODES has a dedicated Review lane; every other team handles routing inside their own triage.

This same table governs the issue-ticket state move when a ready PR is linked onto a referenced issue ticket (SKILL.md step 7B): move the issue ticket to Review for NODES, Triage otherwise — keyed off the PR's resolved owner team.

Source: SKILL.md on GitHub

Third-party checks

No third-party reports yet.

Provenance

Signed by skilld at 4349410. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub yesterday.

Activeupdated 2 months ago

Capability

What it can do
Runs commands Reads files
All 6 allowed tools
Bash(gh:*)Bash(git:*)Bash(node:*)ReadGlobGrep
Other metadata
compatibility
{
  "requires": [
    {
      "mcp": "linear",
      "description": "Required for reading and updating Linear tickets during triage"
    },
    {
      "cli": "gh",
      "description": "Required for PR inspection and triage actions. Must be authenticated (gh auth login)"
    }
  ]
}

Topics

  • Testing
  • n8n
  • pull-request
  • community
  • cla
  • triage
  • linear
  • automation
  • github

README badge

README badge for n8n-io/n8n/community-pr-readiness-check

What it does

Validates community pull requests for the n8n workflow engine against CLA signature, title format, description completeness, test coverage, and code review comments, then routes approved PRs to the responsible Linear team or recommends closure. Targets the n8n contributor workflow and handles triage state transitions, auto-rejection screening, and related-issue cross-referencing.

Generated from the current SKILL.md.

Frequently asked

Does this skill work with GitHub Enterprise or only github.com?
It targets n8n-io/n8n on github.com. The skill uses hardcoded repo references and assumes the n8n repository structure, team ownership rules, and Linear integration specific to that instance.
What happens if a PR is already marked with triage:in-progress?
The skill bails out to avoid double-processing. It emits a one-line note and moves on. The user can manually clear the label and re-invoke if the previous run crashed.
Does this skill create new Linear tickets or only update existing ones?
It updates the existing Linear ticket linked via n8n-assistant's PR comment (GHC-XXXX). If no ticket exists (older PRs), it prompts the user whether to create one before triaging.
What checks does the skill run before marking a PR ready for review?
It verifies CLA signature, PR title format, description completeness against the template, test coverage for logic changes, and that cubic-dev-ai has no unresolved review comments. It also auto-rejects typo-only or unsanctioned new-node PRs.
Can this skill handle PRs from n8n's internal bots like n8n-cat-bot?
Yes. It detects internal bot authors and skips full review, instead relabeling the PR from community to n8n team and updating the linked Linear ticket appropriately (cancelling for n8n-cat-bot, routing to Dev Platform for aikido-autofix).

Generated from the current SKILL.md. These answers refresh after source changes.