// Use for GitHub issue triage and local investigation, including gh issue workflows, picking a fresh issue, reproducing issue reports, and planning regression coverage.
| name | github-issue-investigation |
| description | Use for GitHub issue triage and local investigation, including gh issue workflows, picking a fresh issue, reproducing issue reports, and planning regression coverage. |
Use this skill when investigating GitHub issues locally, especially bug reports that may need reproduction and durable regression coverage before any fix is attempted.
gh issue list and gh issue view are allowed for investigation.Inspect that specific issue with gh issue view. Summarise:
Avoid changing GitHub state while doing this. If the issue is clearly a duplicate, support question, feature request, or waiting for reporter information, report that and explain whether local investigation is still worthwhile.
Use gh issue list to build a shortlist rather than choosing silently. Present about 3-5 candidate issues with:
Do not require or prefer positive labels. Actively avoid issues labelled exactly awaiting testing or effectively equivalent, because those are usually awaiting reporter or user verification rather than fresh local investigation.
Prefer issues with observable broken behaviour and enough detail to reproduce. Avoid issues that are obvious duplicates, support questions, feature requests, waiting on reporter information, already assigned or visibly in progress, dependent on unavailable external services, private servers, client-only behaviour, or anything requiring GitHub-side mutation before local investigation can proceed.
integration-test-verification for integration-test matrix selection, runs, Kotest registration, compact result triage, and failure investigation.build/integration-test-logs/*.log files directly; use compact summaries first and delegate log inspection only when needed.Keep this skill investigation-focused. If the user later requests a fix:
TDD for repro-test-first work;Planner when the fix needs planned multi-step work or broader design decisions;BuildReview for small standalone quick changes.Do not start a fix, comment on GitHub, or create persistent planning artefacts merely because an issue looks actionable.
Use when rewriting CHANGELOG.md, GitHub release notes, or Release Please PR changelog sections into user-facing release notes; do not use for release publishing, assets, licence, or workflow readiness checks.
Supports preparing commits, pre-commit hooks, Spotless, formatting or linting, validation before commit, staging files, and writing conventional commits.
Use for Dependabot PRs, dependency bumps, Gradle or Maven dependency updates, GitHub Actions updates, dependency changelog/licence/release-note review, JVM/classfile checks, and validation recommendations.
Use when running, selecting, authoring, or triaging integration tests, Kotest specs, Gradle matrix tasks, FakePlayer-backed test cases, or compact test-result files; do not use for unrelated production-only edits, release publishing, or general PR prose.
Use for Java 8 backports, Bukkit/Paper version differences, NMS/reflection, PacketEvents compatibility, fake-player implementation choices, and feature-detection design; do not use for release publishing, PR wording, or simple test-running decisions.
Use for config.yml, module enablement, modesets, config migration, configurable module assignment, and per-module option changes; do not use for unrelated integration-test triage, release publishing, or PR summaries.