zeweihan/aiworkdeck/mqc-litigation-visual-redraw

Litigation visual redraw

This skill is `mqc-litigation-visual-redraw` — the first open-source module of 新诉讼可视化 · New Litigation Visualization (slogan: 把法律画出来 · Make the Law Visible), 缪奇川's litigation-visualization project. It takes an ugly / hand-drawn / "AI-flavored" source — or even plain judgment text — and redraws it into a standard legal diagram (timeline · flowchart · relationship). This module stands alone.

Turn a messy or generic litigation diagram into a calm, professional legal graphic. The guiding idea (先吃透，再重画): first understand the source faithfully, then redraw it — never change the wording and never change the legal meaning; only improve the visual expression. Method, in the spirit of mqc-legal-skills: scenario is vertical, the SOP is tight, the output should look like a McKinsey exhibit, not a student's slide.

Scope: timelines (three forms — numbered, dated, gantt), flowcharts, and relationship diagrams (free-form network + hierarchical tree; a two-column comparison table is the A-vs-B variant of the relationship family). All are frozen and share one visual language. This skill draws these three families and nothing else — do not invent new diagram types.

Intent router (what to read first)

Read SKILL.md + references/STANDARDS.md always. Then, by intent, open only what you need (don't preload everything):

Forbidden — never do these (集中红线)

Golden rule: the model extracts, the scripts draw

Do not hand-write SVG coordinates, and do not try to lay out nodes "by eye". Language models place boxes/arrows badly (overlaps, overflow, crossings), and this skill must work even on weaker models. So the division of labor is fixed:

• The model's job: read the source, transcribe every character verbatim,

and emit a semantic-map.json. Judgement calls (which element is the single most important, reading order, above/below placement) live in that JSON.

• The scripts' job (scripts/): all geometry — column math, date scaling,

text wrapping, collision-free stacking, styling, and rasterization.

If you follow this split, output quality comes from the JSON being correct, not from the model being clever about pixels.

Workflow

1. Read, analyze, decompose the source — this is the make-or-break stage of

this skill (turning an ugly/hand-drawn/cluttered source into a high-grade legal diagram lives or dies here). Follow the six-step discipline in `references/extraction-guide.md`: (1) classify the diagram type → pick the layout; (2) find the spine first (the axis / the happy path / the core party), then hang branches off it — never transcribe left-to-right blindly; (3) transcribe every character verbatim — dates, labels, evidence numbers; do not normalize ("2023年5月左右" stays as is), paraphrase, or merge; (4) strip decoration (pie charts, waveforms, icons, flourishes) — this skill re-draws STRUCTURE, it does not copy illustrations; (5) do NOT choose emphasis yourself — the deep-red accent is the USER's call, asked at the checkpoint, and defaults to NONE (no red anywhere) if they skip it; (6) when the source is dense, main structure goes in the diagram and sub-notes go to provenance — do not cram. Anything you cannot read confidently goes into provenance.uncertainties, never into a guess.

1. Write `semantic-map.json`. Follow references/semantic-map-schema.md.

Preserve original numbering if present; you may add numbering for readability and must record that in provenance.

1. CHECKPOINT — one round of questions before rendering (not optional).

Do not compose the questions yourself. Generate them:

``bash python3 scripts/checkpoint.py map.json --suggest=<n> # n = the mark you propose ``

Show that output to the user verbatim and wait. It asks the same three things every time:

• ① structure — the layout, why that layout (the data decides it, not

taste), what was read, what is uncertain, and the sibling forms this data could genuinely be swapped to. The layout is presented as a reading to correct, never as a free menu: offering a date-proportional axis for events with no parseable dates is offering something that cannot be delivered.

• ② style — each mode by what it LOOKS like and what it is FOR. Never by

whose style it is: these names are the author's, but the reader is another lawyer choosing a look for their own file.

• ③ emphasis — your proposed mark, plus 0 for none. Short candidate lists

are numbered; a long one is not printed, because a sixteen-item list is a wall rather than a menu — the user knows their own case and can name the element. This is generated rather than written out here for the same reason the geometry is computed rather than placed: a question that a hurried model might drop, shorten or garble is not a reliable question, and the consequences of these three answers are already enforced deterministically.

Then record the answers in the map and render:

``jsonc "checkpoint": { "confirmed": true, // the user confirmed the structure "emphasis_source": "user" // "user" | "model" | "none" } ``

• `"user"` — they named the element. Up to two marks.
• `"model"` — they skipped, said "you pick", or did not reply. Mark the

ONE element you judge the case turns on. render.py keeps exactly one and clears any others, and you must say in the delivery which one you marked and why, so the user can move or remove it. It is your legal reading, not theirs — never let it pass silently as if it were.

• `"none"` — they asked for no red. The figure is pure greyscale.
• Absent / anything else — the map cannot say where the red came from, so

the renderer draws none. provenance.emphasis_note authorises nothing: it is written by the same model whose choice it describes.

Defaults when the user does not choose: 奇川风, and `emphasis_source: "model"` — a figure with no focal point at all is not the safer answer, it is just a weaker one. Until confirmed is true, every file is written as *-draft.*.

1. Render deterministically, in the mode chosen at the checkpoint. From scripts/.

Every run writes the master .svg, a .png, and three editable hand-offs — .drawio, .pptx (PowerPoint / WPS) and .vsdx (ProcessOn / Visio / WPS / Edraw). All five are transcribed from the same master, so none can drift from the delivered figure. This is deliberate: which tool the lawyer edits in is not ours to guess. Narrow it only if asked, with --formats=svg,png. On an unfamiliar machine (a fresh clone), run python3 scripts/doctor.py first — it reports missing tooling (graphviz, rasteriser, fonts) instead of failing obscurely: ``bash python render.py <semantic-map.json> final # 奇川风 (recommended, colour) python render.py <semantic-map.json> final --guizang # 歸藏风 (online / lecture) python render.py <semantic-map.json> final --baimiao # 白描 (pure black and white) ` (Or set "visual_mode":"歸藏风" / "白描" in the JSON instead of a flag.) This picks the layout, writes final.svg (primary, editable) and final.png (preview/filing), and prints an audit summary. All three modes share ONE geometry — only the surface differs. Never edit coordinates by hand; if something is wrong, fix the JSON or the script, not the SVG. Mode standards: references/visual-style.md`.

1. Deliver. Hand over final.svg + final.png + a one-line audit summary

(elements preserved, mode used, emphasis used or "none", any uncertainties). Keep the summary in the reply / JSON — never draw it onto the image.

Pick a layout

Set "layout" in the JSON. Three timeline forms, chosen by what the spacing should mean:

• `numbered_point_timeline` — discrete events whose spacing carries NO

argument (a dense fact chronology, or events with no usable dates: 签约 → 转账 → 违约 → 起诉 → 判决). Axis is equidistant; markers are numbered circles (1-2-3), cards alternating above/below. → render_points.py

• `dated_point_timeline` — discrete events on a date-proportional axis, so

the distance between two events is faithful to the elapsed time. The axis is a light-gray bar carrying an honest ruler (year ticks, or year+month for a short span, auto-chosen); markers are dots (no numbering); the precise date sits in each card. Best for long, well-separated chronologies (诉讼时效, 长期履行). Every event needs a real date or it errors — use the numbered form for undated/clustered events. → render_dated.py

• `proportional_gantt` — periods that run, overlap, or leave gaps

(诉讼时效 / 保证期间 / 主债权 / 履行期间). Axis is date-proportional — bar length and overlap ARE the legal point (e.g. whether 本诉 falls outside 诉讼时效). One period per row. → render_spans.py

Rule of thumb: real time distances matter → dated_point_timeline (points) or proportional_gantt (periods); only the ORDER matters → numbered_point_timeline. Decide the timeline form with the ordered decision ladder in references/extraction-guide.md (Step 1): if any event lacks a precise, parseable date — or events are tightly clustered — use the equidistant numbered_point_timeline; reserve dated_point_timeline for precise dates whose gaps carry legal meaning. numbered_point_timeline is the safe default. A gantt may also carry point events (转让公告, 提起本诉) as dashed vertical markers — put those in points (see schema).

For a process / procedure diagram (not dates but steps, decisions, branches, merges), use the flowchart layout: