Grooming Sprint Tasks

Overview

Sprint grooming means every task gets: subitems, a detailed description, linked GitHub issues, proper labels, SP estimate, and priority. This skill automates the cross-referencing of Monday.com tasks with GitHub issues across multiple repos, identifies gaps, and produces fully groomed tasks.

Process

Phase 1: Gather All Data

Collect from three sources in parallel:

Monday.com board:

1. get_board_info — learn column IDs, status labels, groups, epics
2. GraphQL query for items by sprint group:

   query { boards(ids: [BOARD_ID]) { groups { id title items_page(limit: 100) { items { id name } } } } }

1. get_board_items_page with includeColumns: true, includeSubItems: true — get full details

GitHub issues (ALL repos, in parallel):

gh issue list --repo ORG/REPO --state open --limit 100 --json number,title,state,labels,body,url

Check every repo the team works in — not just the obvious one.

GitHub labels (ALL repos, in parallel):

gh label list --repo ORG/REPO --json name,description,color --limit 50

Know what labels exist before assigning them. Create new labels if the repo is missing useful ones.

Phase 2: Cross-Reference Tasks ↔ Issues

For each sprint task:

1. Identify repos — Which repo(s) does this task touch? A task can span multiple repos.
2. Find matching issues — Search by keywords in issue titles across all repos
3. Classify the result:

Phase 3: Produce Groomed Output Per Task

Every task (except DoD/ceremony tasks) needs ALL of these:

#### A. Subitems

RULE: 3-5 subitems per task, each independently completable

• Break the task into concrete work items
• Set "Days to Complete" for each subitem — sum should ≈ Est SP
• Reference issue numbers in names when applicable: "Table rendering in chat UI (client #1802)"
• Names should be descriptive enough to understand without the parent context

Create via Monday API:

create_item with parentItemId → creates subitem
columnValues: {"numbers": "0.5"} → sets Days to Complete

#### B. Task Description (Monday update/comment)

Every task gets an update in this format:

📋 Sprint Grooming Notes

[2-3 sentences: what this task is and why it matters]

🔗 Repo: org/repo-name
🎫 Issues:
• repo #NUM (title) — URL
• repo #NUM (title) — URL
📎 Related: repo #NUM (brief note on relationship)

[Dependencies or blockers if any]

Acceptance criteria:
• [Concrete, testable criterion]
• [Concrete, testable criterion]
• [Concrete, testable criterion]

Multi-repo tasks list all repos and issues.

#### C. GitHub Issues (for gaps)

New issues must be fully groomed — not just a title:

## Context
[What this is and how it fits into the system]

## Motivation
[Why this matters — user impact, business value, what breaks without it]

## Scope
- [ ] Checkbox for each piece of work

## Technical Notes (if applicable)
[Schema, API contracts, data shape, file paths]

## Dependencies (if any)
[What must exist first]

## Acceptance Criteria
[How we know it's done]

Labels: Assign MULTIPLE relevant labels — not just enhancement. Use domain-specific labels (agent, evals, tools, resources, security, observability, etc.). Create labels if the repo is missing useful ones:

gh label create "label-name" --repo ORG/REPO --color "HEX" --description "Description"

Phase 4: Validate

After grooming, verify:

Phase 5: Present Summary

After all grooming, present to the user:

1. Task list — table with: task name, SP, priority, repos, issue count
2. SP breakdown — committed SP vs buffer SP vs capacity
3. Issues created — table with: repo, issue #, title, labels
4. Issues closed — any superseded issues
5. Labels created — new labels added to repos
6. Remaining gaps — anything still missing

Red Flags — STOP

Anti-Patterns

Single-repo tunnel vision: Checking only one repo when a task spans agent + MCP + client. Always check all repos.

Label laziness: Slapping enhancement on everything. Use agent, evals, tools, resources, security, observability, performance, etc.

Skeleton issues: Creating issues with just a title and no body. Every issue needs Context, Motivation, Scope, and Acceptance Criteria.

Missing cross-links: Creating issues but not linking them back to the Monday task description. The Monday update must reference every related issue with URLs.

Subitem vagueness: "Do the thing" subitems with no days estimate. Each subitem needs a clear name and days-to-complete.

Ignoring superseded issues: Old issues that are replaced by new work should be closed with a comment, not left open to confuse future sprints.