agentsclimarketplace

Paper audit

Skill kinhluan/skills/.agent-skills/paper-audit

Audit a research paper against its public codebase to detect mismatches between claims and implementation. Use when reviewing papers with code, verifying reproducibility, or checking for implementation gaps. Inspired by Feynman's /audit workflow.From its SKILL.md

Install
npx -y skills add kinhluan/skills --skill paper-audit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

9.4 KB, ~2.4k tokens by cl100k_base, as published. Nobody here has run it

Paper Audit

Claims in the paper must match code in the repository.

This skill audits research papers against their publicly available codebases to detect mismatches, missing implementations, and reproducibility issues. Inspired by Feynman's /audit workflow.

"Trust but verify." — Russian proverb


1. When to Audit

Audit when:

  • Reviewing a paper with an accompanying GitHub repository
  • Planning to build on someone's method (verify it works first)
  • Reviewing for a conference/journal (check reproducibility)
  • Teaching (show students what to look for)

Do NOT audit when:

  • No code is available (audit becomes impossible)
  • Paper is purely theoretical (no implementation to check)
  • You are the author (use internal-critique instead)

2. The Audit Protocol

Step 1 — Paper Claim Extraction

Extract all verifiable claims from the paper:

Claim IDSectionClaimVerifiable?
C1Method"We use Adam optimizer with lr=0.001"Yes
C2Method"Batch size is 256"Yes
C3Results"Achieves 95.2% accuracy on ImageNet"Yes
C4Method"Our attention mechanism reduces complexity to O(n)"Partial (need to read code)
C5Ablations"Removing component X drops performance by 3%"Yes

Claim types:

  • Hyperparameter: Learning rate, batch size, weight decay, architecture details
  • Architecture: Layer counts, dimensions, activation functions, connectivity
  • Data: Dataset version, preprocessing steps, augmentation pipeline
  • Metric: Reported numbers with confidence intervals
  • Ablations: Performance differences when components are removed

Step 2 — Code Mapping

For each verifiable claim, locate the corresponding code:

Paper Claim → Code Location → Verification Result

Example:
C1: "Adam optimizer, lr=0.001"
  → Code: train.py:45: optimizer = torch.optim.Adam(model.parameters(), lr=0.001)
  → Result: ✅ MATCH

C2: "Batch size is 256"
  → Code: config.yaml: batch_size: 128
  → Result: ❌ MISMATCH (paper says 256, code uses 128)

C3: "95.2% accuracy on ImageNet"
  → Code: README.md reports 94.8%
  → Result: ⚠️ DISCREPANCY (0.4% gap, possibly different eval protocol)

Where to look:

Claim TypeLikely Code Location
Hyperparametersconfig.yaml, args.py, train.py top-level constants
Architecturemodel.py, network.py, architecture/ folder
Data preprocessingdata.py, dataset.py, preprocess.py
Training looptrain.py, trainer.py, main.py
Evaluationeval.py, test.py, metrics.py
Ablationsablation.py, experiments/, scripts/

Step 3 — Mismatch Classification

SeverityTypeDescriptionExample
🔴 CriticalMissing implementationCode doesn't implement claimed methodPaper claims "novel attention mechanism" but code uses standard softmax
🔴 CriticalWrong hyperparametersKey hyperparameters differPaper reports lr=0.001 but code uses lr=0.01
🟡 MajorPartial implementationOnly part of the method is implementedMulti-scale feature extraction claimed but only single-scale in code
🟡 MajorDifferent evaluation protocolMetrics computed differentlyPaper uses top-5 accuracy, code computes top-1
🟡 MajorMissing ablationsClaimed ablations not in codePaper shows ablation table but no ablation scripts
🟢 MinorDocumentation mismatchREADME or comments wrongREADME says Python 3.8+ but code uses 3.10 syntax
🟢 MinorHardcoded valuesValues not configurableBatch size hardcoded instead of in config
🔵 NoteImplementation detailDifferent but equivalent approachPaper describes loop, code uses vectorized operation

Step 4 — Reproducibility Check

Attempt to run the code (if environment permits):

# 1. Environment setup
pip install -r requirements.txt  # Check: are all dependencies listed?

# 2. Data availability
# Check: is data downloadable? Is preprocessing script provided?

# 3. Run training
python train.py --config config.yaml  # Check: does it run without errors?

# 4. Run evaluation
python eval.py --checkpoint model.pth  # Check: can you reproduce reported numbers?

Reproducibility score:

ScoreCriteria
5/5Runs out-of-the-box, reproduces numbers exactly
4/5Runs with minor fixes, numbers within 0.5%
3/5Runs with significant fixes, numbers within 1-2%
2/5Runs but numbers don't match (>2% gap)
1/5Doesn't run, missing dependencies or data
0/5No code provided

3. Audit Report Template

## Paper Audit: [Paper Title] by [Authors]

**Paper:** [arXiv/DOI link]
**Code:** [GitHub/repo link]
**Audit Date:** YYYY-MM-DD
**Auditor:** [Name/Agent]

### Claim Verification Matrix

| ID | Claim | Code Location | Result | Notes |
|---|---|---|---|---|
| C1 | Adam, lr=0.001 | train.py:45 | ✅ Match | Exact match |
| C2 | Batch size 256 | config.yaml:3 | ❌ Mismatch | Code uses 128 |
| C3 | 95.2% ImageNet | README.md | ⚠️ Discrepancy | README reports 94.8% |

### Mismatches Found

#### 🔴 Critical (0 found)
[None / list]

#### 🟡 Major (1 found)
1. **Different batch size** (C2)
   - Paper: 256
   - Code: 128
   - Impact: Could affect convergence and final performance
   - Recommendation: Clarify which was used for reported results

#### 🟢 Minor (1 found)
1. **README outdated** (C3)
   - README reports 94.8% but paper claims 95.2%
   - Possibly different evaluation protocol or checkpoint

### Reproducibility Score: 3/5

**What worked:**
- Code structure is clean and modular
- Dependencies are mostly listed

**Blockers:**
- Missing preprocessing script for custom dataset
- Hardcoded paths in config files

**Time to reproduce:** Estimated 4-6 hours (with fixes)

### Recommendations

1. **For authors:** Update README with correct hyperparameters and results
2. **For users:** Use batch_size=128 for fair comparison, or ask authors which was used
3. **For reviewers:** Flag batch size discrepancy in review

### Verdict

- [ ] **Reliable** — Claims match code, reproducible
- [ ] **Mostly reliable** — Minor discrepancies, reproducible with fixes
- [x] **Use with caution** — Major discrepancies, needs clarification
- [ ] **Not reproducible** — Critical mismatches or missing code

4. Common Audit Patterns

Pattern 1: The "Cherry-picked" Result

Symptom: Paper reports best run, code shows multiple runs with variance.

Detection:

# In code: results/ folder has multiple runs
# run_1: 94.1%, run_2: 94.8%, run_3: 95.2%, run_4: 94.5%
# Paper reports: 95.2% (best run, not average)

Verdict: Not necessarily dishonest, but should report mean ± std.

Pattern 2: The "Missing Ablation"

Symptom: Ablation table in paper, no ablation code in repo.

Detection:

# Search for ablation scripts
find . -name "*ablation*" -o -name "*ablate*"
# No results found

Verdict: Major concern. How were ablation numbers computed?

Pattern 3: The "Different Method"

Symptom: Paper describes complex method, code uses simple baseline.

Detection:

# Paper: "We propose a novel hierarchical attention mechanism..."
# Code: model.py uses nn.MultiheadAttention (standard PyTorch)

Verdict: Critical mismatch. Method is not implemented as described.

Pattern 4: The "Undocumented Preprocessing"

Symptom: Results don't match, preprocessing steps differ.

Detection:

# Paper: "We normalize images to [0,1]"
# Code: transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225])

Verdict: Major concern. Different preprocessing → different results.


5. Tools for Auditing

Manual Audit

  • Read paper claims → Find code → Compare
  • Best for: Deep understanding, thorough verification
  • Time: 2-4 hours per paper

Semi-Automated Audit

  • Use grep / ripgrep to find claim keywords in code
  • Use diff to compare configs
  • Best for: Quick checks, large codebases
  • Time: 30-60 minutes per paper

Automated Audit (future)

  • Parse paper PDF for claims (NLP extraction)
  • Parse code for hyperparameters and architecture
  • Auto-compare and flag mismatches
  • Best for: Batch auditing, systematic reviews
  • Time: 5-10 minutes per paper (after setup)

6. Integration with Other Skills

This skill providesRelated skillFor deeper dive
Code verificationsota-surveyFind papers with code to audit
Reproducibility checkexperiment-trackingRun and compare experiments
Issue severityinternal-critiqueSeverity grading system
Paper qualitypublication-strategyDecide if paper is trustworthy enough to cite

References

What ships with it: 1 file

326 B alongside SKILL.md

Keep looking

Skills are one crate of 326,852. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.