pre-pr

スター0

フォーク0

更新日2026年1月7日 09:00

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 ページを確認してインストールできます。

ソース

ainergiz

ainergiz/mac-setup-guide

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Pre-PR Spec Compliance Review

Review code changes against the original spec to detect drift and principle violations.

What This Does

Detect spec drift - did implementation deviate from plan?
Check test coverage - does new code have tests?
Detect breaking changes - API/DB changes that need coordination
Check principle compliance - YAGNI, simplicity, etc.
Offer remediation for issues found

Workflow

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

Phase 1: Get Issue Context

If no issue provided: Ask user for the GitHub issue number this work relates to.

Phase 2: Fetch Spec Context

# 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>

Phase 3: Get Code Changes

# 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)

Phase 4: Quality Checks

Test Coverage

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

Breaking Changes

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:

Options: ["Fix now", "Explain why acceptable", "Create follow-up issue"]

Phase 5: Code Analysis

Spec Drift

→ Read references/drift-analysis.md

For EACH drift found, ask user if intentional.

Principle Compliance

→ Read references/principles-review.md

Check: YAGNI, Simplicity, Boring Tech.

Phase 6: Summary Report

## 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.

Notes

Be strict about flagging drift - let user decide if acceptable
Use AskUserQuestion for every drift/violation
Don't auto-fix - present options, let user decide
This is review only - use create-pr skill for actual PR creation

このリポジトリの他の Skills

同じリポジトリ

create-pr

ainergiz/mac-setup-guide

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.

2026-01-070

pdf

ainergiz/mac-setup-guide

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.

2026-01-070

spec-design

ainergiz/mac-setup-guide

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".

2026-01-070

improve-skill

ainergiz/mac-setup-guide

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.

2026-01-060

skill-creator

ainergiz/mac-setup-guide

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.

2026-01-060

gh-issues

ainergiz/mac-setup-guide

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".

2026-01-060

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.

Pre-PR Spec Compliance Review

Review code changes against the original spec to detect drift and principle violations.

What This Does

Detect spec drift - did implementation deviate from plan?
Check test coverage - does new code have tests?
Detect breaking changes - API/DB changes that need coordination
Check principle compliance - YAGNI, simplicity, etc.
Offer remediation for issues found

Workflow

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

Phase 1: Get Issue Context

If no issue provided: Ask user for the GitHub issue number this work relates to.

Phase 2: Fetch Spec Context

# 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>

Phase 3: Get Code Changes

# 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)

Phase 4: Quality Checks

Test Coverage

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

Breaking Changes

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:

Options: ["Fix now", "Explain why acceptable", "Create follow-up issue"]

Phase 5: Code Analysis

Spec Drift

→ Read references/drift-analysis.md

For EACH drift found, ask user if intentional.

Principle Compliance

→ Read references/principles-review.md

Check: YAGNI, Simplicity, Boring Tech.

Phase 6: Summary Report

## 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.

Notes

Be strict about flagging drift - let user decide if acceptable
Use AskUserQuestion for every drift/violation
Don't auto-fix - present options, let user decide
This is review only - use create-pr skill for actual PR creation