AntFleet

Disagreement · c0feb3ca-anthropic-1

gh api contents .content jq extraction will fail to base64-decode without `-r`

mismatch
repo 6f7fc663·PR #30·reviewed 1 week ago

Primary finding

gh api contents .content jq extraction will fail to base64-decode without `-r`

mediumbughigh
  • skills/skill-update-check/SKILL.md:53-58
`--jq '.content'` outputs the JSON-encoded string with surrounding quotes (since jq is not given `-r` and gh's `--jq` mirrors jq behavior). Piping a quoted string into `base64 -d` will fail with `invalid input` because the leading `"` is not valid base64. Additionally, GitHub's contents API returns base64 with embedded newlines that base64 handles, but the quotes are the blocker. Also, `-f ref=` sends ref as a body param; for GET it becomes a query param, which is correct, but the quote issue still breaks decoding.

Recommendation

Use `--jq -r '.content'` is not valid syntax; instead use `| jq -r '.content'` or `gh api ... -q '.content'` is also quoted. Correct form: `gh api ... --jq '.content' | tr -d '"\n' | base64 -d` or use `gh api ... | jq -r '.content' | base64 -d`.

Counterpart finding

“OK” log message is misleading when all results are UNREACHABLE

lowdocs-gaphigh
  • skills/skill-update-check/SKILL.md:63-66
  • skills/skill-update-check/SKILL.md:122
UNREACHABLE entries are explicitly not current, yet the prescribed message states “N skills current.” In cases where zero are current and some are unreachable, this is inaccurate and could mask connectivity problems.

Recommendation

Adjust the log to reflect the true state, e.g., “No changes detected — Up-to-date: X, Unreachable: Y,” and reserve “OK: N skills current” for the case where Y=0.

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 →