vellum-pr-readiness

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

1|Updated Mar 30, 2026
One-click install
npx skills add https://github.com/Logarn/Worklin-ai --skill vellum-pr-readiness-logarn
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: vellum-pr-readiness
Source: https://github.com/Logarn/Worklin-ai/tree/main/.cursor/skills/vellum-pr-readiness
Command: npx skills add https://github.com/Logarn/Worklin-ai --skill vellum-pr-readiness-logarn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Opening a pull request without checking branch hygiene, scope, and verification leads to noisy reviews, leaked secrets, and missing migrations or documentation. This Skill runs a structured readiness audit before a PR is created. ## Core Features & Use Cases - Git Hygiene Inspection: Reviews git status, staged and unstaged diffs, untracked files, and blocks committing secrets like .env files, tokens, or private keys. - Scope and Follow-Up Checks: Flags oversized branches for splitting and identifies required migrations, docs updates, and companion vellum-assistant-platform PRs. - Linear and PR Conventions: Enforces Linear issue IDs in branches and PR bodies (Closes JARVIS-123 vs Part of JARVIS-123) and provides a compact Summary/Test Plan/Risk PR template. - Use Case: Before opening a PR for a multi-package feature, run this Skill to confirm tests and typechecks ran, unrelated changes are excluded, and the PR body links the correct Linear issue. ## Quick Start Ask the assistant to check whether the current branch is ready for a pull request using the vellum-pr-readiness checklist.

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 a readiness check that inspects git status for unrelated or untracked changes, reviews staged and unstaged diffs, confirms no secrets are committed, and verifies focused tests and typechecks ran for the changed code.

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 independent reviewable branches. Each PR should be scoped to one concern so reviewers can approve changes incrementally.

What files should never be committed to a git repository?▼

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.

How do I link a Linear issue in a pull request?▼

Include the Linear issue ID in the branch name, commit body, and PR body. Use "Closes JARVIS-123" for a single final PR and "Part of JARVIS-123" for intermediate PRs in a multi-PR plan.

When does a code change require a database migration or docs update?▼

A migration is needed when persisted data or workspace formats change. Documentation updates are required for significant architecture, service, or data-flow changes, and platform-affecting contracts may need a companion repo PR.