notation-review
Skill4 starsChanged 4 months agoMITView on GitHub
Use when the user asks to review, simplify, or standardize mathematical notation. Do not use for proof, prose, or document-flow review.
In this repository45 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- bib-auditSkill
- bootstrap-dispatcher-runtimeSkill
- ci-debugSkill
- cloud-filesSkill
- connect-googleSkill
- daily-planSkill
- distill-to-ruttersSkill
- email-clientSkill
- email-triageSkill
- find-handoff-candidatesSkill
- formal-prose-reviewSkill
- get-weatherSkill
- git-workflowSkill
- hook-makerSkill
- initialize-tddSkill
- install-launchersSkill
- latex-workshopSkill
- list-managerSkill
- llm-wakeupSkill
- loose-modeSkill
- make-tex-docstringSkill
- math-dependency-graphSkill
- milestone-loggingSkill
- node-certifySkill
- node-driftSkill
- online-calendarSkill
- pdf-to-markdownSkill
- prepare-handoffSkill
- proof-auditSkill
- recurring-tasksSkill
- refactor-nodeSkill
- regenerate-blueprintsSkill
- relocate-nodesSkill
- semantic-integrationSkill
- send-feedbackSkill
- setup-interface-managerSkill
- skill-makerSkill
- technical-flow-reviewSkill
- tight-modeSkill
- tool-applicabilitySkill
- update-standardsSkill
- using-compassSkill
- wrap-upSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 23 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈23
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
When this skill is used, begin with:
- Distinctive: line 34
When reviewing a notation choice:
- Distinctive: line 35
check how the same object or notation family appears earlier and later in the document
- Distinctive: line 37
do not improve notation locally in a way that creates inconsistency globally
- Distinctive: line 39
Prefer diagnosis first. Do not rewrite notation globally unless the user asks.
- Distinctive: line 48
Keep the answer concise and diagnosis-first.
- Distinctive: line 50
When structure helps, use short headings such as:
- Distinctive: line 56
Do not force a fixed template.
- Distinctive: line 77
If two things are mostly the same thing, that should be visible in the notation.
- Distinctive: line 79
If a distinction is mathematically real, encode it with the lightest modifier that makes the distinction clear.
- Distinctive: line 83
Prefer standard conventions when they fit the paper, but treat field-specific conventions as primary.
- Distinctive: line 84
Do not import notation from a foreign area if it will look unnatural to readers in the paper's own field.
- Distinctive: line 97
When auditing notation, check for:
- Distinctive: line 131
When two objects are variants of one mathematical object:
- Distinctive: line 132
prefer one base symbol with light modifiers
- Distinctive: line 134
use a notation scheme that can extend to later sections
- Distinctive: line 144
Do not force unification when it hides an important difference.
- Distinctive: line 147
Use local notation for temporary objects and global notation for recurring objects.
- Distinctive: line 149
Prefer notation schemes that survive:
- Distinctive: line 163
ask before rewriting text or changing notation globally
- Distinctive: line 165
When proposing a notation change:
- Distinctive: line 168
prefer the smallest coherent change over a total renaming
- Distinctive: line 171
keep macro names mathematically transparent and source-readable
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- BEGIN BLUEPRINT INTERFACES -->Generated from
blueprint.yaml. Do not edit this block by hand.
Used Interfaces: none
<!-- END BLUEPRINT INTERFACES -->When this skill is used, begin with:
Skill: notation-review
1. Goal
Your job is to audit mathematical notation, not prose.
Optimize for notation that is:
- easy to understand and follow on first encounter
- light rather than heavy
- unified across the document
- reusable across scopes
- semantically transparent
- readable both in formulas and in the TeX source
Once the notation is understood, the mathematics should be readable with minimal reliance on explanatory text.
2. Review stance
Audit notation at the document level, not just the local paragraph or section, unless the user explicitly asks for a local review only.
When reviewing a notation choice:
- check how the same object or notation family appears earlier and later in the document
- assess it from the viewpoint of a new reader in the same field
- do not improve notation locally in a way that creates inconsistency globally
Prefer diagnosis first. Do not rewrite notation globally unless the user asks.
3. Output
Start with:
Mode: ExploreSkill: notation-review
Keep the answer concise and diagnosis-first. Organize only when useful. When structure helps, use short headings such as:
Main issuesUnificationConventionsCandidate scheme
Do not force a fixed template.
4. Principles
Prefer:
- lighter notation over heavier notation
- one notation family for one mathematical family
- notation that reflects mathematical similarity
- notation that highlights essential parameters and suppresses routine ones
- notation that scales across local and global scopes
- notation standard in the paper's field or immediate literature
- TeX macros that improve consistency, maintainability, and source readability for the author
Avoid:
- unnecessary hats, tildes, bars, primes, stars, long subscripts, and overloaded superscripts
- introducing a fresh symbol for something that is mostly the same object
- using unrelated symbols for closely related objects
- reusing one symbol family for genuinely different objects
- introducing notation used only once or twice unless it materially improves readability
- macros that make the TeX source harder to scan than the underlying notation
If two things are mostly the same thing, that should be visible in the notation.
If a distinction is mathematically real, encode it with the lightest modifier that makes the distinction clear.
5. Conventions
Prefer standard conventions when they fit the paper, but treat field-specific conventions as primary. Do not import notation from a foreign area if it will look unnatural to readers in the paper's own field.
Examples of common defaults:
- compact sets as
K - open sets as
U - balls as
B - nonnegativity as
+ - strict positivity as
++
These are defaults, not rigid rules. If the paper has a strong local convention, preserve it and extend it consistently.
6. What to check
When auditing notation, check for:
Heavy notation- a symbol carries more decoration than the mathematics needs
False split- two nearly identical notions are written with unrelated notation
False unification- genuinely different notions are written as if they were the same
Family mismatch- related objects are not presented as a coherent notation family
Scope drift- notation changes across sections even though the role is unchanged
Type ambiguity- notation does not signal whether an object is a set, map, scalar, vector, parameter, or operator
Semantic opacity- notation does not help the reader see what the object is or how it relates to nearby objects
Parameter overload- notation exposes too many parameters or distinctions at once
Unnecessary notation- a symbol is introduced where direct formulas or ordinary mathematical language would be clearer
Convention mismatch- notation fights the paper's local conventions
Field mismatch- notation follows conventions from a different area rather than the paper's own field
Literature mismatch- notation departs from common usage in the relevant area without enough benefit
Macro opacity- macros make the TeX source harder to read than the raw notation would
Macro inconsistency- recurring global notation is not centralized in macros when it should be
Reader friction- a new reader in the same field would struggle to decode the notation quickly
7. Unification and scope
When two objects are variants of one mathematical object:
- prefer one base symbol with light modifiers
- reserve modifiers for real distinctions
- use a notation scheme that can extend to later sections
Examples of distinctions that often belong to one notation family:
- local vs global
- pointwise vs setwise
- primal vs dual
- constrained vs unconstrained
- interior vs closure vs boundary
- deterministic vs randomized
Do not force unification when it hides an important difference.
Define notation at the widest scope where it remains coherent, but no wider. Use local notation for temporary objects and global notation for recurring objects.
Prefer notation schemes that survive:
- a change of domain
- a local-to-global upgrade
- restriction to a subset
- passage from a point to a set
- passage from an object to its derived quantity
8. How to propose fixes
By default:
- diagnose the notation system
- identify the main points of friction
- propose a candidate unified scheme
- explain what should be merged, what should stay separate, and why
- ask before rewriting text or changing notation globally
When proposing a notation change:
- first ask whether the best fix is to remove notation rather than rename it
- preserve the paper's local conventions where reasonable
- prefer the smallest coherent change over a total renaming
- explain the organizing principle behind the new notation
- recommend macros when notation recurs globally or may change later
- keep macro names mathematically transparent and source-readable
9. What not to do
Do not:
- drift into proof checking unless notation blocks the mathematics
- turn notation review into prose editing
- recommend heavy notation just to make every distinction explicit
- standardize blindly when the paper's own convention is already better for this context
- rewrite large sections unless the user asks for line edits, a LaTeX block, or a full replacement
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

