Issue Triage & Batch Implementation Skill

Overview

Workflow that orchestrates issue discovery → categorization → implementation planning → batch execution → CI verification → PR/MR merge.

Single PR/MR policy: All issues implemented in one PR/MR unless user specifies otherwise.

Exception: When issues have clear dependency layers (e.g., models → API → frontend), stacked PRs via gh stack may be used instead. See stacked-prs skill. Only when explicitly requested and repository is on GitHub.

Platform Detection

Auto-detect from git remote:

REMOTE=$(git remote get-url origin)
if echo "$REMOTE" | grep -qi "github"; then
  PLATFORM="github"; CLI="gh"
elif echo "$REMOTE" | grep -qi "gitlab"; then
  PLATFORM="gitlab"; CLI="glab"
else
  echo "Unknown platform - set --platform github|gitlab"
fi

CLI Command Mapping

Arguments

Prerequisites

• gh CLI authenticated (gh auth status) — for GitHub
• glab CLI authenticated (glab auth status) — for GitLab
• Repository hosted on GitHub or GitLab
• CI enabled (GitHub Actions / GitLab CI) for verification

Workflow Phases

[Start]
   ↓
Phase 1: DETECT PLATFORM
   - Check git remote URL
   - Select gh or glab CLI
   ↓
Phase 2: DISCOVER
   - gh issue list / glab issue list
   - Read issue bodies, labels, acceptance criteria
   ↓
Phase 3: CATEGORIZE
   - Group by type: feature, bugfix, docs, ci, chore
   - Group by effort: trivial, small, medium, complex
   - Identify dependencies between issues
   - Flag already-implemented issues
   ↓
Phase 4: PLAN
   - Sort by dependency order (dependencies first)
   - Group compatible issues for single PR/MR
   - Estimate risk level per group
   - Create implementation checklist
   ↓
Phase 5: IMPLEMENT
   - Execute implementation groups in order
   - For each group: code → tests → docs
   - Track progress per issue
   ↓
Phase 6: VERIFY
   - Run quality gates
   - Push and create PR/MR
   - Monitor CI until green
   - Fix any failures
   ↓
Phase 7: REPORT
   - Summarize implemented issues
   - List any skipped/blocked issues
   - Report CI status

Categorization Rules

By Type

By Effort

Already-Implemented Detection

Skip issues where:

• Source code already exists with the described functionality
• Tests already cover the acceptance criteria
• README already documents the feature

Dependency Detection

Look for:

• Issue mentions another issue number (e.g., "depends on #123")
• Acceptance criteria references files created by another issue
• Feature requires infrastructure from another issue

Quality Gates

Integration with Other Skills

• atomic-commit: Used in Phase 6 for PR/MR creation
• self-fix-loop: Used in Phase 6 if CI fails
• task-decomposition: Used in Phase 4 for complex issues
• build-rust: Used in Phase 5 for compilation checks
• lint-rust: Used in Phase 5 for quality checks
• test-rust: Used in Phase 5 for test verification

Output Format

## Issue Triage Report

**Platform:** GitHub (gh) / GitLab (glab)

### Summary
- Total open: N
- To implement: M
- Already done: K
- Skipped (too complex): L

### Implementation Plan
| # | Issue | Type | Effort | Status |
|---|-------|------|--------|--------|
| 1 | #123 | feature | small | done |
| 2 | #124 | docs | trivial | done |

### Skipped Issues
- #125 (complex feature, needs design discussion)

### CI Status
- All checks: pass
- PR/MR: https://github.com/.../pull/XXX  or  https://gitlab.com/.../-/merge_requests/XXX

Example Usage

User: "read all open github issues and implement all missing"
Agent: Detects GitHub → uses gh → discover → categorize → plan → implement → verify → report

User: "implement all issues on gitlab"
Agent: Detects GitLab → uses glab → discover → categorize → plan → implement → verify → report

User: "implement issues #100-#110 in one MR"
Agent: Uses issue-triage with --limit 11 → filters to specific issues → batch implement

User: "triage open issues and tell me what's already done"
Agent: Uses issue-triage with --dry-run → discover → categorize → report (no implementation)

Rationalizations

Red Flags

• Implementing issues without reading their full acceptance criteria
• Creating separate PRs/MRs for each issue when user asked for batch
• Skipping dependency analysis between issues
• Not reporting which issues were already implemented
• Ignoring CI failures after implementation
• Using wrong CLI for the platform (gh on GitLab or vice versa)