comment-added's stated bound is inexact in the same way issue-ref's was, and for the same reason: both apply a leading filter to extracted_comments' output, and that function reports every non-empty continuation line of an open block comment as leading, whatever preceded the opener.
The claim
Three surfaces state it, in near-identical words:
.agents/skills/comment-and-doc-style/SKILL.md "Comments": "A trailing comment is out of scope, since which mid-line marker opens a comment differs by language in ways a gate cannot settle from the marker alone."scripts/README.md's comment-added paragraph: the same, with the four languages spelled out.comment_added_findings' own docstring, which states the marker-position rule without the exclusion.
What actually happens
A file holding
int x = 1; /* the retry is one character
wide and the loop never advanced */
reports comment-added on line 2. The comment is trailing, its only marker sits mid-line and opens nothing, and the rule reads it anyway, because the continuation line carries no marker of its own to judge and extracted_comments hardcodes leading for it.
Why it is filed rather than fixed
A branch adding the sibling issue-ref rule hit this on its own text and tried five wordings of the bound. Each was false in a different way: an exception clause was false for a documentation block comment and for Markdown, and a positive restatement mispredicted both the wrapped block and a trailing HTML comment in instruction Markdown. What settled it was deleting the description from every surface outside the scanner, leaving it in the function where the parser is in view.
That branch restored all three comment-added surfaces to their merge-base bytes rather than carrying the same churn into a rule it was not changing. An earlier round of it had edited them and broke two pronoun referents and a docstring's indentation in the process.
Suggested shape
Two candidates, and the first is what worked next door.
- Delete the bound from the skill and from
scripts/README.md, leaving comment_added_findings' docstring as the single statement, with each of its clauses checked against a fixture. Both files are carried or hub-hosted documentation, and neither has a reader who needs the parser's exact reach.
- Narrow the wording in all three, which is what was tried next door and failed three times.
Either way the finding a wrapped trailing block comment produces is wanted, since it is a real comment carrying real prose, so the behavior stays and only the claim moves.
comment-added's stated bound is inexact in the same wayissue-ref's was, and for the same reason: both apply aleadingfilter toextracted_comments' output, and that function reports every non-empty continuation line of an open block comment as leading, whatever preceded the opener.The claim
Three surfaces state it, in near-identical words:
.agents/skills/comment-and-doc-style/SKILL.md"Comments": "A trailing comment is out of scope, since which mid-line marker opens a comment differs by language in ways a gate cannot settle from the marker alone."scripts/README.md'scomment-addedparagraph: the same, with the four languages spelled out.comment_added_findings' own docstring, which states the marker-position rule without the exclusion.What actually happens
A file holding
reports
comment-addedon line 2. The comment is trailing, its only marker sits mid-line and opens nothing, and the rule reads it anyway, because the continuation line carries no marker of its own to judge andextracted_commentshardcodesleadingfor it.Why it is filed rather than fixed
A branch adding the sibling
issue-refrule hit this on its own text and tried five wordings of the bound. Each was false in a different way: an exception clause was false for a documentation block comment and for Markdown, and a positive restatement mispredicted both the wrapped block and a trailing HTML comment in instruction Markdown. What settled it was deleting the description from every surface outside the scanner, leaving it in the function where the parser is in view.That branch restored all three
comment-addedsurfaces to their merge-base bytes rather than carrying the same churn into a rule it was not changing. An earlier round of it had edited them and broke two pronoun referents and a docstring's indentation in the process.Suggested shape
Two candidates, and the first is what worked next door.
scripts/README.md, leavingcomment_added_findings' docstring as the single statement, with each of its clauses checked against a fixture. Both files are carried or hub-hosted documentation, and neither has a reader who needs the parser's exact reach.Either way the finding a wrapped trailing block comment produces is wanted, since it is a real comment carrying real prose, so the behavior stays and only the claim moves.