skills/bluebook-audit/skills/audit-check/SKILL.md
Phase 2: Run mechanical checks and Gemini formatted audit
npx skillsauth add edwinhu/workflows audit-checkInstall 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.
Two-stage checking: Python mechanical checks catch definite errors; Gemini batch audit catches judgment-call issues.
uv run python3 "${CLAUDE_SKILL_DIR}/../../../../skills/bluebook-audit/scripts/scan_formatting.py" --docx path/to/file.docx
Checks performed on ALL footnotes:
*supra* should be roman, not italic (unless it's a case name short form). Catches *Manne, supra* → should be Manne, *supra**supra * should be *supra* ). These don't affect Word display but cause Gemini misparsesDOCX uses non-breaking spaces (\xa0) in abbreviations. ALL search functions must handle both \x20 and \xa0:
No.\xa02106, Feb.\xa07, Oct.\xa021Wall St.\xa0J., Corp.\xa0GovernanceDefault: Use Gemini Batch API (50% cheaper, handles all footnotes in one job). Fallback to sync calls if batch is unavailable.
uv run python3 "${CLAUDE_SKILL_DIR}/../../../../skills/bluebook-audit/scripts/gemini_audit.py" --docx path/to/file.docx --extract-only
This outputs a JSON file mapping footnote numbers to formatted text with inline markup:
*text* = italic[SC]text[/SC] = small capsBuild a JSONL file with one request per footnote, then submit via Batch API:
# Build JSONL (one line per footnote)
for fn_num, formatted_text in footnotes.items():
request = {
"custom_id": f"fn-{fn_num}",
"body": {
"contents": [{"parts": [{"text": PROMPT.format(fn_num=fn_num, formatted_text=formatted_text)}]}],
"generationConfig": {"responseMimeType": "application/json", "temperature": 0.1}
}
}
# Submit batch job (see /gemini-batch skill for full pattern)
# Use examples/batch_processor.py pattern — DO NOT guess API parameters
IMPORTANT: Follow the /gemini-batch skill's Iron Law — read examples/batch_processor.py before writing batch code.
Fallback (sync): If batch is unavailable, use:
uv run python3 "${CLAUDE_SKILL_DIR}/../../../../skills/bluebook-audit/scripts/gemini_audit.py" --docx path/to/file.docx
The Gemini audit MUST cover every footnote, not a subset. Auditing only "major" or "flagged" footnotes guarantees missed errors.
Previous failure: Auditing 45 of 239 footnotes missed 41 journal names needing small caps. </EXTREMELY-IMPORTANT>
Never trust a single agent. After Gemini's per-footnote audit, Claude reviews the full set for cross-footnote patterns that per-footnote analysis misses.
Claude receives:
Claude reviews for:
supra note 42 actually point to the right source?Output: Annotated version of Gemini findings with cross-footnote issues added and false positives flagged.
| Action | Why Wrong | Do Instead | |---|---|---| | Sending plain text to Gemini | 10-20x false positives without formatting info | Always include inline markup | | Auditing a subset of footnotes | Missed errors guaranteed | Audit ALL footnotes | | Skipping NBSP variants in mechanical checks | Silent search failures | Always try both space types | | Trusting Gemini results without Claude cross-check | Per-footnote misses cross-footnote patterns | Always run Stage 2c | | Trusting Claude review without mechanical checks | Claude misses deterministic patterns | Mechanical checks are authoritative for their categories | | Skipping any stage | Each stage catches different error classes | Run all three: mechanical → Gemini → Claude |
Priority order: Mechanical > Claude cross-review > Gemini per-footnote
Mechanical checks are authoritative for deterministic rules:
Claude cross-review is authoritative for:
Gemini per-footnote is authoritative for:
Never drop a mechanical finding because Gemini or Claude didn't flag it. The mechanical checker catches 100% of signal issues by design.
Before proceeding to Report phase:
scratch/audit_findings.json existsRead ${CLAUDE_SKILL_DIR}/../../../../skills/bluebook-audit/skills/audit-report/SKILL.md and follow its instructions.
testing
Internal skill for literature review and source materialization. Called after brainstorm, before setup. NOT user-facing.
documentation
This skill should be used when the user asks to 'write a paper', 'start a writing project', 'draft an article', 'write about', 'brainstorm writing topics', 'gather sources for a paper', 'what should I write about', or needs the writing workflow entry point for any writing task.
testing
Validate draft sections cover all PRECIS claims before review.
testing
Internal skill for creating PRECIS.md, OUTLINE.md, and ACTIVE_WORKFLOW.md. Called after brainstorm sources are gathered.