agent-sandbox: Skill for Claude Code

Triage agent-sandbox issues against the roadmap

Map every open issue in kubernetes-sigs/agent-sandbox to a roadmap theme/item, assign a triage priority, and sync that priority to both the issue's k8s priority/* label and the Priority field (P0–P4) on the Kanban board.

Label ↔ Priority mapping (fixed)

k8s label	Kanban Priority
priority/critical-urgent	P0
priority/important-soon	P1
priority/important-longterm	P2
priority/backlog	P3
priority/awaiting-more-evidence	P4

Key references

• Roadmap: roadmap.md in the repo root (source of truth for themes + status).
• Project board: https://github.com/orgs/kubernetes-sigs/projects/120 (owner kubernetes-sigs, number 120).
• The board's Priority single-select field holds P0–P4.

Triage heuristics

Assign each open issue a tier using, in order:

1. Honor existing priority/* labels — do not downgrade/overwrite an existing priority label unless the issue clearly changed; note any you keep.
2. Roadmap references — if the issue number is cited in roadmap.md, inherit that item's status: ⏳ In Progress → P1, 📅 Planned → P2, ✅ Completed follow-ups → P2/P3.
3. Bug severity — data-integrity / duplicate-resource / resource-leak bugs in the core controller → P0/P1. Self-labeled "Critical" → P0.
4. Value props — latency / performance / scale bottlenecks skew P1 (called out as a primary value proposition).
5. Security — critical security vulnerabilities / CVEs → P0 (priority/critical-urgent); routine dependency/patch updates → P1 (tied to "Security Fixes" roadmap item).
6. Low-signal — empty bodies, one-line questions, "collecting use cases", pinned/frozen community threads, items marked triage/not-reproducible/triage/needs-information → P4. Nice-to-have features, refactors, cleanups, test scaffolding → P3.

Procedure

1. Verify access: gh auth status; confirm repo kubernetes-sigs/agent-sandbox.
2. Read the roadmap: read roadmap.md; extract themes, item statuses, and any cited issue numbers.
3. Fetch open issues: gh issue list --repo kubernetes-sigs/agent-sandbox --state open --limit 500 --json number,title,labels,assignees,createdAt,updatedAt,body,url > open_issues.json
4. Discover board metadata (IDs change per board, always re-fetch):
   • Project + Priority field/options: gh project field-list 120 --owner kubernetes-sigs --format json → grab the Priority field id and the P0–P4 option ids; project id via gh project view 120 --owner kubernetes-sigs --format json.
   • Item ids: gh project item-list 120 --owner kubernetes-sigs --limit 1000 --query "is:open" --format json → map issue number → project item id. Add any open issue not yet on the board with gh project item-add 120 --owner kubernetes-sigs --url <issue-url> --format json.
5. Triage: assign every open issue exactly one tier using the heuristics. Sanity-check that the assigned set equals the open-issue set (no missing, no extras).
6. Report first: write a markdown report (issue-triage-report.md) grouping issues by priority with roadmap mapping + one-line rationale, and a "second look" section for judgment calls (e.g., heuristic conflicts, boundary cases, insufficient info, or ambiguous roadmap items). In an interactive run, stop and wait for the user to review before changing anything on GitHub. In an automated/scheduled run, see below.
7. Apply (after approval in interactive mode, or filtered by untriaged issues in scheduled mode):
   • Label: gh issue edit <#> --repo kubernetes-sigs/agent-sandbox --add-label "<priority/...>" --remove-label "<priority/...>" (if the tier changed).
   • Board field: gh project item-edit --id <itemId> --project-id <projectId> --field-id <fieldId> --single-select-option-id <optionId>.
   • Drive the apply loop from a small script so all issues are processed in one pass (adding a sleep 1 delay between API calls to respect GitHub's 900 points/min secondary rate limit); collect per-issue ok/err and print a final total / errors summary.
8. Confirm: report the final distribution (count per tier) and any errors.