Problem
Board #28 now holds 533 items (counted 2026-09-22), but the card lookups in .claude/skills/board-ops/SKILL.md run gh project item-list 28 … --limit 500. Past the limit, item-list truncates silently: no error and no warning, just the first 500 items. Any card beyond that point is invisible, so the recipes return false negatives rather than failing:
Recipe (board-ops/SKILL.md) |
Limit |
What goes wrong |
| GHSA advisory draft lookup (~L44, added in #2444) |
500 |
Reports no draft card titled [GHSA-…] on #28 for a card that exists |
| Move an existing card (~L160) |
500 |
ITEM_ID comes back empty, then item-edit --id "" fails with an opaque node-resolution error |
| Delete a card (~L175) |
500 |
Same as above |
| Snapshot before touching options (~L245) |
600 |
Headroom of 67 items; a snapshot that silently drops cards cannot restore them |
Recovery board-broken.json dump (~L267) |
600 |
Same as above |
issue-triage/SKILL.md uses --limit 700 (L56, L222), which covers today's board with ~170 items to spare. It will fail the same way once the board grows past that.
The skill already warns that --limit must stay above the board's item count, but that warning relies on someone remembering to check. The "~265 as of 2026-08-01" figure it quotes has doubled in under two months.
How it bit
Twice in one session (2026-09-22), both times leading to a confidently wrong statement:
Expected
A lookup either finds the card or fails loudly. It should never return an empty result because the board grew.
Suggested direction
- Issue cards: look them up from the issue side, which does not depend on board size:
gh api graphql -f query='{repository(owner:"modelcontextprotocol",name:"inspector"){issue(number:<N>){projectItems(first:10){nodes{id project{number}}}}}}' \
--jq '.data.repository.issue.projectItems.nodes[] | select(.project.number==28) | .id'
- Draft cards and whole-board dumps (GHSA lookup, snapshot, recovery, the triage audit) do need the full listing. Give them a limit with real headroom, and assert
.items | length is below it, so a truncated listing fails instead of passing as complete.
- Remove the stale "~265 items" figure, or replace it with the assertion so no manual check is needed.
🤖 Generated with Claude Code
Problem
Board #28 now holds 533 items (counted 2026-09-22), but the card lookups in
.claude/skills/board-ops/SKILL.mdrungh project item-list 28 … --limit 500. Past the limit,item-listtruncates silently: no error and no warning, just the first 500 items. Any card beyond that point is invisible, so the recipes return false negatives rather than failing:board-ops/SKILL.md)no draft card titled [GHSA-…] on #28for a card that existsITEM_IDcomes back empty, thenitem-edit --id ""fails with an opaque node-resolution errorboard-broken.jsondump (~L267)issue-triage/SKILL.mduses--limit 700(L56, L222), which covers today's board with ~170 items to spare. It will fail the same way once the board grows past that.The skill already warns that
--limitmust stay above the board's item count, but that warning relies on someone remembering to check. The "~265 as of 2026-08-01" figure it quotes has doubled in under two months.How it bit
Twice in one session (2026-09-22), both times leading to a confidently wrong statement:
Done.Incoming.Expected
A lookup either finds the card or fails loudly. It should never return an empty result because the board grew.
Suggested direction
.items | lengthis below it, so a truncated listing fails instead of passing as complete.🤖 Generated with Claude Code