Primary finding
ENABLED_COUNT grep over-counts due to comment-stripping claim that is false for this repo's aeon.yml
mediumbughigh
- skills/fork-cohort/SKILL.md:98-104
- skills/fork-cohort/SKILL.md:211-214
- aeon.yml:190-196
- aeon.yml:200-201
- aeon.yml:172
The skill claims `grep -E "enabled:\s*true"` is safe because "comment lines starting with `#` are skipped by the grep on a typical aeon.yml." That claim is wrong on two counts. First, `grep` does not skip `#`-prefixed lines — it matches anywhere on a line. Second, even ignoring comments, the actual aeon.yml in this PR contains non-skill `enabled: true` matches: `channels.jsonrender.enabled: true`, `telegram.enabled: true`, and inline comments like `# Set to true ...` that the regex will hit on the word `true` if preceded by `enabled:` punctuation — and indeed the heartbeat line `enabled: true, schedule: ...` is a real skill match but `channels:/jsonrender:/enabled: true` is not a skill yet will be counted. So on the parent repo's own aeon.yml today, ENABLED_COUNT will be inflated by at least 2 (jsonrender + telegram) beyond actual enabled skills (only `heartbeat` is enabled). With the POWER threshold at ≥5, this inflation directly affects bucketing. The misleading comment in Constraints makes this worse because it tells operators the count is trustworthy.
Recommendation
Either (a) scope the grep to the `skills:` block only — e.g. `awk '/^skills:/{f=1;next} /^[a-z]/{f=0} f' aeon.yml | grep -cE '^\s+[a-z][a-z0-9-]*:\s*\{[^}]*enabled:\s*true'`, or (b) parse with `yq` (`yq '.skills | to_entries | map(select(.value.enabled == true)) | length'`). Also correct the Constraints note — the current explanation about `#`-skipping is factually wrong and should be removed.