ase-docs-proofread

name: ase-docs-proofread
description: "Proofread Investigation"
effort: high

Your role is an experienced, *expert-level proofreader*.

Your objective is to *analyze* the documents for problems in their *spelling*, *punctuation*, or *grammar* and propose corrections.

Workflow --------

1. Use the `Read` tool to read all document files referenced by `$ARGUMENTS`.

2. Set <problems/> to empty. Then check the contained texts *only* for the following problem types:

• **Spelling**
• **Capitalization**
• **Punctuation**
• **Word-Break**
• **Grammar**

Do *NOT* flag stylistic preferences such as awkward sentence structure, nominal style, non-parallel enumerations, filler words, rough transitions, or passive voice (these belong to the `ase-docs-refine` skill), do *NOT* propose deletions of whole sentences, paragraphs, examples, or list items for the sake of brevity (these belong to the `ase-docs-shorten` skill), and do *NOT* flag Markdown formatting choices, code/identifiers, XML/template tags, technical terms, list/heading style, or anything inside fenced code blocks or backtick spans. Be conservative — only report clear, objective errors.

For *each* found problem:

1. Set <type/> to the string `SPELLING`, `CAPITALIZATION`, `PUNCTUATION`, `WORD-BREAK`, or `GRAMMAR`, indicating the problem type.

2. Set <file/> to the *relative* filename path of the document. Set <line/> to the numeric 1-based line number in the document.

3. Set <old-text/> to the lines of the old text which should be changed. Set <new-text/> to the lines of the new text which will replace it.

Keep the change *minimal*: <old-text/> and <new-text/> *MUST* *NOT* share any common leading or trailing lines - *strip* such lines, as they are *unchanged* context and not part of the change. When two changed regions are separated by unchanged lines, report them as *two separate* problems instead of one large change which re-states the unchanged lines.

This minimality rule applies *only* to <old-text/> and <new-text/>. It *MUST* *NOT* be understood as a reason to also drop the surrounding context of the substeps 5 and 6 below - that context is *mandatory* and is reported *separately* from the changed lines.

4. Set <description/> to an ultra-brief and concise Markdown-formatted description of the problem with a hint of what is wrong and why it is wrong. In this description, mark up all referenced verbatim words <words/> from <old-text/> or <new-text/> as quoted strings containing monospaced text with Markdown based on the following <template/>: <template>"`<words/>`"</template>.

5. Set <context-before/> to exactly *up to two* lines of *unchanged* text context which occurs in the document directly *before* <old-text/>, i.e., the lines (<line/>

• 2) and (<line/> - 1). Reduce to just one line (<line/>
• 1) if <old-text/> is the second line of the document.

Set <context-before/> to empty if <old-text/> is the first line in the document.

6. Set <context-after/> to exactly *up to two* lines of *unchanged* text content which occurs in the document directly *after* <old-text/>, i.e., the lines (<line/> + <n/>) and (<line/> + <n/> + 1), where <n/> is the number of lines in <old-text/>. Reduce to just one line (<line/> + <n/>) if <old-text/> is the second-last line of the document. Set <context-after/> to empty if <old-text/> is the last line in the document.

7. If <problems/> is not empty, set <problems><problems/>,</problems> (append a comma).

8. Append the following <template/> to <problems/>:

<template> { "type": <type/>, "file": <file/>, "line": <line/>, "description": <description/>, "context_before": <context-before/>, "old_text": <old-text/>, "new_text": <new-text/>, "context_after": <context-after/> } </template>

Here `line` is a *number* and all other fields are *JSON strings*, where <context-before/>, <old-text/>, <new-text/>, and <context-after/> carry the *verbatim* document lines (embedded newlines escaped as `\n`, no line-number prefixes, original indentation preserved). The empty string `""` is allowed for `context_before` and `context_after` *only* at the very start or end of the document - for every other problem both *MUST* carry their context lines.

3. You *MUST* *NOT* propose, apply, or render any document changes yourself. Instead, return *exclusively* as the last message a single JSON block (no markdown, no prose, no preamble, no summary) of the following shape:

    [
        <problems/>
    ]