skill-check misses a make target inside a hard-wrapped inline code span #228

Open
opened 2026-08-28 07:37:24 +00:00 by logan · 0 comments
Collaborator

Report

scripts/skill-check.sh matches a backticked mention with
/`make [a-z][a-z0-9-]*/ — one regex against one line — so an inline
code span that Markdown renders as a single `make dev-headless`
but that the file hard-wraps across two lines is not seen at all.

Measured on docs/220-skill-check-scope (the branch that adds
README.md and CONTRIBUTING.md to the scanned set), by appending this
to CONTRIBUTING.md and running the check:

The end-to-end tier drives the real app with no display at all: `make
no-such-wrapped-target` starts it in the background.
skill-check: 47 documented make targets, all present
exit=0

The same plant on one line fails correctly, so it is the wrap and
nothing else.

It is live, in the file the widening was for. CONTRIBUTING.md:80
already ends in a bare `make — that is make dev-headless, wrapped:

$ grep -n '`make$' README.md CONTRIBUTING.md
CONTRIBUTING.md:80:The end-to-end tier drives the real app with no display at all: `make

Nothing is broken today. dev-headless exists, and it is named on
one line in CLAUDE.md and in .pi/, so the target is covered — by a
different file. What is missing is coverage of a target named only
inside a wrapped span, which is a shape these two files invite: #220
notes both are mostly hard-wrapped prose, and the wrap is what the
author does not think about.

Why it was left rather than fixed in #220. The fence half of the
matching rule exists because line-start alone is not evidence of code in
hard-wrapped prose — a sentence broke onto a line beginning make a and
the check failed on a target called a. Joining lines before matching
re-opens exactly that, so this is not a one-character regex change: it
needs a rule for which line joins are safe (inside an unterminated
inline span, which means counting backticks), and that is a different
piece of work from widening a file list.

Direction

Two candidate answers, and they are not the same size.

  • Cheap and blunt: fail on a line ending in a bare `make,
    telling the author to reflow so the span fits one line. No parsing,
    and it makes the limitation loud instead of silent — but it fails a
    file for its formatting rather than for a wrong target, and there is
    one such line to fix today.
  • Honest: join a line to the next when it ends inside an unclosed
    inline code span (odd backtick count), then match. Correct for the
    real shape, and the fence/line-start half is untouched because a
    fenced command is already whole.

Found while doing #220.

**Report** `scripts/skill-check.sh` matches a backticked mention with `` /`make [a-z][a-z0-9-]*/ `` — one regex against one line — so an inline code span that Markdown renders as a single `` `make dev-headless` `` but that the *file* hard-wraps across two lines is not seen at all. Measured on `docs/220-skill-check-scope` (the branch that adds `README.md` and `CONTRIBUTING.md` to the scanned set), by appending this to `CONTRIBUTING.md` and running the check: ``` The end-to-end tier drives the real app with no display at all: `make no-such-wrapped-target` starts it in the background. ``` ``` skill-check: 47 documented make targets, all present exit=0 ``` The same plant on one line fails correctly, so it is the wrap and nothing else. **It is live, in the file the widening was for.** `CONTRIBUTING.md:80` already ends in a bare `` `make `` — that is `make dev-headless`, wrapped: ``` $ grep -n '`make$' README.md CONTRIBUTING.md CONTRIBUTING.md:80:The end-to-end tier drives the real app with no display at all: `make ``` **Nothing is broken today.** `dev-headless` exists, and it is named on one line in CLAUDE.md and in `.pi/`, so the target is covered — by a different file. What is missing is coverage of a target named *only* inside a wrapped span, which is a shape these two files invite: #220 notes both are mostly hard-wrapped prose, and the wrap is what the author does not think about. **Why it was left rather than fixed in #220.** The fence half of the matching rule exists because line-start alone is not evidence of code in hard-wrapped prose — a sentence broke onto a line beginning `make a` and the check failed on a target called `a`. Joining lines before matching re-opens exactly that, so this is not a one-character regex change: it needs a rule for *which* line joins are safe (inside an unterminated inline span, which means counting backticks), and that is a different piece of work from widening a file list. **Direction** Two candidate answers, and they are not the same size. - **Cheap and blunt:** fail on a line ending in a bare `` `make ``, telling the author to reflow so the span fits one line. No parsing, and it makes the limitation loud instead of silent — but it fails a file for its formatting rather than for a wrong target, and there is one such line to fix today. - **Honest:** join a line to the next when it ends inside an unclosed inline code span (odd backtick count), then match. Correct for the real shape, and the fence/line-start half is untouched because a fenced command is already whole. Found while doing #220.
logan added the Kind/DocumentationKind/Testing
Priority
Low
4
Reviewed
Confirmed
1
labels 2026-08-28 07:37:24 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#228