You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Our own advice about the em-dash is written with em-dashes #82
Not a correctness defect. The engine never analyses its own strings, and no string is long enough to be judged: EmDashAnalyzer skips anything under 40 words and a suggestion has eight. This exists only as a reader noticing it.
Not a rule against the em-dash. The rule measures density. A deliberate dash in a sentence is fine and the skill says so — "keep em-dashes rare and deliberate."
That rule protects a judged text from being edited to move its own number. The test that settles this case without arguing about categories:
Does the edit change what the tool says about anyone else's text?
Rewriting mix, blend, range — or just name the thing as mix, blend, range; or name the thing changes no threshold, no rule and no score for any user. It is not tuning the instrument. Changing EmDashAnalyzer's thresholds would be, and is out of bounds.
Scope, and the part that is explicitly out of it
SKILL.md is not in scope. It is a real 2,208-word document that people paste into the engine, so it is a judged text, and rewriting it to lower its score is precisely what the line above forbids. After #80 it reads Low anyway, as a consequence and not as a goal.
Guard rails for whoever takes this
Most of these read fine as they are. If a rewrite reads worse, leave it. A clumsy suggestion is worse than a consistent one.
Do not add a test demanding zero em-dashes in the packs. The product measures density; a prohibition test would contradict it. If it needs guarding at all, guard density over the user-facing strings at the same 1.0/100 the rule applies to everyone.
Activity