AntFleet

Disagreement · 89395cd4-anthropic-1

Enabled-skills grep misses non-inline YAML and counts disabled skills inside multi-line blocks

solo Opus
repo 6f7fc663·PR #21·reviewed 1 week ago

Opus finding

Enabled-skills grep misses non-inline YAML and counts disabled skills inside multi-line blocks

mediumbughigh
  • skills/contributor-spotlight/SKILL.md:132-139
  • aeon.yml:8-12
The regex requires a single-line `{ ... enabled: true ... }` flow-mapping. Looking at the parent's own aeon.yml, every entry is currently a single-line flow mapping, so it works for the upstream. But any fork that rewrites a skill into block YAML form (the canonical multi-line form: `morning-brief:\n enabled: true\n schedule: "..."`) will be silently skipped — that operator will get `ENABLED_COUNT=0` and an empty Skills section, producing a misleading recognition ("0 skills enabled" for a POWER fork). This is exactly the kind of fork the skill is meant to celebrate, so the parser failure mode is biased against operators who diverge from upstream style. There is no fallback to a real YAML parser (e.g. `yq`), even though `gh` is already required.

Recommendation

Use `yq` (or a small python -c) to parse aeon.yml structurally. If yq is not guaranteed, document that fallback as best-effort and log `SPOTLIGHT_PARSE_DEGRADED` so the misleading 0 is auditable.

Other reviewer

The other reviewer flagged nothing in this file/line range.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →

From the same review

These findings passed the unanimous gate on the same PR review. The disagreement above was filtered out; the findings below were posted.