Ambiguity Report

Stage 4 — Render

Each format has its own reference file with detailed instructions. Read the relevant one before rendering. The rough invocations:

Website (multi or single page) — bundled script:

python scripts/generate_site.py \
  --spec <output-dir>/spec.json \
  --out <output-dir>/site \
  --mode multi    # or "single"

The script emits a complete static site (HTML + CSS) ready to upload to Netlify. See resources/format-website.md.

Single-file HTML — no script. Write one self-contained .html file directly from the spec, inlining the stylesheet and every scenario. This is the fallback when Python is unavailable, and a legitimate first choice whenever the deliverable has to survive being emailed. Full instructions in resources/format-inline-html.md.

Word document — delegate to the docx skill. Read resources/format-docx.md for the document structure (title page, executive summary, statute-as-block, scenarios as level-2 sections, redrafts appendix, methodology appendix). Build via the docx skill's python-docx pattern.

PowerPoint deck — delegate to the pptx skill. Read resources/format-pptx.md for the slide structure (title, statute overview, one slide per scenario with family-color band, redrafts slide, methodology slide). Speaker notes carry the analysis. Build via the pptx skill's tooling.

LaTeX — bundled script:

python scripts/generate_latex.py \
  --spec <output-dir>/spec.json \
  --out <output-dir>/report.tex

The script emits a self-contained .tex file using the article class with a clean preamble. The deliverable is the .tex. Compiling it to PDF requires a LaTeX distribution — latexmk -pdf report.tex, or pdflatex run twice. Attempt the compile only where a distribution is present; where it is not, hand over the .tex and say plainly that it needs LaTeX to typeset, rather than reporting a failed PDF. See resources/format-latex.md.

All formats at once. If the user asks for all formats from one invocation, run the renderers in sequence and present each output. This is useful when a deliverable is going to a mixed audience (the litigator wants the Word doc, the colleague wants the link to the site, the meeting wants the deck).

Output organization

Default output directory: <source-name>-ambiguity/ in the workspace folder if one is connected, otherwise in the temporary outputs folder. Within it:

<source-name>-ambiguity/
├── spec.json              # The canonical spec — re-renderable
├── site/                  # If website was requested (multi or single)
├── site.zip               # The site folder, zipped for delivery
├── report.html            # If single-file HTML was requested
├── report.docx            # If Word was requested
├── deck.pptx              # If PowerPoint was requested
├── report.tex             # If LaTeX was requested
└── report.pdf             # Only if a LaTeX distribution was present and compilation succeeded

Deliver each produced file to the user by whatever mechanism the host provides — a file-presentation or file-sending tool if one exists, otherwise state the output paths plainly.

Zip the site folder before handing it over. A multi-page site is dozens of files, and delivering a loose directory to someone working in a chat window is its own small frustration. Produce site.zip alongside site/, deliver the zip, and point at site/index.html as the entry point. The user can unzip and drag the folder to Netlify Drop, or upload it to any static host, to deploy. Single-file HTML needs none of this — it is one file by design.

What this skill does not do

• It does not perform the ambiguity analysis itself. That is the job of ambiguity-stress-test. This skill turns analysis into a deliverable; it does not generate scenarios from a bare legal text.
• It does not edit the source text — only quotes it.
• It does not verify citations or check current law. If the underlying analysis relies on case law that may have changed, the skill should add a research note to the methodology section but cannot itself confirm currency. Cite-checking would be a separate pass.
• It does not produce printed-paper layouts. The LaTeX path produces a screen-readable PDF; print-specific layout (booklet format, court submission formats) is the province of more specialized skills like scotus-amicus.

When the user asks for design tweaks

Re-render from the saved spec.json with the new design tokens. Do not re-parse the input. This is what makes the spec file worth saving — design iteration is fast and deterministic.

Bundled resources

Read the two or three files the job actually needs; do not read all six.

• resources/data-format.md — the canonical spec schema. Read this in Stage 2 before building the spec.
• resources/parsing-unstructured.md — heuristics for extracting scenarios from less-structured input. Read this in Stage 1 if the input is Signature B or C.
• resources/format-website.md — how the website renderer works, deployment to Netlify, the design system.
• resources/format-inline-html.md — the single-file HTML fallback, written directly without the scripts. Read this whenever the host cannot run Python, or the deliverable must travel as one attachment.
• resources/format-docx.md — Word document structure, delegated to the docx skill.
• resources/format-pptx.md — PowerPoint structure, delegated to the pptx skill.
• resources/format-latex.md — LaTeX preamble, document class, compilation.
• scripts/generate_site.py — the website renderer. Python 3, standard library only.
• scripts/generate_latex.py — the LaTeX renderer. Python 3, standard library only.
• assets/site-style.css and assets/latex-preamble.tex — the stylesheets the two renderers read. generate_site.py resolves assets/site-style.css relative to its own location, so keep the scripts/ and assets/ folders as siblings.

Limitations and risks

This skill formats an analysis someone else produced. It does not evaluate whether that analysis is correct, and a polished deliverable makes a weak audit look authoritative. Nothing it produces is legal advice.

It inherits every defect in its input. Wrong scenarios render as beautifully as right ones. Where fields were missing, the skill fills defaults and surfaces what it inferred — read those notes before circulating the result.

It does not check citations or currency. If the underlying analysis rests on case law that has moved, the deliverable will reproduce the error. The methodology section can carry a research note; the skill cannot itself confirm anything.

Most formats need a capable host. Both website renderers and the LaTeX renderer are Python scripts that write files; Word and PowerPoint delegate to the docx and pptx skills. Where none of that is available, single-file HTML still works and requires nothing — which is why the capability check in Stage 3 comes before the format conversation rather than after it.

The PDF needs a LaTeX distribution. The script emits .tex; compiling to PDF requires latexmk, pdflatex, or xelatex on the machine. Absent one, the .tex file is still the deliverable — do not present that as a failure.

The script-generated website loads fonts from Google Fonts. Those pages call an external service when opened, and fall back to system fonts offline or behind a restrictive network. Where that matters — a confidential audit, an air-gapped review — either override the font tokens in the spec with a local stack, or use single-file HTML, which by design embeds no web fonts and makes no outbound request.

Quoted source text travels with the deliverable. A rendered audit reproduces passages of the instrument it analyses. Check before publishing a site or sharing a deck built from a confidential draft.

The two scripts use only the Python standard library. They make no network calls, spawn no subprocesses, and write only inside the output directory the caller names.