| name | reviewer-audit |
| description | Address reviewer/editor comments by number with localized, traceable edits. Use when the user provides numbered reviewer concerns, editor proof queries, or revision lists and asks to "address comment N", "fix W1-W4", "respond to editor queries", etc. Complements review-response (rebuttal drafting) and paper-edit (style enforcement). |
| tags | ["Writing","LaTeX","Academic","Review","Rebuttal"] |
Reviewer Audit
Localized, traceable response to numbered reviewer/editor comments. The skill enforces scope discipline so a "fix comment 3" request never turns into a global restyle.
When to Use
- User provides reviewer comments numbered (R1.W1, R2.O3, M1, A10, etc.) and asks to address them in the paper.
- Editor proof queries (e.g., MDPI 27-item list, IEEE editorial sheet).
- A revision document from advisor with itemized changes.
- Any "fix items 5-12" style request.
Core Rules
- One comment, one localized change. Each numbered item maps to specific lines in specific files. Do not propagate edits beyond the cited locations.
- Never globally restyle on a numbered request. "Remove bold from §3.2 caption" is NOT permission to remove bold everywhere.
- Citations are sacred. Format/style fixes do not delete or replace citations.
- Audit trail. Every applied edit gets a LaTeX comment marker so it can be diffed and verified later.
Workflow
Step 1: Build the Item Table
Parse the user's input into a table:
| ID | Comment summary | Target file | Target section/lines | Action type |
|---|
| R1.W1 | clarify threat model | sections/3-threat.tex | §3.1, lines 12-18 | rewrite paragraph |
| M3 | shorten caption | figs/main.tex | Fig.4 caption | shorten |
If any row's target is unclear, ask the user before editing.
Step 2: Group by File and Stage
If the audit touches 3+ files or 6+ items, present a stage plan:
Stage 1: items M1-M5 in sections/abstract.tex + intro.tex (compile after)
Stage 2: items R1.W1-W4 in sections/3-threat.tex (compile after)
Stage 3: items R2.O1-O3 in sections/5-method.tex (compile after)
Wait for approval per stage. Do not bundle.
Step 3: Apply Edits with Audit Markers
For each edit, leave a LaTeX comment so the change is traceable:
% [REVIEWER R1.W1] clarified threat model: attacker has read access only
We assume the attacker observes ...
Marker format: % [REVIEWER <ID>] <one-line summary>
Step 4: Verify Compilation
After each stage, the latex-check.js PostToolUse hook runs compilation automatically. Confirm:
- Page count delta vs. previous stage.
- Zero new compilation errors.
- BibTeX still resolves all
\cite{}.
If compilation fails, stop and surface the error before proceeding to the next stage.
Step 5: Generate Response Table
After all stages applied, produce a markdown table mapping each ID to:
- Comment summary
- Files/lines touched
- Brief description of the change
- Page in updated PDF where the change is visible
This table feeds directly into the cover letter or rebuttal document (use review-response skill for full rebuttal drafting).
Anti-Patterns
- ❌ "While I'm in §3.2, let me also clean up some other awkward sentences"
- ❌ "The reviewer flagged one bold phrase, so I'll remove all bold in the paper"
- ❌ Applying all 27 items in one batch without staged compile checks
- ❌ Silent edits with no
% [REVIEWER ID] marker
- ❌ Substituting a flagged citation with a different one without asking
Cross-Skill References
- For free-form rebuttal text drafting: use
review-response skill.
- For style enforcement after edits: use
paper-edit skill.
- For BibTeX/citation issues found during audit: use
citation-verification skill.
