# Fluix Priority Action List

**One-line purpose:** Turn open items across a Fluix report (or reports) into a ranked "what to actually do today/this week" list — the small number of things that genuinely need attention now, each with a stated reason and a next action. Not a dashboard (exploratory) and not a digest (periodic summary) — this is forward-looking and action-oriented: where should I focus, right now.

---

## When to trigger it

- "What needs my immediate attention?" / "What's most urgent right now?"
- "What should I focus on today/this week?"
- "Give me my priority list" / "What should I do first?"
- "What's overdue or stuck that I need to deal with?"
- Any request asking what to act on next, as opposed to what happened (Digest) or what the data looks like overall (Dashboard)

## Inputs

Required:
- **Data source(s) and tool family** — same discovery as the other two Fluix skills (`tasks_list_reports` / `docs_list_datasets` / `docs_status_rows`). If no report is named at all, ask which report(s) to scan rather than silently scanning every report in the account — that's expensive and likely to pull in irrelevant items.
- **Timeframe** — Today or This week (simpler than the Digest skill's four options, since this is about upcoming action, not a historical window). Ask via quick-select if not stated.

Optional, inferred from context or defaulted:
- **Scope: default is team-wide, treating the person as the owner/manager/lead who needs the overview.** Unless the prompt explicitly narrows it — a name, "my," "assigned to me," or similar — assume the person asking is the one who needs to see everything and act on it, not just their own slice. Don't ask a clarifying "whose work?" question by default; only filter to a specific person when the request actually signals that, and only ask for their name/identity if it says "my/mine" but no identifying field or context establishes who that is.

## Workflow steps

1. **Find the data source(s) and confirm tool family** — identical to the other Fluix skills.
2. **Get the timeframe** — resolve via quick-select/direct question before pulling data. Scope defaults to team-wide (see Inputs) without asking, unless the request explicitly signals a narrower, personal scope.
3. **Get the schema first, always** — same classification as the Dashboard skill. Specifically look for: a severity/priority field, a due-date field, a status field, an "assignee/owner" field, and any explicit urgency signal (e.g. "urgent repair," "not approved for use," "safety incident," "high severity").
4. **Identify the use case** — same reasoning as the other Fluix skills (asset inspection, work order, incident report, etc.), since what "urgent" means differs by type: an inspection's urgency is driven by condition/severity fields; a work order's is driven by blockers and due dates; a document workflow's is driven by status age.
5. **Pull only open/incomplete records** — exclude anything already finished/closed/approved; those need no action. Filter to the requested scope (whose work) if applicable.
6. **Score each open item on transparent, stated signals** — no hidden numeric formula. An item is flagged as immediate-attention if one or more of these hold, and the item's listed reason names exactly which one(s):
   - An explicit high-urgency value is present (severity = High/Critical, action = Urgent Repair, "not approved for use," a logged safety incident).
   - It's overdue against a due date, or has been sitting in the same open status far longer than similar items (aging outlier, same concentration logic as the Dashboard skill).
   - It falls within the selected timeframe (due today, or due this week).
   - It's blocking something else (an explicit blocker/dependency field is filled).
   - **Severity/action mismatch** — a condition, severity, or checklist-failure field indicates something serious (e.g. Poor condition, majority of checklist items failed) but the logged required-action/disposition field is mild (e.g. "Monitor" instead of "Repair"). Flag this explicitly as a mismatch worth a second look, not just as a severity item — the discrepancy itself is the signal.
   Items with none of these signals go in a lower "worth monitoring" tier, or are omitted if the list would otherwise be too long.
   - **If no due-date field exists or is populated anywhere in the source**, say so once in the output rather than silently ranking by fabricated urgency — fall back to severity and time-in-status (aging) as the ranking basis, and note in the Data confidence line that "today vs. this week" reflects status-age rather than actual deadlines.
7. **Cap the immediate-attention list** at roughly 5-8 items even if more technically qualify — rank by the strongest signal first (explicit severity/safety > overdue/blocking > falls-in-timeframe), and note "+N more items also flagged" rather than listing everything.
8. **Render as a plain ranked list** (response text, no widget) — see Output format. A small metric-card strip (same visual spec as the Digest skill) MAY precede it to show top-line counts (e.g. "3 overdue," "1 safety flag," "2 due this week"), but the list itself is the deliverable, not the cards.

## Output format

```
Priority actions — [today / this week], [report/scope name]

Immediate attention:
1. [item/record] — [why: the specific signal(s) from step 6] — [suggested next action]
2. ...
(up to ~5-8; if more qualify: "+N more items also flagged — ask to see the full list")

Worth monitoring (not urgent, but keep an eye on it):
- [item] — [why]
(or: "Nothing else worth flagging this period.")

If nothing qualifies as immediate: "Nothing requires immediate attention for [timeframe] — the most pressing open item is [X], but it doesn't meet the urgency bar."
```

Each numbered item states its reason using the actual field/value that triggered it (e.g. "severity: High, unresolved 12 days" or "due today, blocking the review step") — never a vague "this seems important."

## Guardrails

- Never invent an urgency score — every ranked item must cite the specific field/value or aging fact that earned its place on the list. If nothing concrete supports flagging an item, it doesn't go on the list.
- Don't silently scan every report in the account when no report is named — ask which report(s) before pulling data broadly.
- Default to team-wide scope, treating the person asking as the owner/manager/lead who needs the overview — don't ask "whose work?" unless the request itself narrows to a specific person and that person's identity isn't otherwise clear.
- A severity/action mismatch (serious condition or widespread checklist failure paired with a mild logged action) is a valid, distinct reason to flag an item — don't fold it silently into a plain severity flag; call out the mismatch itself.
- Cap the immediate-attention list; don't let it become a full report dump. "+N more flagged" is correct; listing all 20 is not.
- This skill only surfaces and ranks — it never sends messages, reassigns tasks, or updates records on the person's behalf. Suggested actions are for the person to carry out (or ask Claude to draft a message for, as a separate step with normal confirmation).
- Keep the same data-quality stance as the other Fluix skills — flag demo/sample data or missing fields rather than treating them as real signal, and say so if a report has too few open items to produce a meaningful list.
- If the metric-card strip is used, follow the same visual spec as the Digest skill (label / number / delta or plain count) — don't introduce a third card style.