chore(source-control): babysit-loop/SKILL.md sits 1 line under the 500-line hard cap, blocking any net-positive edit

[kyle-sexton]

🤖 Agent-authored (autonomous babysit lane), found while fixing #1612 in #1618.

Problem

plugins/source-control/skills/babysit-loop/SKILL.md is 499 lines against a hard cap of 500. plugins/skill-quality/scripts/check-skill.sh fails at >=:

LINE_HARD_CAP=500
LINE_COUNT="$(grep -c '' "$SKILL_MD")"
if ((LINE_COUNT >= LINE_HARD_CAP)); then
  err "SKILL.md is $LINE_COUNT lines (hard cap $LINE_HARD_CAP)"

So the file has exactly zero headroom. Any change that adds a single net line fails skill-quality-gate in CI.

This is not hypothetical — it bound #1618. The correct per-window fail-open rule is necessarily longer than the incorrect one it replaced (it has to state the whole-guard triggers, the per-window trigger, and the "reactive-only only when no window is plausible" floor). Fitting it required reflowing two other paragraphs in the same section to net zero. That worked because those paragraphs genuinely were ragged — orphaned 9- and 42-character wrap lines sitting beside 98-character neighbours — so the reflow was a real improvement rather than a workaround. That is luck, and it is spent. The next edit to this file has no such slack and no obvious ragged prose left to reclaim.

Why this is worth fixing rather than absorbing

The failure mode is bad: a contributor makes a correct, small change and CI rejects it for a reason unrelated to their change. The available responses are all poor — pad lines to unnatural width to game the metric, delete unrelated content, or abandon the edit.

The cap is a proxy for context cost, and the checker already says the real target is much lower. It emits, on this same file:

WARN: SKILL.md is 499 lines (soft target 200 — consider pushing detail to progressive-disclosure spokes)

The warning names the remedy. At 2.5x the soft target and 1 line under the hard cap, this skill has outgrown a single file.

Suggested direction (not prescriptive)

Move a coherent section into a progressive-disclosure spoke under the skill's own directory, which the skill-authoring guidance already treats as the standard shape for a SKILL.md this size. Candidate: the inlined rate-limit guard floor section (~35 lines) — but note a constraint that makes this less trivial than it looks. The loop-lane convention §6 requires each lane body to inline the operable floor because an installed plugin cannot read a sibling plugin's files at runtime. A spoke inside the same plugin does not violate that (${CLAUDE_PLUGIN_ROOT} reach is fine), but the convention's wording says the lane body inlines it, and the values are required to stay byte-identical across all three lanes. Moving it for one lane and not the others would break that symmetry.

So the options are genuinely:

1. Move the same section to a spoke in all three lane skills, keeping symmetry, and update loop-lane convention §6's wording to say "the lane's own plugin" rather than "the lane body". Largest change, cleanest end state.
2. Move some other section of babysit-loop only — it is the outlier at 499 vs 330 and 192, so it likely has lane-specific bulk the others do not. Smallest blast radius.
3. Raise LINE_HARD_CAP. Cheapest and worst: it treats the symptom and defers the same wall.

I lean 2 for cost and blast radius, with 1 as the better long-term shape if the other two lanes also approach the cap. Whoever takes this should confirm against the current file rather than trusting this triage — I did not survey babysit-loop's sections for the best extraction candidate.

Acceptance criteria

• babysit-loop/SKILL.md has meaningful headroom under the hard cap (a target, not one line).
• check-skill.sh still passes for all three lane skills.
• If the rate-limit floor moves, it moves in all three lanes, stays byte-identical across them, and loop-lane convention §6 is updated to match — verified, not assumed.
• No content is deleted to make room; this is a relocation, not a trim.

[kyle-sexton]

🤖 Claim released by the autonomous babysit lane (fable-autopilot) — closed by PR #1627, squash a85b2225. babysit-loop/SKILL.md 499 → 459/500. Sibling finding filed as #1626 (babysit-prs/SKILL.md is also at 499).

[kyle-sexton]

This was generated by AI during triage.

Triage: verified — but the fix is already in flight, so this is deliberately not routed to the autonomous frontier

Verified against origin/main (fe331930), not taken on the report's word. The automated label and bot filing bought this item no shortcut:

Claim	Result
babysit-loop/SKILL.md is 499 lines	Confirmed — grep -c '' on origin/main returns 499
Hard cap is 500 and fails at >=	Confirmed — check-skill.sh:144 LINE_HARD_CAP=500; :324 if ((LINE_COUNT >= LINE_HARD_CAP))
Soft target 200	Confirmed — check-skill.sh:145 LINE_SOFT_CAP=200; the warning fires at :442-443
Therefore zero headroom	Confirmed — 499 against a >=500 failure is exactly one line of slack, and a net-positive edit consumes it

The report's characterization is accurate, including the part that matters most: this is not a hypothetical. Two sibling lane skills sit at 330 (work-loop) and 192 (attend-queue), so babysit-loop is a genuine outlier rather than a fleet-wide pattern — which supports the report's own option 2 over option 1.

Why no agent-ready label

PR #1627 (chore/1620-babysit-loop-headroom) is open and its body opens with Closes #1620. It takes the report's option 2, extracts the pre-escalation dispatch section to reference/pre-escalation-dispatch.md, and reports 499 → 459 (41 lines of headroom). It also confirms — with a section-size survey the triage explicitly deferred — that the rate-limit floor is not extractable for one lane, exactly as this issue predicted, and independently rules out Telemetry for the same §4 runtime-reach reason.

So the work is written and awaiting a merge decision. Labelling this item autonomous-eligible while it is unassigned would put it on the frontier for /work-items:work pickup and manufacture a second, competing PR against the same file. The raw-intake marker is cleared and the priority normalized, but no role label is applied: the item resolves when #1627 merges, via its closing keyword.

If #1627 is closed without merging

This returns to ordinary intake. Its acceptance criteria are already sound and need no rework — re-triage would only need to re-route it, not re-specify it.

Residual, inherited by #1626

Even at 459, babysit-loop remains well above the 200-line soft target, so the warning persists. Whether lane skills are legitimately large — the soft target simply being wrong for them — or whether they should be split further is a judgment call worth making once for all lane skills rather than per-PR. It blocks neither this item nor #1626, so it is recorded here rather than gating either.

_{Role labels resolved from .work-item-tracker.json, which declares no config.role_labels — the canonical roles therefore run on their documented defaults (agent-ready / needs-human); both were confirmed present in this repo's live label set before use.}