Primary finding
`date -d "${today} - 30 days"` fails on BSD/macOS, breaking the macOS fallback path
mediumbughigh
- skills/contributor-spotlight/SKILL.md:136-138
The BSD fallback uses `-f %Y-%m-%dT%H:%M:%SZ` as the input format but passes `${today}T00:00:00Z` (e.g. `2025-01-15T00:00:00Z`). That parses the *current* date string, not 30 days ago, and the `-v-30d` adjustment is supposed to subtract 30 days from that parsed time. On BSD `date -j -v-30d -f <fmt> <input> <outfmt>`, the option order matters: `-v` adjustments are applied to the parsed time, so this technically works — BUT only if `${today}` is a full ISO timestamp. The skill defines `${today}` as the date (e.g. `2025-01-15`), and concatenates `T00:00:00Z`. That part is OK. However, on GNU `date` the first branch produces output like `2024-12-16T00:00:00Z` (midnight UTC), but if `${today}` itself contains spaces or timezone information injected from a different runtime, the GNU parser silently accepts non-ISO strings while BSD does not — leading to inconsistent SINCE values between runners. More importantly, if BOTH branches fail (e.g. on Alpine/busybox `date`, which is common in minimal containers and supports neither `-d` nor `-j`), SINCE becomes empty and the subsequent `gh api "repos/...?since=&per_page=100"` returns *all* commits (busybox `date` lacks `-d` parsing for relative strings). The article would then report a wildly inflated `COMMITS_30D` count. There is no validation that SINCE was actually computed.
Recommendation
After computing SINCE, validate it matches `^[0-9]{4}-[0-9]{2}-[0-9]{2}T` and fall back to omitting the `since=` parameter only if you can also bound results another way (e.g. iterate commits and break on date). Or compute SINCE in a small inline Python/node snippet that is portable. Also remove `2>/dev/null` so failures are visible.