Analyze

A grammar-and-style deep-scan. Combines a full style scorecard, per-issue grammar flags with suggested fixes, and a summary block.

Endpoint: /analyze — up to 1,500 words per run (the tightest budget in the suite).

What it measures

The /analyze endpoint returns two payloads for whatever slice of prose it received:

Scores — the same fifteen style metrics as Style score (style score composite, sentence length, readability, sentence variety, glue index, passive voice, business jargon, complex paragraphs, conjunction starts, slow pacing, very long sentences, emotion tells, -ing starts, weak adverbs, dialogue tags), each with its current value, ideal range, and status. But whereas /score runs against the whole 50k-word manuscript, /analyze scores only the specific 1,500-word window it saw — so the numbers reflect this passage, not the book. This is what makes it useful for polishing a single chapter opening: you can see how the fifteen dimensions score inside that particular scene, rather than diluted across the whole book.
Issues — a list of concrete grammar and style problems the parser found in the window, each with:
- The exact string in your prose that flagged (the surface text)
- A type label — one of a large taxonomy including Grammar_agreement, sentence_length_excessive, passive_voice, weak_adverb, ing_start, comma_splice, and dozens more. The prefix Grammar_ is stripped and lowercased for display, so a raw Grammar_agreement renders as agreement.
- The paragraph key — an opaque identifier the editor uses to land the highlight on exactly the right paragraph
- Start/end character offsets — so the highlight painting lands on the exact span, not the whole sentence
- A suggested rewrite — the parser's best-guess replacement for the flagged span

Plus a summary block: total issue count, word count, sentence count, paragraph count.

Why it's useful

For any 1,500-word section you're actively focused on — a scene you're polishing, a chapter opening that's not landing, a difficult monologue — Analyze is the closest thing to a copy-editor's pass we can do in software. Every flagged issue comes with a specific suggested fix, which turns revision from hunting for problems into accepting or rejecting proposals. That's a completely different workflow: instead of reading every sentence looking for what might be wrong, you scan the issue list, decide whether each flag is a real defect, and click through to fix or move on.

The two payloads (scores + issues) together are what makes the report powerful. The scores tell you what dimension is off in this passage; the issues tell you the specific sentences that made it off. If the passage's Passive voice metric is red, the issue list will contain the exact passive constructions responsible. If Weak adverbs is amber, the issue list will show you the specific adverbs to consider cutting.

Use Analyze for tight polishes on individual scenes. For whole-book passes, use Summary report and Passive voice instead — those endpoints run on the full manuscript without a word cap.

How to read it

Filter by issue type using the chips above the list. Click any issue to jump to the exact span in the editor. The suggested rewrite is a starting point, not a mandate — accept, adapt, or ignore.

The Analyze output does not get its own dedicated list panel in the current Rust panel layout. Instead, its grammar issues are wired into the Issue breakdown donut chart in the middle of the panel — the grammar slice (red) is populated by every issue Analyze returned.

To use it: find the donut in the panel body, click the grammar legend row (or the grammar slice itself) to lock it as active. When locked, the plot-hole highlight layer paints every grammar-flagged span in the editor via the shared decoration layer. The rest of the donut dims to indicate that grammar is the selected view. Click again to deselect.

Individual grammar suggestions (the parser's suggested rewrites) are surfaced through the same donut selection — the panel currently does not render a dedicated collapsible list for grammar with the per-issue suggestion text. To see the suggestions inline, isolate the grammar layer via the donut and then hover the highlighted spans in the editor.

The score data from Analyze — the fifteen metrics scored on the 1,500-word window — does not display separately in the panel either. It runs behind the scenes and is used to keep the header metrics honest when the passage is short enough that whole-manuscript scoring would drown out the local shape.

When to ignore it

For a whole-book pass, use Summary report and Passive voice instead — they cover the same territory at scale without the word budget. Reserve Analyze for tight polishes on specific sections where you want issue-by-issue detail.

The suggested rewrites are heuristic. They know grammar and general style; they don't know your voice, your rhythm, or the specific effect you're going for in this scene. The parser will helpfully rewrite "was seen to have been prepared by the assistant" as "the assistant prepared it" without noticing that the passive construction was doing narrative work (obscuring the actor deliberately). Read every suggestion; accept only the ones that improve the prose.

The type taxonomy is uneven. Some flags are almost always correct (comma_splice, subject_verb_agreement); some are almost always debatable (sentence_length_excessive, weak_adverb). Weight the flags by how much of a defect the underlying issue actually is in your register.

A note on the /analyze budget

Analyze is the fragile endpoint in the Rust suite. It rejects payloads above ~2,000 words upstream (we cap at 1,500 with a safety margin), and when it runs in parallel with /score it can starve the shared rate limit and take the whole panel down.

We work around this by:

Word-budget truncation. Long documents get truncated to 1,500 words for Analyze only. The other seven endpoints see the full manuscript.
Endpoint ordering. Analyze runs LAST in the queue. If it fails, the seven reliable endpoints have already completed cleanly.
Truncation transparency. When we truncate, the response comes back with a truncated: true marker and the panel shows a "stats over 1,500 of N,NNN words" pill so you know the report doesn't cover the whole document.

If you want Analyze-level detail on the whole manuscript, run it on chapters one at a time.

How to run it

Click Write in the left sidebar and open the document you want to analyze.
Open the right rail: click the Reports button (bar-chart icon) in the editor's top toolbar.
In the rail header, click the Rust tab.
All 8 Rust endpoints run in parallel on tab open — typically completes in 2–5 seconds. Because Analyze runs LAST in the queue and caps at 1,500 words, the seven reliable endpoints render first; Analyze issues stream in a beat later.
Analyze's grammar issues feed the grammar slice of the Issue breakdown donut. Click the "grammar" legend row (or the slice itself) to paint every flagged span in the editor via the shared highlight layer.
Individual grammar suggestions are surfaced through the same donut selection — the panel currently does not render a dedicated collapsible list for grammar, so use the donut to isolate the layer and click through in the editor to see each rewrite suggestion inline.