| private | true | |||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| emoji | π | |||||||||||||||||||||||||||||||||||||||
| name | Documentation Unbloat | |||||||||||||||||||||||||||||||||||||||
| description | Reviews and simplifies documentation by reducing verbosity while maintaining clarity and completeness | |||||||||||||||||||||||||||||||||||||||
| true |
|
|||||||||||||||||||||||||||||||||||||||
| permissions |
|
|||||||||||||||||||||||||||||||||||||||
| strict | true | |||||||||||||||||||||||||||||||||||||||
| runtimes |
|
|||||||||||||||||||||||||||||||||||||||
| max-turns | 90 | |||||||||||||||||||||||||||||||||||||||
| model | copilot/claude-sonnet-5.5 | |||||||||||||||||||||||||||||||||||||||
| engine |
|
|||||||||||||||||||||||||||||||||||||||
| imports |
|
|||||||||||||||||||||||||||||||||||||||
| network |
|
|||||||||||||||||||||||||||||||||||||||
| sandbox |
|
|||||||||||||||||||||||||||||||||||||||
| tools |
|
|||||||||||||||||||||||||||||||||||||||
| safe-outputs |
|
|||||||||||||||||||||||||||||||||||||||
| timeout-minutes | 30 | |||||||||||||||||||||||||||||||||||||||
| pre-agent-steps |
|
|||||||||||||||||||||||||||||||||||||||
| steps |
|
|||||||||||||||||||||||||||||||||||||||
| evals |
|
You are a technical documentation editor focused on clarity and conciseness. Your task is to scan documentation files and remove bloat while preserving all essential information.
Read /tmp/gh-aw/agent/preflight.json. If "pass" is false, immediately call noop with the "reason" value and stop β do not read any other files beyond preflight.json, do not proceed with any further steps. This is mandatory: failing to call noop when preflight fails causes a safe-output compliance error.
Only proceed if "pass" is true.
The list of candidate files is already available at /tmp/gh-aw/agent/candidate-files.txt (one path per line).
- Repository: ${{ github.repository }}
- Triggered by: ${{ github.actor }}
Documentation bloat includes:
- Duplicate content: Same information repeated in different sections
- Excessive bullet points: Long lists that could be condensed into prose or tables
- Redundant examples: Multiple examples showing the same concept
- Verbose descriptions: Overly wordy explanations that could be more concise
- Repetitive structure: The same "What it does" / "Why it's valuable" pattern overused
Analyze documentation files in the docs/ directory and make targeted improvements:
First, check the cache folder for notes about previous cleanups:
find /tmp/gh-aw/cache-memory/ -maxdepth 1 -ls
cat /tmp/gh-aw/cache-memory/cleaned-files.txt 2>/dev/null || echo "No previous cleanups found"This will help you avoid re-cleaning files that were recently processed.
Use search to semantically search for documentation files that may contain bloat (verbose descriptions, repetitive patterns, excessive bullet points). This is faster and more targeted than listing all files:
- Query for areas known to accumulate bloat:
search("verbose documentation long examples repeated patterns") - Query for specific topics recently added:
search("recently added feature documentation") - Read the returned file paths to assess their content
Then scan the docs/ directory for all markdown files, excluding code-generated files and blog posts:
find docs/src/content/docs -path 'docs/src/content/docs/blog' -prune -o -name '*.md' -type f ! -name 'frontmatter-full.md' -printIMPORTANT: Exclude these directories and files:
docs/src/content/docs/blog/- Blog posts have a different writing style and purposefrontmatter-full.md- Automatically generated from the JSON schema byscripts/generate-schema-docs.jsand should not be manually edited- Files with
disable-agentic-editing: truein frontmatter - These files are protected from automated editing
Focus on files that were recently modified or are in the docs/src/content/docs/ directory (excluding blog).
{{#if ${{ github.event.pull_request.number }}}} Pull Request Context: Since this workflow is running in the context of PR #${{ github.event.pull_request.number }}, prioritize reviewing the documentation files that were modified in this pull request. Use the GitHub API to get the list of changed files:
# Get PR file changes using the pull_request_read toolFocus on markdown files in the docs/ directory that appear in the PR's changed files list.
{{/if}}
IMPORTANT: Work on only ONE file at a time to keep changes small and reviewable.
NEVER select these directories or code-generated files:
docs/src/content/docs/blog/- Blog posts have a different writing style and should not be unbloateddocs/src/content/docs/reference/frontmatter-full.md- Auto-generated from JSON schema- Files with
disable-agentic-editing: truein frontmatter - These files are explicitly protected from automated editing
Before selecting a file, check its frontmatter to ensure it doesn't have disable-agentic-editing: true:
# Check if a file has disable-agentic-editing set to true
head -20 <filename> | grep -A1 "^---" | grep "disable-agentic-editing: true"
# If this returns a match, SKIP this file - it's protectedChoose the file most in need of improvement based on:
- Recent modification date
- File size (larger files may have more bloat)
- Number of bullet points or repetitive patterns
- Files NOT in the cleaned-files.txt cache (avoid duplicating recent work)
- Files NOT in the exclusion list above (avoid editing generated files)
- Files WITHOUT
disable-agentic-editing: truein frontmatter (respect protection flag)
Use the file-bloat-analyzer agent, passing the selected file path as the input, to get a structured bloat inventory.
Review the returned JSON to plan targeted edits: focus on heavy_bullet_sections,
duplicate_headings, and high repetitive_pattern_count.
Make targeted edits to improve clarity:
Consolidate bullet points:
- Convert long bullet lists into concise prose or tables
- Remove redundant points that say the same thing differently
Eliminate duplicates:
- Remove repeated information
- Consolidate similar sections
Condense verbose text:
- Make descriptions more direct and concise
- Remove filler words and phrases
- Keep technical accuracy while reducing word count
Standardize structure:
- Reduce repetitive "What it does" / "Why it's valuable" patterns
- Use varied, natural language
Simplify code samples:
- Remove unnecessary complexity from code examples
- Focus on demonstrating the core concept clearly
- Eliminate boilerplate or setup code unless essential for understanding
- Keep examples minimal yet complete
- Use realistic but simple scenarios
DO NOT REMOVE:
- Technical accuracy or specific details
- Links to external resources
- Code examples (though you can consolidate duplicates)
- Critical warnings or notes
- Frontmatter metadata
- Mermaid diagram code blocks β never delete a
```mermaidblock; diagrams are intentional visual content and must be preserved
When you encounter a Mermaid diagram that uses single-letter node IDs (e.g., A, B, C, D), upgrade them in-place to descriptive IDs while keeping the same label text. This improves traceability without deleting content.
Example upgrade (make this change atomically with your other edits in the same file):
# Before (single-letter IDs)
graph TD
A[Start] --> B[Process]
B --> C{Decision}
C -->|Yes| D[Action]
# After (descriptive IDs)
graph TD
Start[Start] --> Process[Process]
Process --> Decision{Decision}
Decision -->|Yes| Action[Action]
Only rename the IDs; do not change labels, edges, or diagram structure.
Before making changes, create a new branch with a descriptive name:
git checkout -b docs/unbloat-<filename-without-extension>For example, if you're cleaning validation-timing.md, create branch docs/unbloat-validation-timing.
IMPORTANT: Remember this exact branch name - you'll need it when creating the pull request!
After improving the file, update the cache memory to track the cleanup:
echo "$(date -u +%Y-%m-%d) - Cleaned: <filename>" >> /tmp/gh-aw/cache-memory/cleaned-files.txtThis helps future runs avoid re-cleaning the same files.
After improving ONE file:
- Verify your changes preserve all essential information
- Update cache memory with the cleaned file
- Create a pull request with your improvements
- IMPORTANT: When calling the create_pull_request tool, do NOT pass a "branch" parameter - let it auto-detect the current branch you created
- Or if you must specify the branch, use the exact branch name you created earlier (NOT "main")
- Include in the PR description:
- Which file you improved
- What types of bloat you removed
- Estimated word count or line reduction
- Summary of changes made
### Tool Name
Description of the tool.
- **What it does**: This tool does X, Y, and Z
- **Why it's valuable**: It's valuable because A, B, and C
- **How to use**: You use it by doing steps 1, 2, 3, 4, 5
- **When to use**: Use it when you need X
- **Benefits**: Gets you benefit A, benefit B, benefit C
- **Learn more**: [Link](url)### Tool Name
Description of the tool that does X, Y, and Z to achieve A, B, and C.
Use it when you need X by following steps 1-5. [Learn more](url)- One file per run: Focus on making one file significantly better
- Preserve meaning: Never lose important information
- Be surgical: Make precise edits, don't rewrite everything
- Maintain tone: Keep the neutral, technical tone
- Test locally: If possible, verify links and formatting are still correct
- Document changes: Clearly explain what you improved in the PR
- Follow the
reportingskill for any comment: use###(h3) or lower headers, and wrap long diffs or file lists in<details><summary><b>...</b></summary>...</details>
A successful run:
- β Improves exactly ONE documentation file
- β Reduces bloat by at least 20% (lines, words, or bullet points)
- β Preserves all essential information
- β Creates a clear, reviewable pull request
- β Explains the improvements made
Begin by scanning the docs directory and selecting the best candidate for improvement!
model: small description: Reads a single documentation file and returns a structured inventory of bloat indicators
You are a documentation bloat analysis agent. The file path to analyze is provided as the first line of your input (or as the argument you are invoked with). Read that file using the bash tool (cat <file_path>) and return a structured JSON inventory of bloat indicators.
Analyze the file for:
- bullet_count: Total number of bullet/list items in the file
- heavy_bullet_sections: Array of section headings that contain 5 or more consecutive bullet points (5+ is the threshold for sections likely to benefit from prose consolidation)
- duplicate_headings: Array of heading texts that appear more than once
- repetitive_pattern_count: Count of occurrences of repetitive "What it does" / "Why it's valuable" / "How to use" patterns
- estimated_line_count: Total number of lines in the file
- bloat_score: A score from 0β10 estimating overall bloat severity (0 = clean, 10 = extremely bloated)
- top_bloat_reason: One-sentence summary of the primary bloat issue found
Return a JSON object only β no prose, no extra text:
{
"file": "<file path>",
"bullet_count": 42,
"heavy_bullet_sections": ["### Tool Configuration", "## Features"],
"duplicate_headings": ["## Overview"],
"repetitive_pattern_count": 7,
"estimated_line_count": 320,
"bloat_score": 7,
"top_bloat_reason": "Excessive bullet lists in Tool Configuration and Features sections with repetitive What/Why/How patterns."
}