referee-mock
Skill17 starsChanged 3 months agoMITView on GitHub
Mock R1 referee report (methodologist, theorist, area-expert, or editor persona) calibrated to the target journal — summary, major and minor comments, honest recommendation. Use when a draft is near submission-ready or the user asks how reviewers will react.
In this repository38 other files it gives its agents.
- abstract-shotgunSkill
- analyzeSkill
- archiveSkill
- carefulSkill
- coauthor-reviewSkill
- codebookSkill
- cover-letterSkill
- data-acquireSkill
- data-cleanSkill
- design-researchSkill
- draft-sectionSkill
- freezeSkill
- guardSkill
- hypothesis-designSkill
- idea-shotgunSkill
- identification-reviewSkill
- journal-fitSkill
- learnSkill
- lit-mapSkill
- llm-checklistSkill
- mstack-initSkill
- mstack-upgradeSkill
- paper-statusSkill
- pdf-ingestSkill
- power-analysisSkill
- preregisterSkill
- r-and-rSkill
- research-questionSkill
- results-auditSkill
- retroSkill
- robustnessSkill
- scope-challengeSkill
- submission-packSkill
- survey-buildSkill
- theory-buildSkill
- title-shotgunSkill
- unfreezeSkill
- vizSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
Stage: write (pre-submission) · Voice: referee, anchored to voice.reviewer_style in .mstack/config.yaml
- Distinctive: line 18
When every section exists and the draft is "submission-ready": the last line of defense before real reviewers.
- Very specific: line 33
Reviewer style: If voice.reviewer_style names an installed skill, use it for voice, tone, and structure.
- Distinctive: line 49
Sycophancy: No major comment means you did not read hard enough.
≈ “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.
Files
/mstack:referee-mock
Stage: write (pre-submission) · Voice: referee, anchored to voice.reviewer_style in .mstack/config.yaml
When every section exists and the draft is "submission-ready": the last line of defense before real reviewers.
$ARGUMENTS picks the persona (default methodologist; unrecognized → default):
| Persona | Presses hardest on |
methodologist | Identification, SE clustering, robustness, multiple comparisons, sample restrictions, attrition |
theorist | Theoretical contribution, mechanism vs. correlation, engagement with the canonical 3–5 papers, scope conditions |
area-expert | Empirical / case knowledge, measurement validity, omitted contextual factors, source reliability |
editor | Contribution per page, fit with the target journal, clarity, headline-vs-evidence proportionality, length |
Procedure
- Load
paper/main.tex(ormain.qmd) and every file underpaper/sections/;output/tables/andoutput/figures/to verify claims in the prose;.mstack/config.yamlfor the target journal, which sets the bar. - Prior reports in
.mstack/referee-cache/: if the same persona reviewed an earlier draft, say explicitly what improved and what did not. - Reviewer style. If
voice.reviewer_stylenames an installed skill, use it for voice, tone, and structure; otherwise${CLAUDE_PLUGIN_ROOT}/references/referee-report-conventions.md. Persona ammunition.methodologist: read the design section of${CLAUDE_PLUGIN_ROOT}/references/identification-threats.mdand raise every threat the paper does not address, plus the sensitivity analysis it does not report.theorist: the rival-mechanisms table in.mstack/theory.md, and whether the paper tests any of them.editor: the referee complaints table in${CLAUDE_PLUGIN_ROOT}/references/writing-conventions.md.area-expert: the data-source pitfalls in${CLAUDE_PLUGIN_ROOT}/references/polisci-data-sources.mdfor the sources the paper uses. - Write the report in the standard structure:
- Summary (one paragraph) — what the paper does and what it claims.
- Major comments (3–6) — substantive issues that change the headline if unaddressed.
- Minor comments (5–15) — clarity, presentation, missing citations, table / figure issues.
- Recommendation —
Reject,Major revisions,Minor revisions, orAccept. Be the reviewer the author fears, not the one they hope for.
- Save to
.mstack/referee-cache/referee-mock-<persona>-<YYYY-MM-DD>.mdwith a header: persona, target journal, draft commit hash (git rev-parse --short HEADif a git repo) or word count, date.
Outputs
.mstack/referee-cache/referee-mock-<persona>-<date>.md.- Summary block: top 3 major comments, the recommendation, and the persona to run next.
Anti-patterns
- Sycophancy. No major comment means you did not read hard enough.
- Generic comments. "Could use more theory" is useless; cite the section, line, or table.
- Breaking persona. The methodologist does not critique prose style; the editor does not propose identification strategies.
Next
Major revisions or worse → /mstack:results-audit and /mstack:identification-review before revising. After revision, re-run with a different persona to triangulate.
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
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.