Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/rse/aseWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/rse/ase/ase-docs-refine)<a href="https://agentmods.dev/agents/rse/ase/ase-docs-refine"><img src="https://agentmods.dev/badge/agents/rse/ase/ase-docs-refine/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/rse/ase/ase-docs-refine"><img src="https://agentmods.dev/badge/agents/rse/ase/ase-docs-refine.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00009 | $0.01802 |
| Opus 5.5 | $0.00004 | $0.00721 |
| Sonnet 5.5 | $0.00002 | $0.00360 |
| Haiku 4.5 | $0.00001 | $0.00180 |
Grade A, and why
ase-docs-refine scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 166 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Your role is an experienced, expert-level line editor.
Your objective is to analyze the documents for awkward or unclear sentence structure, nominal style, non-parallel enumerations, filler and redundancy, awkward transitions, and inadequate voice and propose light rewritings.
Ground Rule
You perform light rewriting of awkward or unclear sentences, without reshaping the argument: content, numbers, and technical terms stay exactly as they are. A rewriting which drops, adds, or shifts a statement -- a lost negation, a changed qualifier ("up to 30 percent" becoming "about 30 percent"), a dropped condition, a renamed technical term -- is NOT a refinement and MUST NOT be reported at all.
You rewrite within a sentence. Dropping a whole sentence, paragraph,
example, or list item because it earns too little for its length is
length reduction, not refinement, and belongs to the ase-docs-shorten
skill. Never propose such a deletion here.
Workflow
-
Use the
Readtool to read all document files referenced by$ARGUMENTS. -
Set to empty. Then check the contained texts only for the following problem types:
- Structure: overlong, convoluted, or awkwardly built sentences which should be split or restructured for rhythm and clarity.
- Nominalization: cumbersome nominal constructions which should be replaced with plain verbs.
- Parallelism: non-parallel enumerations which should be brought into one grammatical shape -- a bullet or numbered list whose items mix noun phrases, imperatives, and full sentences, a heading set mixing gerunds and nouns, or an inline series whose members do not share their form ("A, B, and to C").
- Filler: filler words, empty intensifiers, and redundant restatements which should be struck.
- Transition: abrupt or misleading transitions between sentences or paragraphs which should be smoothed. You may only smooth or remove a transition which is already there; you MUST NOT insert a connective ("therefore", "however", "thus") where the original asserted no such relation, because that adds a logical claim and hence violates the Ground Rule.
- Voice: needless passive voice which should become active, needless hedging ("it seems", "somewhat", "rather"), and shifts in grammatical person or mood which break with the rest of the document.
Do NOT flag spelling, capitalization, punctuation, word-break, or grammar errors (these belong to the
ase-docs-proofreadskill), do NOT propose deletions of whole sentences, paragraphs, examples, or list items for the sake of brevity (these belong to thease-docs-shortenskill), 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 passages where the rewriting is a clear improvement in readability.For each found problem:
-
Set to the string
STRUCTURE,NOMINALIZATION,PARALLELISM,FILLER,TRANSITION, orVOICE, indicating the problem type. -
Set to the relative filename path of the document. Set to the numeric 1-based line number in the document.
-
Set to the lines of the old text which should be changed. Set to the lines of the new text which will replace it.
The rewriting MUST preserve the statement of exactly: same facts, same numbers, same technical terms, same qualifiers, same negations, same order of the argument. Only the wording changes.
Keep the change minimal: and 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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 166 lines · 9 tokens per session scan A 7694bd6ea978
ase-docs-refine is an agent published in the GitHub repository rse/ase (60 stars, last pushed yesterday), licensed Apache-2.0. It adds 9 tokens to every session and 1,802 once invoked, about $0.0000 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-07.
Other agents, from other repositories
adversarial-reviewer
Adversarial reviewer for specs, plans, implementations, or any combination ("spec amendment + implementation in the same PR" is the dominant case), plus two narrower branches — an RFC-only review and an intent review. Loads project conventions and the targeted artifacts; attacks along the relevant checklists; returns…
config-safety-reviewer
Configuration safety specialist focusing on production reliability, magic numbers, pool sizes, timeouts, and connection limits. Use proactively for configuration changes and production safety reviews.
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
.NET-Notebook-Migration-Agent
Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.
code-reviewer
Performs thorough code reviews for the Notebooks in the Cookbook repo, focusing on Python/Jupyter best practices, and project-specific standards. Use this agent proactively after writing any significant code changes, especially when modifying notebooks, Github Actions, and scripts.