# Fluix Risk Check

**One-line purpose:** Catch work before it goes overdue, not just after — flag what's already late, what's about to be, and what's quietly gone stale even with no due date at all, using how long it's actually sat open. For every flagged item, diagnose the likely blocker, and when the person holding it is also carrying a heavier load than their peers, say so and suggest who has room. Merges what used to be two separate skills (Overdue Sweep and Load Check) into one, since "this is late" and "this person is overloaded" are often the same underlying problem, not two unrelated ones.

---

## When to trigger it

- "What's overdue right now" / "what's stuck and why"
- "What's about to be overdue" / "what's coming due soon"
- "Is anyone's queue building up" / "who's overloaded"
- "What should we redistribute before it becomes a problem"
- Any request about work that's late, at risk of becoming late, or piling up on one person — as opposed to a general urgency ranking that includes everything open regardless of lateness or workload (Priority Action List)

## Inputs

Required:
- **Data source(s) and tool family** — same discovery as the other Fluix skills (`tasks_list_reports` / `docs_list_datasets` / `docs_status_rows`). If no report is named, ask which one(s).
- **Due-soon window** — how far ahead counts as "about to be overdue." If the request states one, use it; if not, ask via quick-select (Today / Next 3 days / This week / Custom).

Optional, inferred from context or defaulted:
- **Scope** — defaults to team-wide, same as the other Fluix skills, treating the person asking as the one who needs the overview. Only narrows to a specific person when the request signals that.
- **Staleness comparison** — when no due-date field exists (or a record has none populated), "stuck" is judged by comparing the item's open duration and time-with-current-assignee against similar items in the same report, not a fixed day count. State the comparison used.

## Workflow steps

1. **Find the data source(s) and confirm tool family** — identical to the other Fluix skills.
2. **Get the schema first, always** — same field classification as the Dashboard skill. Specifically confirm: a due-date field (if any), a status/workflow-step field, an explicit blocker/dependency field (if any), an assignee/owner field, and whatever timestamp fields exist for computing age (created/started date, `Last Action`, `Duration`).
3. **Resolve the due-soon window** — via quick-select if not stated. Don't pull data until this is settled.
4. **Identify the use case** — same reasoning as the other Fluix skills, since what "stuck" looks like differs by process.
5. **Pull only open/incomplete records**, scoped per Inputs.
6. **Sort every open record into a risk tier:**
   - **Overdue** — due date has already passed (only possible when the source has a populated due-date field).
   - **Due soon** — due date falls within the resolved window.
   - **Stale, no due date** — the source has no due-date field, or this record has none populated. Compare its open duration and time-with-current-assignee against similar items in the same report; flag it when it's a real outlier (the same concentration/outlier logic the Dashboard skill uses elsewhere), not because it crosses an invented fixed threshold.
   - A record can only land in one tier — overdue takes priority over due-soon, which takes priority over stale.
7. **Diagnose the likely blocker for every flagged item**, the same way as before: an explicit blocker/dependency field if populated; otherwise infer from the current workflow step/status; otherwise say plainly that no blocker field exists and it's likely simple inactivity. Never state a blocker as fact when the data only supports a guess.
8. **Compute per-assignee queue depth and aging** across all open items (not just flagged ones) — count, average age, and whether it's trending up over the trailing 2-4 weeks, same as before. Compare assignees to each other, not to a fixed number; a real outlier is one whose depth or aging stands out relative to peers.
9. **Connect the two**: for every flagged item (any tier), check whether its assignee is also a workload outlier from step 8. When both are true, call it out explicitly as a compound signal — the item isn't just late or stale, it's late or stale *and* sitting with someone already carrying more than their share. Name a specific peer with real available room (from the same comparison) when the data supports naming one, rather than a generic "consider redistributing."
10. **Recommend a next step per flagged item**, tied to its tier and blocker: overdue with a clear blocker → the matching follow-up (signer, approver, or check-in for unexplained inactivity); due-soon → a heads-up before it tips into overdue; stale-no-due-date → a check-in framed around the unusual duration, not a missed deadline that doesn't formally exist. Add the redistribution suggestion from step 9 when it applies. Every recommendation is a suggestion for the person to act on — this skill never reassigns, escalates, or messages anyone itself.
11. **Rank and cap the list** at roughly 5-8 items, prioritizing overdue, then due-soon, then stale, noting "+N more" rather than listing everything.
12. **Aggregate**: count per risk tier, count per blocker category, and count of assignees flagged as workload outliers.
13. **Render as one widget**, same visual language as the other Fluix skills: a metric-card strip (overdue count, due-soon count, stale-no-due-date count, overloaded-assignee count), followed by a bar chart of the risk-tier breakdown and/or per-assignee queue depth — whichever the situation actually calls for. Below the widget, a ranked list in narrative or list form naming each flagged item, its tier, its diagnosed blocker, and the compound workload note when it applies.

## Output format

One widget — no separate text block. Findings render as cards inside it.

**The widget**, in this order:
1. A metric-card strip: overdue count, due-soon count, stale-no-due-date count, and overloaded-assignee count — or "n/a" with a footer note when the assignee field turns out to be role-based rather than individual, since a per-person comparison isn't meaningful then.
2. A bar chart — the risk-tier breakdown (overdue / due soon / stale) when all three are populated, or days-open per item when everything falls in one tier (which happens whenever a report has no due dates at all) — and, when it adds signal, a second chart of queue depth by assignee.
3. A styled card per flagged item, capped at 5-8, ranked overdue > due-soon > stale: bold item/project name, a colored badge showing its tier and duration (e.g. "49 days open"), an icon-led line naming the diagnosed blocker, and an icon-led line with the suggested next step. When several items share the exact same diagnosed blocker (e.g. all waiting on the same review step with nothing case-specific), combine them into one card instead of repeating the same line several times — name the group once and note the shared cause.
4. When a flagged item's assignee is also a workload outlier, add that as a line inside its card, not a separate section: carrying [N] items vs. a team average of [X], and who has more room, when the data supports naming someone.
5. A muted footer line: a by-blocker-type breakdown, sample size, whether the due-soon window or staleness comparison had to substitute for missing due dates, and a demo/sample-data flag if warranted.

## Guardrails

- Never state a diagnosed blocker as fact when the data only supports a guess — say plainly when the cause can't be determined.
- Never invent a fixed "stale after N days" threshold when no due date exists — compare against similar items in the same report and state the comparison.
- Every recommendation, including a redistribution suggestion, is a suggestion only — this skill never reassigns tasks, escalates, or messages anyone on the person's behalf.
- Only name a specific peer for redistribution when the data actually shows they have more room — never suggest a person by default or at random.
- Keep the compound "flagged and overloaded" call-out visually and textually distinct from a plain flagged item — don't blur ordinary lateness with workload-driven risk.
- Combining items into one shared-cause card is for a genuinely identical diagnosed blocker only — never combine items that merely look similar, and never combine across different risk tiers.
- A record lands in exactly one risk tier — overdue beats due-soon beats stale, never double-counted.
- Cap the ranked list; "+N more" is correct, listing everything is not.
- Same data-quality stance as the other Fluix skills — flag demo/sample data or too-small teams (where "average" isn't meaningful) rather than treating them as real signal.