at-risk-detection

name	at-risk-detection
description	Use when asked about project health, stale or blocked issues, deadline risk, or scope creep - scans GitHub issues and PRs with heuristics (staleness, blocked labels, milestone dates, size, unassigned high-priority) and produces a severity-ranked at-risk report

At-Risk Detection Skill

Proactively scan GitHub issues and pull requests to identify at-risk items before they become problems.

When to Use

Activate when:

• Starting a new sprint or planning session
• During standup to identify blockers
• Weekly health checks of the project
• When asked about project health or status
• Before milestone deadlines
• When triaging backlog items

Analysis Approach

Prerequisite: Requires the gh CLI. Fetch data with, e.g.:

gh issue list --state open --limit 30 --json number,title,updatedAt,labels,assignees,milestone,comments
gh pr list --state open --json number,title,updatedAt,additions,deletions,isDraft,reviewRequests

Quick Mode (Default)

Fetch the 30 most recent open issues:

• Fast (seconds)
• Good for daily checks
• May miss older stale items

Comprehensive Mode

Fetch ALL open issues by paginating:

• Thorough analysis
• Slower for large repositories
• Best for milestone reviews

Risk Types and Detection Heuristics

Stale Items

Signal: No activity for extended period Default Threshold: 14 days for issues, 3 days for PRs awaiting review Severity Escalation:

• Warning: > threshold days since last activity
• Critical: > 2x threshold days since last activity

How to detect: Check updated_at field on each issue/PR. Calculate days since last update.

Blocked Work

Signals:

• Has labels matching: blocked, waiting, on-hold, waiting-for-response
• Body contains: "blocked by #", "waiting on", "depends on", "blocked until"
• PR is in draft status
• PR has merge conflicts (if detectable from comments)

How to detect: Check labels array for blocking keywords. Search body text for blocking phrases.

Deadline Risks

Signal: Milestone deadline approaching or overdue Severity Levels:

• Critical: Overdue or due within 2 days
• Warning: Due within 7 days

How to detect: Check if issue has a milestone with a due_on date. Compare to current date.

Scope Creep

Signals:

• Issues with high comment count (>30 comments)
• PRs with many lines changed (>500 warning, >1000 critical)

How to detect: Check comments count on issues. For PRs, check additions + deletions if available.

Assignment Issues

Signal: High-priority issue without assignee Priority Labels: priority:high, urgent, P1, P0, critical, blocker

How to detect: Check if assignee is null AND labels contain any priority keywords.

Output Formats

Project Health Summary

## Project Health: [Project Name]

### Summary
- **Total Open Items**: X (Y issues, Z PRs)
- **At-Risk Items**: N
- **Health Score**: X%

### Risk Breakdown
- Critical: X
- Warning: Y
- Info: Z

### Overloaded Assignees (if any)
- @username: N assigned issues

Health Score = 100 × (1 − atRiskCount / totalOpenItems), rounded to the nearest integer.

At-Risk Item Report

## At-Risk: #[number] - [title]

**Severity**: [Critical | Warning | Info]
**Type**: [Issue | PR]
**URL**: [link]
**Assignee**: @username

### Risk Signals
- [signal type]: [description]

### Suggestions
- [actionable recommendation]

Generating Suggestions

For each risk signal detected, provide actionable suggestions:

Risk Type	Suggestion
Stale issue	"Comment with status update or close if no longer relevant"
Stale PR	"Request review or close if superseded"
Blocked	"Resolve blocking dependency or re-prioritize"
Deadline approaching	"Break into smaller milestones or adjust deadline"
Scope creep	"Split into smaller issues or create a tracking epic"
Unassigned high-priority	"Assign an owner immediately"
Overloaded assignee	"Redistribute work or adjust priorities"

Overloaded Assignee Detection

Track issue counts per assignee:

• Warning: > 7 assigned issues
• Critical: > 10 assigned issues

Configuration Defaults

Setting	Default	Description
staleDays	14	Days before issue is stale
prStaleReviewDays	3	Days before PR awaiting review is stale
deadlineWarningDays	7	Days before deadline to warn
maxCommentsBeforeScopeWarning	30	Comment threshold for scope creep
maxAssignedIssuesPerPerson	10	Max issues before overload warning

Example Workflows

Morning Health Check

1. Fetch recent open issues
2. Apply all heuristics to each issue
3. Present health summary with risk breakdown
4. Highlight any critical items requiring immediate attention

Individual Issue Assessment

1. Fetch the specific issue with all comments
2. Apply all heuristic checks
3. Present detailed risk analysis with signals and suggestions

Pre-Sprint Cleanup

1. Fetch ALL open issues (comprehensive mode)
2. Apply all heuristics
3. Sort by severity (critical first)
4. Present full at-risk report
5. Suggest actions for each at-risk item

Common Mistakes

• Flagging draft PRs as stale-awaiting-review - a draft is not awaiting review; treat it as in-progress or blocked, not a stale review.
• Trusting Quick Mode for staleness - it fetches the 30 most recent items sorted by recency, so it misses exactly the stalest items. Note this limitation in the report; use Comprehensive Mode to find them.
• Conflating parked and forgotten work - items labeled on-hold are intentionally parked; report them separately from genuinely forgotten stale items.