Han Feedback — 2026-08-11

Skills used: none (han-feedback:han-feedback ran to file this report; no other Han skill was
invoked) Agents used: none Component under review: the han-communication:han-readability
output style, active for the whole session Context: The user asked for a description of the
latest release as "3 simple sentences, then a few bullet points with simple sentences." Outcome:
It took three user corrections to produce it. Two of the three failures trace to a gap in the
readability standard's own self-check, which has no criterion for the shape the reader asked for.

Scope note. This file is named for the output style rather than for a skill, because the style is
the component the feedback is about and no Han skill fronted the work. The finding also reaches past
the style: the two clauses named below are duplicated in
han-communication/references/readability-rule.md, which every skill that invokes
readability-guidance sources.

What worked well

• The vocabulary blocklist and em-dash rule held across all four drafts. No blocklisted word
  appeared, no em-dash was misused, and the user never once corrected voice. Criterion 5 is doing its
  job.
• "Main point first" held under pressure. Every draft, including the rejected ones, opened with
  the answer rather than with preamble. So did each revision after a correction.
• Descriptive headings held. No draft produced a generic "Summary" or "Analysis" label.
• The standard did not obstruct the fix. Once the constraint was applied deliberately, the simple
  version satisfied all six criteria at the same time. The rules are not in conflict with plain
  writing; nothing had to be broken to comply.

What didn't work

• The self-check has no criterion for the shape the reader asked for. The user stated two format
  constraints in the first turn: three simple sentences, and bullets of simple sentences. Neither had
  an enforcement point. "Preserve every version number" had criterion 6. The result was a
  three-sentence summary carrying four inline version numbers, which is the opposite of what was
  asked. Both readability-rule.md:130 and the style declare the set closed — "these six criteria
  are the whole check" — which forecloses checking anything else, including the reader's own stated
  constraint.
• "Fidelity wins" reads as outranking a request to simplify. readability-rule.md:99 says "If
  reading more simply would drop or blur a fact, fidelity wins." Applied to a request whose entire
  point was simplification, that clause justified keeping the version numbers. The section's closing
  line ("governs how the content is said, never whether a required fact appears") is meant to bound
  it, but "required" is never defined against the reader's request, so every fact in the source reads
  as required.
• The escape hatch is scoped away from the one case that needed it. "Break a rule before writing
  something clumsy" (readability-rule.md:104-113) covers the drafting properties only and states it
  "never licenses a fidelity loss." So when a reader explicitly asks for less detail, the standard
  offers no sanctioned path to give it to them.
• Criterion 4 is a length ceiling, not a simplicity test. A 28-word sentence with four
  parenthetical version numbers passes it. The rejected first draft passed criterion 4 on every
  sentence while being exactly what the user rejected. Nothing in the check distinguishes "short" from
  "simple."
• Nothing checks that a fact belongs under the heading it is placed under. The first bullet list
  ended with "Nine plugins are unchanged" as a major change, which is a category error the user had
  to point out. The same bullet miscounted: the changelog lists eight unchanged plugins. Criterion 6
  guards a fact's precision but never asks whether the fact belongs where it was put, and it does not
  catch a count the draft itself introduced.
• Cost: four turns for a request fully specified in turn one. Every constraint needed was stated
  before the first draft. Three of the four turns were spent recovering constraints already given.

Proposal

1. Add a seventh self-check criterion to readability-rule.md and the output style: the draft
   matches the shape the reader asked for in count, format, and register. State that an explicit
   reader constraint outranks the other six when they conflict. This requires reopening the "these six
   criteria are the whole check" line, which is deliberate closure, so it is a real decision and not a
   typo fix.
2. Scope-note "Fidelity wins" so it does not outrank an explicit instruction to simplify. A
   workable form: when the reader asks for fewer facts, a fact moves to a layer they can reach (a
   later section, a linked document, an offer to expand) or is dropped with the drop named. It stays
   absolute against silent loss, which is the failure the section was written to prevent.
3. Consider whether criterion 4 needs a simplicity test beside its length ceiling, since short and
   simple came apart cleanly here.

Overall

The standard's voice rules worked perfectly and its structural rules worked perfectly. What failed is
that the standard optimizes for completeness with no counterweight, and the reader had explicitly
asked for the counterweight. A closed six-item check that names fact preservation but never names the
reader's request will reliably lose that trade, which is what happened three times in one short
session. The fix is small and lands in two files, but it touches two clauses written as deliberate
absolutes, so it deserves a decision rather than a quiet edit.

Rating

Ratings apply to the output style, since no Han skill or agent fronted the work.

Accuracy 2/5: the delivered first draft carried a category error and a miscount, both of which passed
the six-criterion check. Evidence discipline 4/5: every claim traced to CHANGELOG.md with no
fabrication; the miscount was a counting slip in new prose, not a sourcing failure. Signal-to-noise
n/a: no agents ran, so there were no findings to score. Length 1/5: this is the central failure —
three simple sentences were requested and four version-number-dense ones were delivered, then five
multi-sentence bullets against a request for simple ones. Turn efficiency 1/5: four turns for a
request whose every constraint was stated in the first.