skills/writing-review/SKILL.md
Internal skill for hierarchical document review. Called by writing-validate after claim validation passes.
npx skillsauth add edwinhu/workflows writing-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Hierarchical bottom-up review that diagnoses structural problems across a drafted document. Produces .planning/REVIEW.md — a structured diagnosis consumed by /writing-revise.
Prerequisites: PRECIS.md, OUTLINE.md, ACTIVE_WORKFLOW.md, and draft files in drafts/ must exist.
Auto-load all constraints matching applies-to: writing-review:
!uv run python3 ${CLAUDE_SKILL_DIR}/../../scripts/load-constraints.py writing-review
You MUST have these constraints loaded before proceeding. No claiming you "remember" them.
CRITICAL: The constraint-loading-protocol above requires loading the domain skill (writing-legal/econ/general) and ai-anti-patterns before reviewing any prose — see Steps 2 and 2b below.
Before starting, check for an existing handoff:
.planning/HANDOFF.md existsNO REVIEW WITHOUT READING. Every claim in REVIEW.md must cite specific text from the draft. This is not negotiable.
If you find yourself writing a review comment without quoting the draft text it refers to:
A review that says "transitions could be improved" without citing the actual transition text is useless. A review that says "Section III ends with 'The market has spoken.' and Section IV opens with 'Turning to regulatory concerns...' — no bridge connects the market conclusion to the regulatory pivot" is actionable.
The writing-review workflow now enforces this structurally: every reviewer it dispatches must attach a verbatim quote + file:line to each issue, so a review without reading cannot be produced.
</EXTREMELY-IMPORTANT>
NO PASSES WITHOUT EVIDENCE. Checking a box requires quoting the text that satisfies it. This is not negotiable.
If you find yourself marking something as "OK" or "no issues found":
"Transitions are smooth" is a lie unless you can quote adjacent section boundaries and explain why they connect. "No repetition found" is a lie unless you compared the argument summaries across all sections.
Reporting "all checks pass" without evidence for every checkmark is NOT HELPFUL — undetected issues survive into the published document.
The writing-review workflow now enforces this structurally: its reviewers return quoted evidence per finding, and a mechanical Verify stage confirms each quote resolves to the draft — fabricated or misattributed quotes are dropped before they reach REVIEW.md. Evidence-grounding is no longer honor-system; it is built into the workflow. </EXTREMELY-IMPORTANT>
<EXTREMELY-IMPORTANT> ## Iron Law: Structural IndependenceREVIEW MUST BE PERFORMED BY FRESH SUBAGENTS THAT DO NOT SHARE CONTEXT WITH THE DRAFTER. This is not negotiable.
The drafter's context contains intent, shortcuts, and assumptions that bias review. A fresh reader catches what the author cannot see. Reviewing your own draft in the same context is rubber-stamping, not reviewing.
The writing-review workflow now guarantees this by construction: it always dispatches fresh reviewer subagents (structure, prose, fidelity) that read each draft cold. You do not — and must not — review draft prose in the main conversation yourself. </EXTREMELY-IMPORTANT>
If you catch yourself in any of these violations, the review output is contaminated. Delete it and start over:
| Violation | Why Contaminated | Action | |---|---|---| | Reviewed a section without reading its draft file | You fabricated a review from outline knowledge | DELETE REVIEW.md. Read every draft. Start Level 1 over. | | Reviewed your own draft in the same context (no fresh subagent) | Self-review is rubber-stamping — you share the drafter's biases | DELETE the section review. Spawn a fresh subagent. Re-review. | | Wrote REVIEW.md without completing all 3 levels | Partial review misses cross-section issues | DELETE REVIEW.md. Complete all levels. Regenerate. |
Partial fixes to contaminated reviews create worse outcomes than restarting. A review built on fabricated evidence will misdirect writing-revise into "fixing" non-problems while real issues persist.
Read(".planning/ACTIVE_WORKFLOW.md")
Read(".planning/PRECIS.md")
Read(".planning/OUTLINE.md")
Glob("outlines/*.md")
Glob("drafts/*.md")
Verify: every section in OUTLINE.md has both an outline file and a draft file. If any draft is missing, STOP and report — you cannot review what doesn't exist.
Based on style in ACTIVE_WORKFLOW.md:
| Style | Action |
|---|---|
| legal | Read("${CLAUDE_SKILL_DIR}/../../skills/writing-legal/SKILL.md") |
| econ | Read("${CLAUDE_SKILL_DIR}/../../skills/writing-econ/SKILL.md") |
| general | Read("${CLAUDE_SKILL_DIR}/../../skills/writing-general/SKILL.md") |
The domain skill contains style rules that inform your review criteria. You MUST read it before reviewing.
Skill(skill="workflows:ai-anti-patterns")
You MUST load ai-anti-patterns before reviewing. Domain skills inform domain-specific review criteria; ai-anti-patterns catches AI writing smell (hedging, filler, false balance) that domain skills don't cover. Both layers are required — see constraints/constraint-loading-protocol.md.
Before any review work, run all mechanical constraint checks:
uv run python3 ${CLAUDE_SKILL_DIR}/../../references/constraints/check-all.py [project-root]
This auto-discovers and runs all writing-*.py constraint scripts (bold-lead, topic sentences, source-anchored citations, etc.). If any check fails, report violations and fix them before proceeding to Level 1.
Constraint checks are Leg 1 of two-leg verification. Leg 2 (convention scoring via reviewer subagents) happens in Level 1.
The review is always parallel and is owned by an ultracode workflow script — you do NOT choose a strategy and you do NOT dispatch reviewers yourself. The workflow runs all three levels (per-section structure + prose + fidelity fan-out, mechanical quote-verification, transition analysis, and whole-document checks) in the background and returns structured findings.
1. Resolve the cached workflow path:
WF=$(command ls -d ~/.claude/plugins/cache/*/workflows/*/workflows/writing-review.js 2>/dev/null | sort -V | tail -1)
# Fall back to the in-repo path when running from the plugin source (cache glob empty):
[ -z "$WF" ] && WF="${CLAUDE_SKILL_DIR}/../../workflows/writing-review.js"
2. Invoke the workflow:
Workflow({
scriptPath: "<WF>",
args: {
projectDir: "<abs project dir>", // holds .planning/, outlines/, drafts/, references/sources.bib
pluginRoot: "${CLAUDE_SKILL_DIR}/../.." // resolves domain skill + bridge_repetition_check.py
}
})
The workflow runs Levels 1-3 and returns:
overallPass / substratePass (== critical===0 && major===0 — the blocking gate; minors are advisory, not blocking), verdict (CLEAN | CLEAN (advisory polish notes) | ISSUES FOUND)summary ({ critical, major, minor, total, blocking, advisoryMinors })stylesections[] — per-section issues (each tagged source: structure | prose | fidelity), boundary, argumentSummary, unreliabletransitions[] — adjacent boundary verdictsdocumentLevel — { conceptOrderIssues, repetition, thesisIssues, completeness }unreliableSections — sections where a reviewer returned nothingsectionsThatFlagged — sections to pass as onlyChecks on a re-reviewRe-review (when /writing-revise re-invokes after edits): pass only the changed sections so the workflow re-reviews them and carries the rest forward:
Workflow({
scriptPath: "<WF>",
args: {
projectDir: "<abs project dir>",
pluginRoot: "${CLAUDE_SKILL_DIR}/../..",
onlyChecks: [<changed section names>], // re-review only these
priorReviews: <previous result.sections> // carry the rest forward
}
})
Note:
references/agent-team-workflow.mdandreferences/reviewer-agent-prompt.mdare SUPERSEDED byworkflows/writing-review.js— the script replaces the hand-rolled agent-team orchestration, andreferences/sequential-checklist.md's content now lives in the workflow's structure-reviewer prompt. Those reference files are retained for provenance only; do not follow them to dispatch reviewers.
Write .planning/REVIEW.md from result.* using the template in references/review-template.md:
result.summary (critical, major, minor, total)result.verdictresult.documentLevel (conceptOrderIssues, repetition, thesisIssues, completeness)result.transitions (one block per non-SMOOTH boundary; quote closes/opens)result.sections — list each section's issues sorted by severity; each issue carries source (structure / prose / fidelity), location (file:line), quote, detail, and fixresult.sections[].boundaryIf result.unreliableSections is non-empty, mark those sections UNRELIABLE in REVIEW.md (a reviewer returned nothing for them) — do NOT fabricate findings or a clean verdict for them.
The workflow's reviewers already cite verbatim quotes with file:line and a mechanical Verify stage drops any quote that does not resolve to the draft, so the findings you render are evidence-grounded by construction. Render them faithfully — do not add, invent, or soften.
Full REVIEW.md template: See
references/review-template.md
Before declaring review complete:
.planning/REVIEW.md existshuman-verify — auto-advance to /writing-revise..planning/PHASE_SUMMARY.md (see constraints/phase-summary-frontmatter.md):
If any section is missing from REVIEW.md, the review is incomplete. Go back.
Update .planning/ACTIVE_WORKFLOW.md:
phase: review
review_completed: true
issues_found: [total count]
critical_issues: [critical count]
Review complete. Results written to .planning/REVIEW.md.
Found [N] issues ([critical] critical, [major] major, [minor] minor).
[If issues found]:
Run /writing-revise to fix issues from the review.
[If clean]:
No issues found. Run /writing-revise to complete the workflow.
Tag each reported issue with a confidence level:
| Level | Threshold | Placement | |---|---|---| | HIGH | >= 90% certain this is a real problem | Main report — fix required | | MEDIUM | >= 80% certain | Main report — fix recommended | | LOW | < 80% certain | Separate "Possible Issues" section at end of REVIEW.md |
Only issues at HIGH or MEDIUM confidence appear in the main report. LOW confidence issues go in a separate "Possible Issues" section so they are visible but do not clutter actionable fixes. This prevents false positives from overwhelming /writing-revise.
After review is complete:
Invoke /writing-revise to fix issues identified in .planning/REVIEW.md.
tools
Use when "query Dewey Data", "deweydata.io", "SafeGraph places/patterns/spend", "Advan foot traffic", "POI / points of interest", "mobility data", "dataplor", "Veraset", "PassBy", "crypto/Bitcoin ATM locations", or any pull from the Dewey Data academic marketplace (UVA/NYU Platform Subscription) via the deweypy/deweydatapy client, DuckDB, or the Dewey MCP server.
development
Use when submitting jobs to UVA HPC (Rivanna/Afton), writing Slurm scripts (sbatch/srun/squeue), converting SGE to Slurm, running compute on any Slurm-managed cluster, or building WRDS data pipelines with polars on HPC. Triggers: 'submit to HPC', 'sbatch', 'squeue', 'slurm job', 'run on Rivanna', 'run on Afton', 'HPC array job', 'convert SGE to Slurm', 'polars on HPC', 'WRDS from HPC'.
testing
Internal skill for literature review and source materialization. Called after brainstorm, before setup. NOT user-facing.
development
This skill should be used when the user asks to "add paper", "paperpile add", "fetch PDF for", "find and add", "search paperpile", "find in paperpile", "paperpile search", "label paper", "trash paper", "download paper", "paperpile index", "edit paper metadata", "update paper title", "fix paper author", "paperpile edit", "find PDF online", "search google for PDF", "resolve PDF", "fetch PDF for citation", "get full-text for DOI", "resolve cite to PDF", or any request to manage their Paperpile library or resolve a citation to a local PDF.