원클릭으로
pr-check
Validate a PR against PR standards before requesting review
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Validate a PR against PR standards before requesting review
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Full implementation lifecycle with adversarial review using subagents
Address PR review feedback and verify independently
Draft and create a GitHub issue from a description, investigation, or conversation context. Use when a problem is too large for a quick fix, when you want to propose a change for later, or when the user asks to "file an issue", "create an issue", "draft an issue", "open a ticket", or "log this for later". Also useful when another skill (like tune) determines a change is too large and needs to be tracked as an issue instead.
Merge a PR and update upstream GitHub issues with progress
Validate a PR against PR standards before requesting review
Health-check the LifeOS persona layer (files load, /chat matches the Telegram bots per persona, no personal values leak into committed persona files, frontmatter valid) and open every persona doc in Sublime for editing.
| name | pr-check |
| description | Validate a PR against PR standards before requesting review |
| argument-hint | ["pr-number"] |
Pre-flight validation for PR quality.
git branch --show-currentgh pr view $ARGUMENTS --json title,body,additions,deletions,changedFiles,commits,baseRefName,number 2>/dev/null || echo "NO_PR_FOUND"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. No issue numbers in the branch name.
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 Closes #N or Relates to #N. WARN if no references found (not all PRs need them, but flag for awareness).
8. Secrets & Sensitive Data This project is open-source. The diff MUST NOT contain any of the following. FAIL immediately if found:
sk-, ghp_, bot[0-9], xoxb-, Bearer , long hex/base64 strings assigned to credential variables). Tokens in test mocks/fixtures using obviously fake values are OK./Users/alice/, /home/username/). Relative paths and ~/ are OK. Paths in AGENTS.md, AGENTS.md, and documentation that describe the project setup are exempt.To check, read the full diff: !git diff main..HEAD -- ':!AGENTS.md' ':!AGENTS.md'
## 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 | ... |
| 8 | Secrets & sensitive data | PASS/WARN/FAIL | ... |
**Result: X/8 passing, Y warnings, Z failures**
If there are failures, add a brief "Suggested Fixes" section listing what to change.