Use when working with Harvard Law Review (HLR) student editors after an offer — the intensive substantive and technical edit, the cite-check / source-pull, and author responsiveness. Manages the relationship and process; it does not run the pre-offer placement (hlr-placement-strategy) or the author-side cite apparatus build (hlr-footnotes-and-cite-check).
Scanned 9/5/2026
Install to Claude Code
npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill hlr-student-editor-review --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Hlr Student Editor Review?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/brycewang-stanford-hlr-student-editor-review)More formats (shields.io, HTML) on the badges page.
---
name: hlr-student-editor-review
description: Use when working with Harvard Law Review (HLR) student editors after an offer — the intensive substantive and technical edit, the cite-check / source-pull, and author responsiveness. Manages the relationship and process; it does not run the pre-offer placement (hlr-placement-strategy) or the author-side cite apparatus build (hlr-footnotes-and-cite-check).
---
# Student-Editor Review (hlr-student-editor-review)
HLR is **student-edited**: once your piece is accepted, smart law students — not anonymous faculty peers
— run an **intensive edit**. Expect substantive pushback on the argument, heavy technical editing, and a
full **cite-check / source-pull** in which editors verify every footnote against the actual source. This
is more hands-on than peer review at most journals. This skill helps you work *with* the editors and
protect your argument while clearing the process.
## When to trigger
- You have an offer and the editing process is beginning
- Editors sent a marked-up draft, queries, or a source-pull request
- You disagree with an edit and need to decide how to respond
- A deadline for returning the edit or sources is approaching
## What the HLR edit involves
| Stage | What editors do | What they need from you |
|-------|-----------------|--------------------------|
| Substantive edit | Press the argument, flag gaps, ask for clarification or support | Defend, clarify, or revise — engage on the merits |
| Technical / line edit | Tighten prose, enforce house style and Bluebook | Approve or push back on specific changes |
| **Cite-check / source-pull** | Verify **every footnote** against the actual source | Provide pulled sources or exact pincites on demand, fast |
| Page proofs | Final formatting and corrections | Careful, timely proof review |
## The source-pull (the distinctive demand)
HLR editors will **pull every source** and confirm that each footnote actually supports the proposition,
that quotations are accurate, and that pincites are correct. To survive it without pain:
1. **Be pull-ready before you submit.** Keep a copy of every cited source with the cited page marked
(build this in `hlr-footnotes-and-cite-check`).
2. **Answer queries precisely.** When an editor says "source does not support proposition," either point
to the exact page that does, or revise the claim — do not argue around it.
3. **Turn sources around fast.** The edit runs on a schedule; slow responses stall the whole piece.
4. **Flag anything you cannot source.** If a proposition has no clean support, fix it now, not at proof.
## Working with student editors (relationship craft)
- **Treat editors as collaborators, not obstacles.** They are improving the piece and protecting the
journal's accuracy; engaging in good faith makes substantive disagreements easier to win.
- **Pick your battles.** Concede style and Bluebook calls; defend the argument and your voice where it
matters, with reasons.
- **Respond on the merits.** "I'm the expert" loses; "the source on page X supports this because…" wins.
- **Be responsive and on time.** Responsiveness is noticed and reciprocated; it is also how the piece
stays on the publication calendar.
## Checklist
- [ ] Every cited source kept and pull-ready with the cited page marked
- [ ] Editor queries answered with exact pincites or honest revisions
- [ ] Style/Bluebook edits conceded; argument defended with reasons
- [ ] Sources and edits returned by the deadline
- [ ] Any unsupportable proposition fixed before proofs
- [ ] Tone collaborative throughout
## Anti-patterns
- Treating the edit as an attack and stonewalling editors
- Fighting every line edit and Bluebook fix instead of conceding the small stuff
- "Trust me, I'm the author" responses to source-pull queries
- Slow turnarounds that stall the piece and annoy the editing team
- Discovering an unsourceable claim at the page-proof stage
## Output format
```
【Stage】substantive / technical / source-pull / proofs
【Open queries】count + the hard ones
【Source-pull readiness】all sources pullable with marked pincites? [Y/N]
【Battles】what to concede vs. defend (with reasons)
【Deadline】next return date
【Next】hlr-revision-and-editing (work the edit cycle to completion)
```
## Supplementary resources
- [`../../resources/official-source-map.md`](../../resources/official-source-map.md) — HLR organization, student-edited model
- [`../../resources/external_tools.md`](../../resources/external_tools.md) — citators and source-management tools for the pull
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!