refine(pseudo): drop one-screen cap, allow prose in a supporting role

Remove the hard one-screen length limit entirely; replace the
former cap (rule 9) with a single-altitude guidance that leans
on the reference markers to let the user steer the zoom instead
of a fixed length.

Loosen the prose ban: prose is now allowed, but only in a
supporting role — the pseudocode block stays the centre of every
answer and prose explains what the code cannot show on its own.
Iron Law, overview, rule 1, worked example, frontmatter, and
README updated to match.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -38,8 +38,9 @@ human-readable pseudocode for explaining code — each answer opens
 with a source-file-and-line anchor, marks notable steps with
 reference markers the user can point back at, sketches the
 layout of the data structures the code touches alongside the
-flow, reduces the irrelevant to stubs, omits low-level
-mechanics, and never runs longer than one screen. It dispatches
+flow, reduces the irrelevant to stubs, and omits low-level
+mechanics. Prose is allowed only in a supporting role — the
+pseudocode block stays the centre of every answer. It dispatches
 no agents.
 
 Vocabulary is configurable. A **cycle** is one round in the

pseudo/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pseudo
-description: Use when the user wants code explained in human-readable, commented pseudocode rather than prose — invoked as `/pseudo` or when the user asks to "explain this in pseudocode". Every reply is pseudocode only; no prose paragraphs, opens with a source-file-and-approximate-line anchor, tags notable steps with reference markers ([1], [A]) the user can point back at, and sketches the layout of the data structures the code touches alongside the control flow. Strips detail irrelevant to the question and omits low-level mechanics (memory management, error plumbing) unless the question is about them. Defaults to the project's main entry point.
+description: Use when the user wants code explained in human-readable, commented pseudocode rather than prose — invoked as `/pseudo` or when the user asks to "explain this in pseudocode". Every reply is centred on a pseudocode block (prose is allowed, but only in a supporting role to explain what the code cannot show); opens with a source-file-and-approximate-line anchor; tags notable steps with reference markers ([1], [A]) the user can point back at; and sketches the layout of the data structures the code touches alongside the control flow. Strips detail irrelevant to the question and omits low-level mechanics (memory management, error plumbing) unless the question is about them. Defaults to the project's main entry point.
 ---
 
 # pseudo — explain code as commented pseudocode
@@ -11,9 +11,11 @@ description: Use when the user wants code explained in human-readable, commented
 
 The user wants to understand how code works without reading the
 code. The medium of explanation is **commented pseudocode** —
-not prose, not the real source. The pseudocode is a teaching
-artefact: it shows the shape of the logic at the altitude the
-question demands, and nothing more.
+not the real source, and not prose carrying the explanation on
+its own. Prose has a place, but a supporting one: it explains
+what the code cannot show and then gets out of the way. The
+pseudocode is a teaching artefact: it shows the shape of the
+logic at the altitude the question demands, and nothing more.
 
 This is a conversational behaviour skill. It dispatches no
 agents and runs no pipeline. While it is active, every answer
@@ -22,20 +24,25 @@ obeys the rules below.
 ## The Iron Law
 
 ```
-EVERY ANSWER IS PSEUDOCODE. NO PROSE PARAGRAPHS.
+PSEUDOCODE IS THE CENTRE OF EVERY ANSWER; PROSE ONLY SERVES IT.
 EVERY ANSWER OPENS WITH ITS SOURCE FILE AND APPROXIMATE LINE.
 MARK THE NOTABLE POINTS SO THE USER CAN POINT BACK AT THEM.
 SHOW ONLY WHAT THE QUESTION IS ABOUT — REDUCE THE REST TO A STUB.
 SKETCH THE DATA SHAPES THE CODE TOUCHES, NOT JUST THE CONTROL FLOW.
 OMIT LOW-LEVEL MECHANICS UNLESS THE QUESTION IS ABOUT THEM.
-NEVER LONGER THAN ONE SCREEN.
 ```
 
 ## Rules
 
-1. **Pseudocode is the whole answer.** No introductory sentence,
-   no closing summary. If something must be said in words, it is
-   said as a `# comment` inside the pseudocode block.
+1. **Pseudocode carries the answer; prose serves it.** The
+   pseudocode block is the centre of every reply. Prose *is*
+   allowed — but only to explain something the code cannot show
+   on its own, and it stays subordinate: a short note before or
+   after the block, never the main event. Reach first for a
+   `# comment` inside the block; spend a sentence of prose only
+   when the point needs more room than a comment gives. If a
+   reply is mostly prose with a token snippet, the balance is
+   wrong.
 
 2. **Anchor line first.** The block opens with a `# comment`
    naming the source file and the approximate line the
@@ -80,10 +87,12 @@ NEVER LONGER THAN ONE SCREEN.
    / primary CLI or server bootstrap). Otherwise start where
    they point.
 
-9. **One screen, hard limit.** No answer exceeds roughly one
-   screen page. If the explanation does not fit, show the top
-   level as stubs and offer to expand one stub next — let the
-   user steer the zoom rather than dumping everything.
+9. **Stay at one altitude; let the user zoom.** There is no
+   length cap, but each answer holds a single altitude rather
+   than expanding every branch at once. When a level has more
+   depth than the question needs, show that level and let the
+   markers invite the user to expand one point next — steer the
+   zoom with them rather than dumping every layer unprompted.
 
 ## Shape of a good answer
 
@@ -108,11 +117,13 @@ That is a whole answer. It opens with the file-and-line anchor,
 sketches the `Router` shape `[1]` right beside the code that
 reads it (only the field on the topic path; the rest stubbed),
 keeps the request path in focus, stubs the config load, omits
-the socket and memory mechanics, marks the discussable steps,
-and fits one screen. The user can now say "expand [2]" and the
-next answer zooms into route matching — with its own anchor line.
+the socket and memory mechanics, and marks the discussable
+steps. It holds one altitude: the user can now say "expand [2]"
+and the next answer zooms into route matching — with its own
+anchor line.
 
 ## When to stop
 
 The skill stays active for the conversation. The user leaves it
-by asking for normal prose, invoking another skill, or saying so.
+by asking for a plain prose explanation (one not built around a
+pseudocode block), invoking another skill, or saying so.