Repository navigation
docs: one paragraph per line in km's Markdown, no hard wrap - #44
Merged
Merged
Conversation
Every tracked Markdown file except the eval cases' prompts and graders (test inputs) and the test fixtures: hard-wrapped lines are joined into their paragraph or list item. Front matter, fenced code, tables, HTML and placeholder lines, headings, block quotes and separate list items are untouched. Whitespace only: with whitespace runs normalised, every file is identical; the counts of headings, fences, table rows, list items, blank lines and hard breaks are unchanged; pandoc renders the same HTML.
pasrom
force-pushed
the
docs/unwrap-markdown
branch
from
November 7, 2026 21:51
30c4297 to
1be2013
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
km's Markdown was hard-wrapped at about 100 characters, so every edit of a sentence reflowed its whole paragraph and the diff showed lines that did not change. This makes it one paragraph per line, as the brains' own Markdown is written.
Regenerated on
mainafter #42, #43 and #45 merged (all three edit Markdown): the branch was reset tomainandunwrap.pyandprove.pybelow were rerun on the same file list, so this is one commit on top ofmain. #45 added no Markdown file (its new templates are a Python script and a workflow), so the list is the same 19 files. The templates undersrc/km/templates/are written verbatim into brains, where a hard wrap would not matter to the renderer; they are included anyway, so that km's own Markdown and what it writes follow one style.What changes
Every tracked
*.mdexcept the test fixtures (tests/fixtures/) and the eval cases' prompts and graders (evals/*/, inputs of the plugin evals): 19 files, of which 15 change. A hard-wrapped line is joined onto the line before it when that one is paragraph or list-item text without a hard break, and the line itself starts no block. Never touched: front matter (the skill'sdescription: >-block stays as it is), fenced code, tables, HTML lines (a comment, a block tag, or a line that is one tag or placeholder, such as<FOLDER_ROWS>and<PLACEMENT_RULES>; a text line that only opens with a placeholder, such as<TEAM>'s shared ...or a wrapped<url> --file ..., is paragraph text and joins), headings, block quotes, link definitions, rules, and separate list items; a list item's wrapped continuation joins into its item.Proof: whitespace only
prove.py HEAD~1 <files>(below) checks per file: (1) text: with every whitespace run normalised to one space, old and new are identical; (2) structure: the counts of headings, fence lines, table rows, list items, blank lines, HTML lines, quotes and hard breaks are unchanged, so no join swallowed a block; (3) render: pandoc (gfm) renders the same HTML, whitespace normalised. Output:Also:
git diff --word-diff=porcelain HEAD~1lists no changed word.prove.py
unwrap.py, the script that made the change (idempotent: a second run joins nothing)
Evals
The change touches
skills/km/, and CLAUDE.md asks for the plugin evals on such a change. They were not run: the proof above shows the skill text is the same word for word, so they would measure the model's variance, not the change, at a cost. That is your call; the cases to run for a core change are all of them (evals/README.md).Reviews
/simplify: no code in the change, nothing to simplify./code-reviewon the regenerated commit, findings and what was done:skills/km/reference/setup.md"Keeping the copy current", thecites:item in the team CONVENTIONS template, the first paragraph of the team README template), because the firstunwrap.pytreated every line starting with<as HTML. It now treats a line as HTML only when it is a comment, a CommonMark block tag, or one tag or placeholder alone;prove.py's HTML count uses the same rule (the pandoc check stays the independent one). A scan for two adjacent text lines outside fences finds none left.tests/skill_inventory.py(SKILL.md at most 500 lines, a## Contentslist in a reference file over 100 lines) bind far less once a paragraph is one line:review-and-pr.md,setup.mdandvalidate-and-gate.mdnow fall below 100 lines with the same text (they keep their Contents lists).CORE_BYTESis unaffected: SKILL.md went from 11,408 to 11,384 bytes (the joins swap a newline for a space and drop list-continuation indent), and the bytes-per-token mix is the same text. A follow-up could move the line limits to bytes.skills/km/reference/queue.md), 1,772 (validate-and-gate.md) and 1,667 characters (README.md), below the 2,000 characters at which Claude Code's Read tool cuts a line. A follow-up could add a line-length check to the skill inventory.All smoke suites pass locally on the regenerated commit: gate 116, index 30, pins 37, cites 87, doctor 57, sync 63, list 40, skill 2, hook 23, mounted_pins 2, team 141, encoding 4, each with 0 failed.