agentleFS
maxwell2732maxwell2732/claudecode-research-harness-workflow/skills/research-harness-review/SKILL.md

research-harness-review

Skill42 starsChanged 6 days agoMITView on GitHub

RES: Read-only review of research outputs. Checks identification, model spec, numerical accuracy, causal claims, reproducibility. Produces review_report.md with APPROVE/REQUEST_CHANGES/BLOCK verdict. Trigger: review research, check results, review analysis, verify outputs. Do NOT load for: cleaning, execution, release, setup, audit, planning.

The file

Show its rules and text

We split this skill into the rules it gives an agent

22 rules. About 0 are common, 13 are distinctive, and 9 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read analysis_plan.md. If it does not exist, stop.

    line 37
  2. Very specific:

    Read study_spec.md, reports/data_audit_report.md, reports/data_cleaning_report.md, and reports/merge_report.md (if it exists).

    line 40
  3. Very specific:

    Read study_spec.md §2 (identification strategy).

    line 48
  4. Distinctive:

    Read the log file

    line 75
  5. Distinctive:

    Read the output file (table or figure metadata)

    line 76
  6. Very specific:

    If a number appears in the output file but not in the log: flag as unverified

    line 78
  7. Distinctive:

    Do not verify numbers by re-running scripts.

    line 82
  8. Distinctive:

    Read the cleaning report row counts

    line 86
  9. Distinctive:

    Read the log files for each analysis task

    line 87
  10. Distinctive:

    Verify that the N reported in analysis logs matches the expected N given the cleaning report and sample restrictions

    line 88
  11. Very specific:

    Read any interim outputs, table notes, or text summaries (if present in output/ or reports/).

    line 93
  12. Very specific:

    Check that it carries an identification strength tag ([descriptive], [correlational], [quasi-experimental: ...], [experimental])

    line 97
  13. Distinctive:

    Do not rewrite weak evidence as strong causal evidence.

    line 101
  14. Distinctive:

    If any citations appear in output text: note that citation accuracy cannot be verified by this skill and flag for manual check

    line 114
  15. Very specific:

    If verdict is REQUEST_CHANGES or BLOCK:

    line 155
  16. Distinctive:

    Do not run any script or Bash command

    line 167
  17. Distinctive:

    Do not edit any script, data file, log, or output file

    line 168
  18. Distinctive:

    Do not approve a result that cannot be traced to a log file

    line 169
  19. Distinctive:

    Do not rewrite weak causal evidence as strong causal evidence in the review report

    line 170
  20. Very specific:

    Do not produce APPROVE when any critical finding exists

    line 171
  21. Distinctive:

    All findings are documented with location and required action

    line 177
  22. Very specific:

    If verdict is APPROVE:

    line 193

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Research Harness Review

Perform an independent, read-only review of research outputs before release.

This skill reads existing scripts, logs, and outputs. It does not run code. It does not edit scripts or data. It produces a structured review report with a verdict.

This skill runs after /research-harness-work and before /research-harness-release.

Quick Reference

InputAction
/research-harness-reviewFull review of all cc:done tasks in analysis_plan.md
/research-harness-review --quickAbbreviated review: identification + numerical accuracy only
/research-harness-review --task 2.1Review a single task

Pre-flight Checks

  1. Read analysis_plan.md. If it does not exist, stop.
  2. Confirm at least one task has status cc:done. If none, report that no completed tasks exist to review.
  3. List all cc:done tasks. These are the review scope.
  4. Read study_spec.md, reports/data_audit_report.md, reports/data_cleaning_report.md, and reports/merge_report.md (if it exists).

Procedure

This skill is read-only throughout. No Bash commands, no script execution, no file writes except the review report.

Step 1 — Identification credibility review

Read study_spec.md §2 (identification strategy).

For each main model task in analysis_plan.md, check:

  • Does the estimator used in the script match the identification strategy in the study spec?
  • Is the key identification assumption stated in the script header or task description?
  • Is any falsification or placebo test present in the plan?
  • For DiD: is there a pre-trend check task?
  • For IV: is the instrument defined and the exclusion restriction described?
  • For RD: is bandwidth selection documented?

Assign one of: strong / moderate / weak / insufficient

insufficient identification immediately produces REQUEST_CHANGES. Do not write findings as minor if the identification is insufficient for the causal claim being made.

Step 2 — Model specification alignment

For each cc:done analysis task:

  • Read the script
  • Compare the estimator, outcome variable, covariates, sample restrictions, and fixed effects to study_spec.md §4 and §5
  • Flag any deviation as: minor (changes that do not affect the main result), major (changes that affect the result), or critical (changes that contradict the approved study design)

Step 3 — Numerical accuracy check

For each cc:done task with an output file:

  • Read the log file
  • Read the output file (table or figure metadata)
  • For each key number that would appear in a paper (main coefficient, standard error, sample size, p-value, mean): confirm it appears in the log
  • If a number appears in the output file but not in the log: flag as unverified

An unverified number is a critical finding if it will appear in the final reported results.

Do not verify numbers by re-running scripts. Only read existing logs and outputs.

Step 4 — Sample construction check

  • Read the cleaning report row counts
  • Read the log files for each analysis task
  • Verify that the N reported in analysis logs matches the expected N given the cleaning report and sample restrictions
  • Flag any discrepancy as: minor (small difference with a plausible explanation), major (large unexplained difference), or critical (N is clearly wrong)

Step 5 — Causal claim assessment

Read any interim outputs, table notes, or text summaries (if present in output/ or reports/).

For every causal claim found:

  • Record the claim text and its location
  • Check that it carries an identification strength tag ([descriptive], [correlational], [quasi-experimental: ...], [experimental])
  • Assess whether the tag is appropriate given the design
  • Flag claims that overstate causal strength as major findings

Do not rewrite weak evidence as strong causal evidence. If the evidence is correlational, the claim must be correlational.

Step 6 — Data cleaning completeness check

  • Confirm reports/data_cleaning_report.md exists and its verification section is PASS
  • Confirm reports/merge_report.md exists (if merges were performed) and all entries have pre/post row counts
  • Confirm data/raw/ was not modified (if git status data/raw/ or equivalent is available from prior logs, read it)
  • Flag any incompleteness as a finding

Step 7 — Hallucination and fabrication check

  • Confirm no result is claimed without a corresponding log file
  • Confirm no script produces a hardcoded numerical result (i.e., check that output values are computed, not assigned as literals)
  • If any citations appear in output text: note that citation accuracy cannot be verified by this skill and flag for manual check

Step 8 — Write review_report.md

Copy templates/review_report.md to reports/review_report.md and fill in all sections from Steps 1–7.

Verdict rules:

ConditionVerdict
No critical or major findingsAPPROVE
One or more major findings (but no critical)REQUEST_CHANGES
One or more critical findingsBLOCK
Identification is insufficient for the causal claims madeBLOCK
Any result cannot be traced to a logBLOCK

BLOCK is a stronger form of REQUEST_CHANGES. It means the research cannot be released in any form until the finding is resolved.

Step 9 — Report verdict

Print a review summary:

Research Harness Review — Complete

Tasks reviewed: N
Scope: [task IDs]

Identification credibility: strong / moderate / weak / insufficient
Numerical accuracy: all verified / N unverified
Causal claims: all appropriate / N overstated

Critical findings: N
Major findings: N
Minor findings: N

Verdict: APPROVE / REQUEST_CHANGES / BLOCK

Review report: reports/review_report.md

If verdict is REQUEST_CHANGES or BLOCK:

Required actions before /research-harness-release:
1. [Finding 1 — required action]
2. [Finding 2 — required action]

Return to /research-harness-work to re-execute affected tasks, then re-run /research-harness-review.

Forbidden Actions

  • Do not run any script or Bash command
  • Do not edit any script, data file, log, or output file
  • Do not approve a result that cannot be traced to a log file
  • Do not rewrite weak causal evidence as strong causal evidence in the review report
  • Do not produce APPROVE when any critical finding exists

Evidence Requirements

  • reports/review_report.md exists with all sections populated
  • Verdict is one of: APPROVE, REQUEST_CHANGES, BLOCK
  • All findings are documented with location and required action

Completion Criteria

  • All cc:done tasks reviewed
  • Identification credibility assessed
  • Model specification checked against study spec
  • Numerical accuracy checked (each key number traced to a log)
  • Sample N checked
  • Causal claims assessed with identification tags
  • Data cleaning completeness confirmed
  • reports/review_report.md written
  • Verdict printed

Handoff to Stage 7

If verdict is APPROVE:

Review passed. Run /research-harness-release to package the replication archive.

If verdict is REQUEST_CHANGES or BLOCK:

Return to /research-harness-work to resolve the findings listed in reports/review_report.md. After re-executing affected tasks, run /research-harness-review again. Do not run /research-harness-release until the verdict is APPROVE.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.