Opus finding
Spotlight pick selection uses non-existent field `featured_at`, will always be empty
highbugmedium
- skills/fleet-state/SKILL.md:105-110
- skills/fleet-state/SKILL.md:47
Step 4 sorts by `.featured_at` and extracts `.fork` / `.featured_at` from each history entry, but the contributor-spotlight skill is the upstream producer and there is no guarantee these field names match what it writes. The doc itself never specifies the schema of contributor-spotlight-history.json (other than saying it has a `history` array). If the actual schema uses different keys (e.g. `featured_date`, `fork_full_name`, `date`), `sort_by(.featured_at)` will sort by null and `// empty` will silently set SPOTLIGHT_FORK and SPOTLIGHT_DATE to blank — yet step 8 fallback path (`If the article is missing but SPOTLIGHT_FORK is set...`) and the verdict/notify gates all rely on these. The skill will silently degrade to a section with empty fork name without flagging spotlight=unavailable. At minimum the schema contract needs to be stated and validated, otherwise this is a silent data-loss / wrong-content bug.
Recommendation
Either (a) document the exact schema of contributor-spotlight-history.json in this file and add a sibling assertion in contributor-spotlight/SKILL.md so the contract is enforced both ways, or (b) make field lookup tolerant: `jq -r '.history | sort_by(.featured_at // .featured_date // .date) | .[-1] | .fork // .fork_full_name // empty'`, and treat an empty SPOTLIGHT_FORK as `spotlight=unavailable` rather than rendering an empty section.