Back to skills
SkillHub ClubShip Full StackFull Stack

pr-file-review

Imported from https://github.com/jack-michaud/faire.

Packaged view

This page reorganizes the original catalog entry around fit, installability, and workflow context first. The original raw source lives below.

Stars
5
Hot score
82
Updated
March 20, 2026
Overall rating
C3.6
Composite score
3.6
Best-practice grade
B72.4

Install command

npx @skill-hub/cli install jack-michaud-faire-pr-file-review

Repository

jack-michaud/faire

Skill path: jack-software/skills/code-review/pr-file-review

Imported from https://github.com/jack-michaud/faire.

Open repository

Best for

Primary workflow: Ship Full Stack.

Technical facets: Full Stack.

Target audience: everyone.

License: Unknown.

Original source

Catalog source: SkillHub Club.

Repository owner: jack-michaud.

This is still a mirrored public skill entry. Review the repository before installing into production workflows.

What it helps with

  • Install pr-file-review into Claude Code, Codex CLI, Gemini CLI, or OpenCode workflows
  • Review https://github.com/jack-michaud/faire before adding pr-file-review to shared team environments
  • Use pr-file-review for development workflows

Works across

Claude CodeCodex CLIGemini CLIOpenCode

Favorites: 0.

Sub-skills: 0.

Aggregator: No.

Original source / Raw SKILL.md

---
name: Pull Request File Review
description: 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.
---

# 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.
pr-file-review | SkillHub