From implement-lifecycle
Validate a PR against PR standards before requesting review. Checks branch naming, title, description, sizing, commits, and references. Triggers: /pr-check, check this PR, validate PR
npx claudepluginhub benjamcalvin/bootstraps --plugin implement-lifecycleThis skill uses the workspace's default tool permissions.
Pre-flight validation for PRs.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Pre-flight validation for PRs.
git branch --show-currentgh pr view $ARGUMENTS --json title,body,additions,deletions,changedFiles,commits,baseRefName,number 2>/dev/null || echo "NO_PR_FOUND"gh pr view $ARGUMENTS --comments 2>/dev/null || echo "NO_COMMENTS"git log --oneline main..HEADValidate the current PR against each standard below. If no PR number was provided and NO_PR_FOUND appears above, check only what can be validated locally (branch name, commits, diff size) and note that no PR exists yet.
For each check, output one of:
1. Branch Naming
Branch must match <type>/<short-description> where type is one of: feat, fix, refactor, docs, test, chore. Must be lowercase, hyphen-separated.
2. PR Title
Must match <type>: <imperative summary>. Type prefix should match branch type. Under 72 characters. No period at the end. Imperative mood ("Add", "Fix"), not past tense ("Added", "Fixed").
3. PR Description — Summary Must include 1-3 sentences explaining what the change does and why.
4. PR Description — Test Evidence Must include how the change was verified: test output, manual steps, or "covered by existing tests."
5. PR Sizing Check additions + deletions (excluding generated code, test fixtures, lock files if identifiable):
6. Commit Messages
Each commit message should follow <type>: <summary> format. No "WIP", "fixup", or "wip" commits.
7. References If the change relates to a GitHub issue, it should reference it with an appropriate keyword:
Closes #N / Fixes #N — only when this single PR fully completes the issuePart of #N — when the PR is one of several addressing the issueWARN if no references found (not all PRs need them, but flag for awareness). WARN if Closes #N is used but the PR appears to be a sub-task of a larger issue (e.g., the issue has multiple acceptance criteria and the PR only addresses some).
## PR Standards Check
| # | Check | Result | Notes |
|---|-------|--------|-------|
| 1 | Branch naming | PASS/WARN/FAIL | ... |
| 2 | PR title | PASS/WARN/FAIL | ... |
| 3 | Summary | PASS/WARN/FAIL | ... |
| 4 | Test evidence | PASS/WARN/FAIL | ... |
| 5 | Sizing | PASS/WARN/FAIL | ... |
| 6 | Commit messages | PASS/WARN/FAIL | ... |
| 7 | References | PASS/WARN/FAIL | ... |
**Result: X/7 passing, Y warnings, Z failures**
If there are failures, add a brief "Suggested Fixes" section listing what to change.