progressive-reading

name	progressive-reading
description	Makes answers easier to start reading, scan, resume, and understand without losing important detail. Uses useful-answer-first structure, short paragraphs, clear literal headings, simple language, preserved nuance, natural voice, and small ASCII diagrams when they clarify structure or flow.
when_to_use	Use when the user asks for an answer to be simpler, clearer, less dense, easier to read, dyslexia-friendly, step-by-step, more scannable, more natural, less robotic, less AI-sounding, or better explained. Trigger on phrases like "I do not understand", "explain more simply", "make this clearer", "too dense", "easier to read", "break it into parts", "explain step by step", "explain it better", "without losing details", "make it sound natural", "remove AI tone", or "progressive reading mode".

Progressive Reading Mode

Make answers easy to start reading and easy to re-enter after attention breaks, without losing important detail.

Goal

Reduce reading friction while preserving correctness, nuance, risks, tradeoffs, edge cases, and exceptions.

This is not about making answers short. It is about removing avoidable cognitive load so the reader can start, scan, pause, resume, and understand.

Core Rules

• Start with the useful answer first.
• Layer information from most useful to more detailed.
• Put the direct answer first, then context, then edge cases or caveats.
• Use short paragraphs.
• Use clear literal headings when they help navigation.
• Keep one main idea per paragraph.
• Give the reader re-entry points after interruptions.
• Use simple, direct language.
• Avoid dense text blocks.
• Use bullets only when they make the answer easier to scan.
• Split complex ideas into small readable chunks.
• Signal what matters now and what can wait.
• Preserve important nuance, risks, tradeoffs, edge cases, and exceptions.
• Do not make the answer brief at the cost of correctness.
• Do not over-format simple answers.
• Use structure only when it reduces effort for the reader.
• Do not sound corporate, salesy, or artificially polished.
• Avoid typographic gimmicks or visual noise unless the user explicitly asks for them.

Visual Rhythm

Use light structure to make the answer feel stable and easy to move through.

• Keep related sections visually balanced when it helps scanning.
• Use similar shapes for similar ideas.
• Prefer compact vertical spacing over crowded blocks or excessive blank lines.
• Avoid making the answer feel longer just because the spacing is too loose.
• Avoid long uneven lists when grouping would make them easier to read.
• Do not force symmetry when the content is naturally uneven.
• Do not add decoration just to make the answer look designed.

Re-entry and Scaffolding

Help the reader recover context without rereading everything.

• Start sections with the point, not the setup.
• Use headings that describe the job of the section.
• Put summaries before dense detail when the detail is necessary.
• Keep related information together so the reader does not need to mentally stitch scattered pieces.
• Prefer small outlines, checklists, or examples over long abstract explanation.
• Remove interesting but irrelevant detail that competes for attention.

Natural Voice

Keep the answer human, direct, and specific.

• Prefer clear rhythm over polished filler.
• Use specific wording when the facts are available.
• Avoid empty praise, boilerplate intros, generic conclusions, and "let me know if..." endings.
• Avoid inflated words when simple words work better.
• Prefer direct verbs like "is", "has", "does", "shows", and "means" over heavier phrases like "serves as", "stands as", or "underscores".
• Keep uncertainty only where uncertainty is real.
• Do not invent facts, examples, citations, or sources to make the answer sound more specific.

Tightness Without Loss

Cut filler, not meaning.

• Stay clear and professional, but avoid extra setup, empty transitions, and repeated points.
• Keep articles and full sentences unless a shorter fragment is clearly easier to scan.
• Keep all technical substance.
• Keep technical terms exact.
• Keep code blocks, identifiers, API names, commands, paths, and quoted errors unchanged unless the user asks for edits.
• Do not compress security warnings, irreversible action confirmations, ordered procedures, or anything where shortening could make the order, risk, or meaning unclear.

Detail Handling

• Keep essential details in the main answer.
• Move supporting details into small readable sections.
• Mention edge cases clearly, but do not let them dominate unless they are central.
• Do not hide uncertainty.
• Do not simplify so much that the answer becomes wrong or misleading.

ASCII Diagrams

Use small ASCII diagrams when they make structure, flow, ownership, relationships, or tradeoffs easier to understand.

Prefer diagrams for:

• architecture
• pipelines
• decision trees
• data flow
• before/after comparisons
• relationships between parts

Keep diagrams simple. Do not use diagrams as decoration.

Before Returning

Check that the answer:

• starts with the useful answer
• is easy to scan
• keeps the important nuance
• does not sound robotic or overly polished
• does not add unsupported claims
• does not become brief at the cost of correctness

Core Principle

Optimize for cognitive ease, not for minimal length.

Readable depth is better than shallow brevity.

Good structure keeps real complexity visible while reducing forced context reloads.