بنقرة واحدة
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.