playbooks

home / skills / vercel / next.js / pr-status-triage

pr-status-triage skill

/.agents/skills/pr-status-triage

This skill helps you triage PR status and CI failures in Next.js projects by prioritizing blockers and reproducing locally.

npx playbooks add skill vercel/next.js --skill pr-status-triage

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
1.1 KB
---
name: pr-status-triage
description: >
  Triage CI failures and PR review comments using scripts/pr-status.js.
  Use when investigating failing CI jobs, flaky tests, or PR review feedback.
  Covers blocker-first prioritization (build > lint > types > tests),
  CI env var matching for local reproduction, and the Known Flaky Tests
  distinction.
---

# PR Status Triage

Use this skill when the user asks about PR status, CI failures, or review comments in the Next.js monorepo.

## Workflow

1. Run `node scripts/pr-status.js` (or `node scripts/pr-status.js <number>`).
2. Read generated files in `scripts/pr-status/`.
3. Prioritize blocking jobs first: build, lint, types, then test jobs.
4. Treat failures as real until disproven; check the "Known Flaky Tests" section before calling anything flaky.
5. Reproduce locally with the same mode and env vars as CI.

## Quick Commands

```bash
node scripts/pr-status.js
node scripts/pr-status.js <number>
```

## Detailed References

- [workflow.md](./workflow.md) - prioritization and common failure patterns
- [local-repro.md](./local-repro.md) - mode/env matching and isolation guidance

Overview

This skill automates triage of pull request status, CI failures, and review comments using the scripts/pr-status.js helper. It speeds investigation by generating a prioritized view of failing jobs, environment details for local reproduction, and a list of known flaky tests. Use it to decide what to fix first and how to reproduce issues reliably.

How this skill works

Run the script to produce a report directory containing job statuses, failure excerpts, and CI environment variables for the PR. The output highlights blocking jobs and annotates failures with flaky-test information when available. It also surfaces the CI mode and env var settings so you can replicate the failing run locally.

When to use it

  • A PR shows one or more failing CI jobs after a push
  • You need to prioritize which failures to fix first
  • You suspect a flaky test but need evidence
  • You want accurate env vars and mode to reproduce CI locally
  • You received review comments tied to CI or test failures

Best practices

  • Prioritize blocking categories: build, lint, types, then tests
  • Assume failures are real until the Known Flaky Tests list proves otherwise
  • Use the exact CI mode and env vars from the report when reproducing locally
  • Run the script with the PR number for focused output
  • Read generated files in the script output directory before posting status updates

Example use cases

  • A new commit causes the build job to fail; identify the failing step and reproduce locally with the same env
  • Intermittent test failures appear; check Known Flaky Tests before marking as flaky
  • A reviewer flags a types error reported by CI; locate the relevant job log and prioritize the fix
  • Multiple failing jobs exist; use the prioritized list to address blocking jobs first
  • You need to collect env vars and mode to create a minimal local reproduction

FAQ

How do I run the triage script for a specific PR?

Run node scripts/pr-status.js <number> to generate a report for that PR in the output directory.

What order should I fix failures in?

Fix blocking categories first: build, then lint, then types, and finally test jobs.

When can I mark a failing test as flaky?

Only after checking the Known Flaky Tests list and reproducing the failure locally with the same CI mode and env vars.