Use when working through the Harvard Law Review (HLR) post-acceptance editing cycle — successive substantive and technical edit rounds, responding to editor markups, and page proofs to publication. Drives the edit cycle to completion; it does not manage the offer/expedite phase (hlr-placement-strategy) or the first editor handshake (hlr-student-editor-review).
Scanned 9/5/2026
Install to Claude Code
npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill hlr-revision-and-editing --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Hlr Revision And Editing?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/brycewang-stanford-hlr-revision-and-editing)More formats (shields.io, HTML) on the badges page.
---
name: hlr-revision-and-editing
description: Use when working through the Harvard Law Review (HLR) post-acceptance editing cycle — successive substantive and technical edit rounds, responding to editor markups, and page proofs to publication. Drives the edit cycle to completion; it does not manage the offer/expedite phase (hlr-placement-strategy) or the first editor handshake (hlr-student-editor-review).
---
# Revision and Editing (hlr-revision-and-editing)
After acceptance, an HLR piece goes through an **intensive, multi-round editing cycle** run by student
editors — heavier and more iterative than at most journals. There is no single "R&R letter" as in peer
review; instead there are successive passes (substantive, technical/line, Bluebook, proofs), each with
deadlines. This skill keeps the cycle moving, protects the argument across rounds, and lands the piece in
print without late surprises.
## When to trigger
- The substantive edit is underway and rounds are stacking up
- You receive markups, queries, or new source-pull requests between rounds
- You disagree with a proposed change and must respond across a round
- Page proofs arrive and need a careful final pass
## The edit cycle (round by round)
| Round | Focus | Author's job |
|-------|-------|--------------|
| Substantive round(s) | Strengthen the argument; close gaps editors flagged | Revise on the merits; defend with reasons where warranted |
| Technical / line round | Prose, clarity, house style | Approve or push back on specific edits, not en masse |
| Bluebook / cite round | Every footnote conformed and verified | Supply pincites/sources fast; fix unsupportable claims |
| Page proofs | Final typeset, last corrections | Catch errors; make only essential changes |
## Working the cycle well
1. **Resolve substance before style.** Settle the argument-level edits early; do not relitigate them once
the piece moves to line and Bluebook rounds.
2. **Track every change across rounds.** Edits move footnotes and text; a fix in round one can break an
*Id.* or a cross-reference in round three. Re-verify short forms after each round (see
`hlr-sources-and-bluebook`).
3. **Respond comprehensively, not selectively.** Address every query in a round; partial responses cause
another round and slip the schedule.
4. **Keep a clean change log.** Note what you accepted, what you pushed back on, and why — it prevents
re-arguing settled points and helps the next editor.
5. **Protect the voice and the claim; concede the rest.** Defend substance and signature phrasing with
reasons; concede style and formatting to keep goodwill and momentum.
6. **Proof carefully, change minimally.** At proofs, fix errors — do not reopen the argument.
## Deadlines and momentum
The cycle runs on the journal's production calendar. **Responsiveness is the variable you control**: fast,
complete returns keep the piece on schedule and signal good faith; slow returns stall it and strain the
team. Build in time for the source-pull rounds, which are the most labor-intensive for the author.
## Checklist
- [ ] Substantive edits resolved before line/Bluebook rounds
- [ ] Every query in each round answered (no partial returns)
- [ ] Short forms / cross-references re-verified after each round of moves
- [ ] Source-pull requests answered with exact pincites, fast
- [ ] Change log kept (accepted / pushed back / why)
- [ ] Argument and voice protected; style conceded
- [ ] Page proofs reviewed for errors only
## Anti-patterns
- Reopening settled substantive edits during the line or Bluebook round
- Partial responses that trigger extra rounds and slip the calendar
- Leaving dangling *Id.*/*supra* after footnotes were reordered in a round
- Fighting every line edit and exhausting editor goodwill
- Introducing new argument at page proofs
## Output format
```
【Round】substantive / technical / Bluebook / proofs
【Open queries】count + the hard ones
【Short forms re-verified】after this round's moves? [Y/N]
【Change log】updated (accepted / pushed back / why)? [Y/N]
【Deadline】next return date
【Next】next round → publication (loop hlr-student-editor-review for relationship issues)
```
## Supplementary resources
- [`../../resources/official-source-map.md`](../../resources/official-source-map.md) — HLR editorial process and publication schedule
- [`../../resources/external_tools.md`](../../resources/external_tools.md) — change-tracking and citation-management tools for the cycle
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!