npx claudepluginhub jack-michaud/faire --plugin jack-softwareWant just this skill?
Then install: npx claudepluginhub u/[userId]/[slug]
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.
This skill uses the workspace's default tool permissions.
TEST-RESULTS.mdexamples/example-1-obvious-artifacts/expected.mdexamples/example-1-obvious-artifacts/input.mdexamples/example-1-obvious-artifacts/scenario.mdexamples/example-2-ambiguous-files/expected.mdexamples/example-2-ambiguous-files/input.mdexamples/example-2-ambiguous-files/scenario.mdexamples/example-3-legitimate-test-files/expected.mdexamples/example-3-legitimate-test-files/input.mdexamples/example-3-legitimate-test-files/scenario.mdPull 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 documentationtest_*.csv,*_test_data.csv- Test data filesscratch.py,temp.py,debug.py- Temporary scriptsoutput.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:
- Location: Root directory (suspicious)
- Naming: "testresults" indicates test artifact
- Search:
grep -r "testresults.md"finds no references - 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:
- Location:
tests/fixtures/(appropriate) - Naming: Follows fixture convention
- Search: Referenced in
tests/test_parser.py - Decision: Approve
Outcome: ā Necessary test fixture
Example 3: Temporary Debug Script
Context: PR includes debug_api.py in root
Application:
- Location: Root directory (suspicious)
- Naming: "debug" indicates temporary purpose
- Search: No imports found
- 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:
- Location: Root directory
- Naming: Contains "test" but may be configuration
- Search: Referenced in
tests/conftest.py - Documentation: Mentioned in testing README
- 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:
-
Create test PR with mixed files:
testresults.mdin root (should flag)tests/fixtures/data.csvreferenced in tests (should pass)scratch.pyin root (should flag)- Legitimate config with test-like name (should pass after analysis)
-
Apply skill systematically:
- Follow the 4-step process for each file
- Document reasoning for each decision
-
Verify accuracy:
- All flagged files should be unnecessary
- No legitimate files should be flagged
- Feedback should be clear and actionable
Quick Reference Commands
# 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.
Similar Skills
Activates when the user asks about AI prompts, needs prompt templates, wants to search for prompts, or mentions prompts.chat. Use for discovering, retrieving, and improving prompts.