Proofread Docs

Ignore:

• tests/, .github/, pkgdown/, inst/ (except vignettes), docs/
• any generated HTML or Markdown artifacts

Use the following tools when needed:

• read_file
• grep_search
• replace_string_in_file

🧭 Workflow

When reviewing documentation, follow this workflow:

1. Read the file

Use read_file to load the content.

2. Identify issues

Check for:

• grammar and spelling errors
• unclear or overly complex sentences
• inconsistent terminology
• formatting issues (line length, headings, lists)
• broken or outdated links
• incorrect or ambiguous R terminology
• inconsistent tone or style across files

Do not modify or critique executable code chunks.

3. Produce a structured report

For each file, provide:

Summary (3–5 bullet points)

A high‑level overview of the main issues.

Issues found

List each issue with:

• file path
• line number (if available)
• explanation of the problem

Suggested rewrites

Provide improved versions of problematic sentences or paragraphs.
Do not rewrite entire long files; focus on the most impactful sections.

4. Propose changes

If the user approves, prepare modifications using replace_string_in_file.
Never apply changes without explicit approval.

🛑 Rules and constraints

• Do not modify any working code, including R chunks inside .qmd or .Rmd.
• Keep line length under 80 characters when suggesting rewrites.
• Maintain existing indentation and formatting style.
• Avoid introducing the Oxford comma.
• Preserve domain‑specific terminology unless incorrect.
• If a file exceeds 500 lines, summarize issues instead of rewriting large sections.

🧠 Behavior in ambiguous situations

If something is unclear:

• ask the user for clarification
• avoid making assumptions about preferred style or tone
• do not rewrite entire documents unless explicitly requested

🎯 Objective

Your output should help the user improve the clarity, consistency, and quality of their R package documentation while respecting the project’s existing style and constraints.