vellum-pr-readiness

Validates git branches for review readiness by checking hygiene, scope, tests, and Linear conventions.

1.2k|166|Updated Feb 7, 2026
One-click install
npx skills add https://github.com/vellum-ai/vellum-assistant --skill vellum-pr-readiness
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: vellum-pr-readiness
Source: https://github.com/vellum-ai/vellum-assistant/tree/main/.cursor/skills/vellum-pr-readiness
Command: npx skills add https://github.com/vellum-ai/vellum-assistant --skill vellum-pr-readiness

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Opening a pull request too early leads to noisy diffs, missing tests, leaked secrets, and unclear scope that slow down code review. This Skill runs a structured readiness checklist over your branch so blockers surface before reviewers see them.

Core Features & Use Cases

  • Git Hygiene Inspection: Reviews git status, staged and unstaged diffs, untracked files, and generated artifacts, and blocks commits containing .env files, credentials, tokens, or private keys.
  • Scope and Follow-Up Checks: Flags oversized branches for splitting into smaller PRs and identifies required migrations, documentation updates, and companion vellum-assistant-platform PRs.
  • Linear and Verification Conventions: Enforces Linear issue IDs in branches, commits, and PR bodies (Closes JARVIS-123 vs Part of JARVIS-123), and confirms focused tests and typechecks ran.
  • Use Case: Before opening a PR for a feature touching both UI and a data migration, ask the assistant to check readiness; it will recommend splitting the changes, verify tests ran, and generate a Summary/Test Plan/Risk PR body.

Quick Start

Ask the assistant to check whether the current branch is ready for a pull request before opening it.

Frequently Asked Questions about vellum-pr-readiness

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my branch is ready for a pull request?

Run the readiness checklist before opening a PR: inspect git status and diffs for unrelated changes, confirm no secrets are committed, verify focused tests ran, and ensure the PR body includes the Linear issue ID. The Skill surfaces blockers rather than polishing summaries.

How to split a large branch into smaller pull requests?

Identify unrelated UI, backend, migration, and infra changes in the diff, then separate them into individual reviewable branches. Each intermediate PR should use "Part of JARVIS-123" in its body, with the final PR using "Closes JARVIS-123".

What files should never be committed to a git branch?

Never commit `.env` files, credentials, tokens, private keys, or local workspace data. A `.env.example` file is acceptable only when it contains placeholder values rather than real secrets.

When does a change require a migration or documentation update?

A migration is required when persisted data or workspace formats change. Documentation updates are needed for significant architecture, service, or data-flow changes, and platform-affecting contracts or new feature flags require a companion vellum-assistant-platform PR.

What is the difference between Closes and Part of in Linear PR conventions?

Use "Closes JARVIS-123" for a single final PR that completes the issue. Use "Part of JARVIS-123" for intermediate PRs in a multi-PR plan so the issue stays open until all parts merge.