Pull Request File Review

Identify and flag unnecessary test artifacts and temporary files in pull requests. Use when reviewing pull requests to ensure only production-relevant files are committed.

7 stars

Best use case

Pull Request File Review is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Identify and flag unnecessary test artifacts and temporary files in pull requests. Use when reviewing pull requests to ensure only production-relevant files are committed.

Teams using Pull Request File Review should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/pr-file-review/SKILL.md --create-dirs "https://raw.githubusercontent.com/jack-michaud/faire/main/jack-software/skills/code-review/pr-file-review/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/pr-file-review/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How Pull Request File Review Compares

Feature / AgentPull Request File ReviewStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Identify and flag unnecessary test artifacts and temporary files in pull requests. Use when reviewing pull requests to ensure only production-relevant files are committed.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Pull Request File Review

## Overview

Review pull request files to identify unnecessary test artifacts, temporary files, and non-production code based on naming patterns, locations, and usage.

## When to Use

- Reviewing pull requests before approval
- Files with test-related names (testresults.md, test_output.csv)
- Temporary scripts or data files in the changeset
- Before merging to ensure only production-relevant files are included

## Process

### 1. Identify Suspicious Files

Look for files matching these patterns:
- `test*.md`, `*results.md`, `*output.md` - Test result documentation
- `test_*.csv`, `*_test_data.csv` - Test data files
- `scratch.py`, `temp.py`, `debug.py` - Temporary scripts
- `output.txt`, `results.json`, `debug.log` - Output/log files
- Files in root directory that don't match project conventions

### 2. Evaluate File Necessity

For each suspicious file, ask:

**Location Analysis:**
- Is it in a test directory? (If yes, likely legitimate)
- Is it in a documentation directory with other docs? (If yes, likely legitimate)
- Is it in the project root or random location? (Red flag)

**Usage Analysis:**
- Is the file imported/referenced in production code?
- Is it required by tests that are committed?
- Is it part of CI/CD configuration?
- Does it have a clear purpose in the project structure?

**Naming Convention:**
- Does the name match the project's file naming conventions?
- Is it clearly temporary? (scratch, temp, test, output, debug)

### 3. Flag or Approve

**Flag for removal if:**
- File appears to be a one-off test artifact
- Name suggests temporary/debug purpose
- Not referenced anywhere in the codebase
- Located in an unusual place for its type

**Approve if:**
- File is referenced in production code
- Part of the test suite infrastructure
- Documented purpose in project structure
- Follows project conventions

### 4. Provide Feedback

When flagging files:
```
🚫 Unnecessary: `path/to/file.ext`
Reason: [Test artifact/temporary script/etc.]
Evidence: [Not referenced/unusual location/temporary naming]
Recommendation: Remove from PR or relocate
```

## Examples

### Example 1: Test Results File

**Context**: PR includes `testresults.md` in project root

**Application**:
1. Location: Root directory (suspicious)
2. Naming: "testresults" indicates test artifact
3. Search: `grep -r "testresults.md"` finds no references
4. Decision: Flag for removal

**Outcome**:
```
🚫 Unnecessary: `testresults.md`
Reason: Test artifact in root directory
Recommendation: Remove from PR
```

### Example 2: Test Data Referenced in Tests

**Context**: PR includes `tests/fixtures/sample_data.csv`

**Application**:
1. Location: `tests/fixtures/` (appropriate)
2. Naming: Follows fixture convention
3. Search: Referenced in `tests/test_parser.py`
4. Decision: Approve

**Outcome**: ✅ Necessary test fixture

### Example 3: Temporary Debug Script

**Context**: PR includes `debug_api.py` in root

**Application**:
1. Location: Root directory (suspicious)
2. Naming: "debug" indicates temporary purpose
3. Search: No imports found
4. Decision: Flag for removal

**Outcome**:
```
🚫 Unnecessary: `debug_api.py`
Reason: Temporary debug script in root
Recommendation: Remove from PR or add to .gitignore if needed locally
```

### Example 4: Configuration File

**Context**: PR includes `test_config.yaml`

**Application**:
1. Location: Root directory
2. Naming: Contains "test" but may be configuration
3. Search: Referenced in `tests/conftest.py`
4. Documentation: Mentioned in testing README
5. Decision: Approve

**Outcome**: ✅ Legitimate test configuration

## Anti-patterns

- ❌ **Don't**: Flag every file with "test" in the name
  - ✅ **Do**: Analyze context, location, and usage

- ❌ **Don't**: Approve files just because they're small
  - ✅ **Do**: Apply consistent criteria regardless of file size

- ❌ **Don't**: Require deep code analysis for obvious artifacts
  - ✅ **Do**: Use file name and location as primary signals

- ❌ **Don't**: Flag files without checking references first
  - ✅ **Do**: Search the codebase for imports/references before flagging

## Testing This Skill

To validate this skill:

1. **Create test PR with mixed files:**
   - `testresults.md` in root (should flag)
   - `tests/fixtures/data.csv` referenced in tests (should pass)
   - `scratch.py` in root (should flag)
   - Legitimate config with test-like name (should pass after analysis)

2. **Apply skill systematically:**
   - Follow the 4-step process for each file
   - Document reasoning for each decision

3. **Verify accuracy:**
   - All flagged files should be unnecessary
   - No legitimate files should be flagged
   - Feedback should be clear and actionable

## Quick Reference Commands

```bash
# List all files in PR
git diff --name-only main...HEAD

# Check if file is referenced in codebase
grep -r "filename.ext" --exclude-dir=.git

# Search for imports (Python example)
grep -r "from.*filename import\|import.*filename" .

# Find test-like files
find . -name "*test*" -o -name "*debug*" -o -name "*temp*" -o -name "*scratch*"
```

---

**Remember**: Catch obvious artifacts without creating friction. When uncertain, ask the author.

Related Skills

stacked-pr-review

7
from jack-michaud/faire

Use when addressing PR review comments on stacked jj branches. Triggered by phrases like "address review comments", "fix PR feedback", "respond to review on stacked branch", or "update the PR with reviewer suggestions".

SOLID Principles Code Review

7
from jack-michaud/faire

Review Python code for adherence to SOLID principles (SRP, OCP, LSP, ISP, DIP). Use when reviewing Python code for maintainability, testability, and design quality.

Python Code Review with Modern Typing

7
from jack-michaud/faire

Review Python code ensuring strict type safety with Python 3.12+ conventions. Use when reviewing Python code, writing new Python code, or refactoring existing Python code.

Prompt Brevity Review

7
from jack-michaud/faire

Review AI prompts and instructions for conciseness and clarity. Use when reviewing skills, CLAUDE.md, slash commands, or any LLM prompt content.

Code Review Orchestrator

7
from jack-michaud/faire

Delegate specialized reviews to subagents and synthesize their findings. Use when reviewing code.

Ticket Workflow

7
from jack-michaud/faire

Autonomous ticket-to-production lifecycle with promptlet-driven phases. Use when executing /ticket commands or working on ticket-driven development.

setup-sprite

7
from jack-michaud/faire

Set up a reproducible remote dev environment using sprites with credential-free git sync. Use when user asks to "set up a sprite", "create a remote dev environment", "use sprites", or mentions wanting a reproducible remote environment for a project.

Writing python services

7
from jack-michaud/faire

Writing a class with encapsulated logic that interfaces with an external system. Logging, APIs, etc.

Python Code Style

7
from jack-michaud/faire

Use when writing python code. Can be used for code review.

Plan

7
from jack-michaud/faire

My planning skill that has additional instructions. Always use when entering plan mode.

Modal

7
from jack-michaud/faire

No description provided.

merging-pr-stack

7
from jack-michaud/faire

Use when merging a stack of stacked PRs with jj. Triggered by phrases like "merge the PR stack", "merge the stacked PRs", "land these PRs", or "merge the stack into main".