write-report

Write Report (Analysis Quality Review) — Review-Only Multi-Mode Grader

This is a protocol skill. It grades reader-facing deliverables and ghost-deck storylines. It does NOT edit them. Each invocation runs a single mode and returns a structured response. The calling skill — which has the substantive context that produced the document — writes the spec itself (using a template this skill provides) and applies fixes itself (using references/fix-patterns.md), then re-invokes this skill to verify the fixes landed.

Input convention. Reader-facing deliverables are typically HTML (combined reports with prose + charts/diagrams inline) at standard+ strictness. Markdown is acceptable for working drafts at low strictness. The rubrics and reviewers grade content (argument structure, prose readability) regardless of file format — HTML chrome is ignored, prose and section structure are what's graded. Machine artifacts (YAML datasets, JSON, machine-readable manifests) should NOT be reviewed — they are audit substrate, not reader-facing.

The skill is built on four agents and one mechanism:

• spec mode (no agent): returns the framework-matched authoring template path. File lookup only.
• Pre-flight (review modes only): artifact-loader (runs once per review audit, builds load_bearing_index.yaml)
• spec-judge mode: spec-judge agent — grades the filled-in authoring spec against the declared structural_framework
• review pass: 1: argument-structure-reviewer — grades document structure against the declared structural_framework
• review pass: 2: readability-reviewer — grades document readability (framework-independent — applies to any prose document)
• review pass: 3: readability-reviewer (humanization mode) — grades the document against the humanize specs (zero em-dashes, no AI tells, human texture present) after the caller has run the humanizer skill on it

Humanization is mandatory for reader-facing deliverables — with one scope carve-out. A document that passes structure and readability can still read as machine-written — clean but generic, em-dash-riddled, contrastive-negation tics, no human texture. For any doc_type in {brief, memo, deck, decision-record} at strictness ≥ standard, the end-to-end flow REQUIRES a humanize stage. Scope rule (owner decision, 2026-06-10): Pass 3 applies when the deliverable is human-read prose in the author's voice (memo, letter, post, executive report). It does NOT apply to agent-read, repo-resident documentation — docs whose primary consumer is an agent (or a team's agents) and that live inside a product/code repo with an established house voice (e.g. a product repo's docs/). There, match the repo's existing register instead; within-repo voice consistency beats memo-style consistency. Passes 1–2 still run. For the in-scope case: after Pass 2 clears, the calling skill runs the humanizer skill on the document (the edit), then Pass 3 grades that the humanize specs hold. This matters most for client-facing deliverables produced under the owner's name, where the standing rule is no em-dashes, the owner's voice. write-report still never edits — the humanizer skill performs the edit; write-report Pass 3 verifies it landed. Companion-skill dependency: Pass 3 assumes a humanizer editing skill on the caller's side. Any de-AI editing pass that satisfies references/rubric-humanization.md works; if no humanizer skill is installed, the Phase A priority greps inline in that rubric are the minimum pattern source.