The generator's own SKILL.md is 7k tokens with zero references — 52% of it loads before the run knows it can proceed

Measured against main today.

Not a duplicate of #67. That one is about the generated skill. This is about this repo's own SKILL.md — the file the agent loads to run a conversion.

Measurement

36,517 bytes · 702 lines · 5,247 words ≈ 7,000 tokens
references to other files ........ 0
inside code fences ............... 270 lines (38%)

Line budget by step:

Steps 7–11 are 367 lines, 52% of the file, and none of it is needed until after the user confirms the cost estimate at Step 2.5. Point the tool at a scanned PDF and it aborts at Step 2 having already loaded the entire GitHub-publishing procedure.

Why it matters

Not tokens, mostly. ~7k of instructions against a job that reads a 250k-token book is roughly 3% overhead, and SKILL.md only loads when the skill triggers. Real, but small. Not the argument.

Two stronger arguments:

Maintainability. 702 lines of linear procedure in one file, against 25 open issues and 2,303 forks. Reviewing a change to Step 7 means loading Step 11.

It contradicts the product. The generated skill is SKILL.md ~4k plus chapters loaded on demand — that's the thing being sold, and docs/performance.md measures what it's worth. The generator is one 7k block with no deferred loading at all: 1.75× the size of the artifact it optimises. #67 asks for more progressive disclosure in the output while the tool itself has none. docs/ doesn't close the gap — that's documentation for readers on GitHub, not reference material the agent can load.

The ## Step N headings are already clean boundaries, so this is reorganisation rather than redesign.

Environment: main, measured with wc, fence counting and step-boundary parsing over the raw file.