القائمة
Review code changes against spec for drift and principle violations before PR submission. Use when user says "pre-pr review", "check against spec", "review my changes", "spec drift", "am I following the spec", or before creating a pull request.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create a GitHub pull request with proper issue linking and conventional commits. Use when user says "create pr", "submit pr", "open pull request", "push and create pr", or after pre-pr review passes.
Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale.
Design robust specs through principle-driven interviews, then create GitHub issues with sub-issue hierarchies. Use when starting a new feature, designing a solution, or when user says "let's spec this out", "design this feature", "create a spec".
Analyze coding agent session transcripts to improve existing skills or create new ones. Use when asked to improve a skill based on a session, or extract a new skill from session history.
Create new Claude Code skills. Use when user wants to create, update, or improve a skill that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
Create and manage GitHub issues with duplicate detection and hierarchy support. Use when creating issues, filing bugs, tracking tasks, managing sub-issues, or organizing parent/child relationships. Triggers on "create issue", "file bug", "track this", "sub-issue", "parent issue", "break down", "list sub-issues".
| name | pre-pr |
| description | Review code changes against spec for drift and principle violations before PR submission. Use when user says "pre-pr review", "check against spec", "review my changes", "spec drift", "am I following the spec", or before creating a pull request. |
Review code changes against the original spec to detect drift and principle violations.
Phase 1: Get Issue Context → Ask for issue number
Phase 2: Fetch Spec → Use gh-issues skill patterns
Phase 3: Get Code Changes → git diff main...HEAD
Phase 4: Quality Checks → Tests + breaking changes
Phase 5: Code Analysis → Spec drift + principles
Phase 6: Summary Report → Action items + follow-ups
If no issue provided: Ask user for the GitHub issue number this work relates to.
# Current issue
gh issue view <number> --json number,title,body,labels,state,url
# Check for parent (full spec)
gh api graphql -f query='{ repository(owner: "{owner}", name: "{repo}") {
issue(number: <number>) { parent { number title } }
} }'
# If parent exists, fetch it
gh issue view <parent-number> --json number,title,body
# List sibling sub-issues
gh sub-issue list <parent-number>
Present spec summary:
## Spec Context Loaded
Parent: #<parent> - <title>
Current: #<number> - <title>
Siblings: #<sib1>, #<sib2>
### Current Sub-issue Scope
<body>
### Parent Spec Summary
<Goals, Non-Goals, Technical Design, Acceptance Criteria>
# Changes against main
git diff main...HEAD --stat
git diff main...HEAD
# Uncommitted changes
git diff --stat
git diff
Present:
## Code Changes
Commits since main: <count>
Files changed: <count>
Changed files:
- <file1> (+X, -Y)
- <file2> (+X, -Y)
Identify new/modified code and check for corresponding tests:
find . -name "*test*" -o -name "*spec*" | grep -i <changed-file-pattern>
| Finding | Action |
|---|---|
| New function without test | ⚠️ Suggest adding test |
| Critical path untested | 🚨 Require test before PR |
Check for API/DB changes:
git diff main...HEAD --name-only | grep -i "migration\|schema"
| Change Type | Required Action |
|---|---|
| Removed API endpoint | Deprecation plan |
| Changed required params | Migration guide |
| DB column removed/renamed | Migration script |
Use AskUserQuestion for any issues found:
→ Read references/drift-analysis.md
For EACH drift found, ask user if intentional.
→ Read references/principles-review.md
Check: YAGNI, Simplicity, Boring Tech.
## Pre-PR Review Complete
### Test Coverage
- New code paths: <count> | With tests: <count> | Missing: <count>
### Breaking Changes
- API changes: [✓ None / ⚠ <count> detected]
- DB migrations: [✓ None / ⚠ <count> detected]
### Spec Drift Summary
- Total: <count> | Intentional: <count> | To address: <count>
### Principle Compliance
- YAGNI: [✓ / ⚠ issues]
- Simplicity: [✓ / ⚠ issues]
- Complexity: [✓ / ⚠ issues]
- Tech Choices: [✓ / ⚠ issues]
### Action Items Before PR
- [ ] <action>
### Follow-up Issues to Create
- [ ] <issue>
Execute approved actions (spec updates, new issues) using gh-issues skill.
After review passes, use the create-pr skill to create the pull request.
create-pr skill for actual PR creation