Working with an Advisory

Use the steps in this chapter as a standard path from an unclaimed Advisory to a closed one, including the Skylar Advisor features that help at each step and the checks that keep the record defensible. Keep this topic open beside your first few advisories. If you supervise a team of operators, see the related chapter, Supervising with Skylar Advisor.

Some steps in this chapter depend on preview features that are enabled per instance, so they might not appear in your environment:

Claiming and closing Advisories depend on the Claim and Close preview feature. For more information, see Claim and Close.
MCP Tools depend on the tools your administrator has enabled in the Toolbox, which requires you to enable the MCP Tools preview feature.
Web search requires that you enable the Web Search preview feature.
The Slack or Teams integrations depend on the Sharing Information with Slack and Microsoft Teams Integrations preview features.

Before You Work an Advisory

An Advisory or Prediction is an account of something that Skylar Advisor detected, written at the moment it fired. Keep in mind the following:

An Advisory describes the past. It is a snapshot of the moment it was raised, not a live view. The older it is, the less you should assume it still reflects current reality.
The thread is the record. Everything you do in the Advisory, including claiming, asking questions, running a tool, adding a comment, and closing, is written into the thread with your name and a timestamp. You do not keep a separate work log; the thread is the work log, and that is what the next person reads.

Reading the Answer Badge

Skylar Advisor labels where each answer came from. Check the badge before you act on anything.

Badge	What It Means for You
Verifiable	Built from facts found in your Corpus. Click the badge to see the source documents.
Verified (via Agents)	The Skylar Advisor AI agents queried your monitoring data directly to produce it. Trustworthy for numbers.
Web Cited	Read live from documentation sites your administrator approved. Click it to see exactly which pages were read, and when.
Tool Call	Produced by a tool rather than written prose. Treat the output as the tool's result.
Unverifiable	Do not act on this alone. It came from general model knowledge, not from your data or documents. Confirm it before you change anything.

If an answer is marked Unverifiable and you are about to act on it, stop and check it first, either with a tool, with the metrics, or by asking a more senior team member. Plausible and correct are not the same thing, and the badge tells you which one you have.

The Advisory Workflow at a Glance

Working an Advisory follows three phases:

Orienting yourself in the report and its events.
Doing the investigative work.
Closing the loop so the record is complete. For more information, see Working an Advisory Step by Step.

Orienting Yourself in the Events

An Advisory is exactly what the name says: advice. Skylar Advisor noticed something and is telling you about it. The events are what it noticed. Open them early, before you form a theory of your own. The events show you the scale, the duration, and the sequence in about thirty seconds, and everything you do afterward is better aimed because of it.

In the thread header of an Advisory, Prediction, or Investigation, an Events button opens the Events panel beside the conversation instead of over it, so you can read the report and the evidence together. This is the same Events tag described in What is an Advisory? What you get is the exact feed Skylar Advisor analyzed: not a fresh query, and not everything that happened, but the rows the Advisory was drawn from.

The Four Summary Tiles

Tile	What It Tells You, and What It Does
Time Span	How long the run of events covers, with the actual date range beneath it. A burst over four minutes and a grind over nine hours are different problems.
Devices	How many distinct devices are involved, your first read on blast radius. Click the tile to copy the device names as CSV.
Event Ids	How many distinct event types fired. One ID repeating is a different story from nine IDs interleaving. Click the tile to copy them as CSV.
Event Flow	Not a statistic, but a control. Click View graph to open the event flow diagram described below.

Reading the Event List

Below the tiles, you have the option to switch between the whole feed and the part that matters, when Skylar Advisor identified one:

All events. Every event Skylar Advisor analyzed. Rows that belong to the causal chain are numbered and lightly tinted, so you can find them while scrolling a long list.
Causal chain. Only the events the Advisory rests on, in order. On a noisy Advisory, this is the difference between eighteen rows and three.

The first step in the chain carries a ROOT CAUSE tag that marks that event is the key event for the Advisory. Skylar Advisor watches live traffic for that same event to raise the Advisory again, so it is often the event to fix if you want the Advisory to stop recurring.

Each row carries a severity band, the device, the event text, and its timestamp. The panel expands to full screen from its header when the side panel gets tight, and the header copies every device ID in the feed to your clipboard in one click, which is useful for pasting into a ticket or another tool.

Viewing the Event Flow Diagram

Click View graph to open the event flow diagram in full screen. The diagram draws the Advisory as three to four columns, left to right:

Events. What fired, ranked by severity, with repeat occurrences counted rather than repeated, and the causal chain's key events marked.
Devices. Which machines those events landed on, each tagged with its class and category and carrying its own event count.
Device Groups. Where relevant, lists the device groups for the impacted devices.
Business services. What those devices serve. Where service membership is not populated, the column falls back to device groups instead of sitting empty. Business services appear only when available.

A timeline runs across the diagram, positioning each event in time, so you see order as well as connection.

Connectors are colored by device rather than by severity: on the common case where every event shares one severity, coloring by severity would give you a single-hue picture with nothing to follow. Coloring by device lets you trace one machine's path from its events through to the services it affects.

The diagram includes a toggle at the top that contains the same all-events and causal-chain switch described above, so you can strip it back to the spine.

When you read the diagram from left to right, it tells you what happened, to what, and who is affected, in one view. That is the fastest way to know whether you are looking at one unhealthy device or the leading edge of something wider.

Working an Advisory From Claim to Close

To work an Advisory from claim to close:

Open the Advisory () and click Claim in the thread header. This stamps your name on it so nobody duplicates your work, and it starts the clock on your ownership. If the Advisory is already claimed by someone else, the header states this; check with that person before you start working it.
Read the contents of the Advisory end-to-end before doing anything else. Note the affected devices, the time window, and what Skylar Advisor says it observed. Then open the events behind the report, as described in Orienting Yourself in the Events. The report is what Skylar Advisor makes of the events; the events are what it saw.

If the Advisory includes charts or metric attachments, read them for shape rather than single values: is the line climbing, spiking, flat but high, or already back down? You are checking whether the shape matches the problem described.

Where a chart contains significant movement or a notable moment, Skylar Advisor attaches an AI analysis. Read it; it names what moved and when, which is usually faster than finding it yourself. You can filter the panel to show only charts with an AI analysis, or show every analysis at once. These charts are interactive, not static images, and the Metrics Snapshot pane also provides:

Full screen. Displays a common cursor across every chart, so one hover marks the same instant everywhere, which is how you see what moved first.
Metrics by category. Groups CPU, memory, disk, and network so they read as groups instead of one chart at a time.
Brush to zoom. Drag across a chart to set a time range. Use the arrow keys to move the window, and click Reset to return to the full range.
Snapshot walker. Steps between older and newer snapshots once the thread holds more than one.
Stitched timeline. Merges snapshots into one continuous view: a problem starting, peaking, and clearing in a single chart. Pairs with the closing snapshot you take before you close the Advisory.
Table view and CSV download. Provides the same data as a table you can export, for copying values into the Scratch Pad or sending them elsewhere.

For more information, see Metrics Enhanced Advisories.

Run the metrics_snapshot tool from the Tools menu on the Ask Skylar prompt box. This tool pulls current telemetry for the affected devices. This step is not optional if more than two hours have passed since the Advisory formed, because it is what stops wasted work. You are answering one question: is this still happening right now?
- Still happening. Continue to the next step.
- Recovered on its own. Do not close the Advisory yet. Note what you found, note that the problem self-recovered, and record what the metrics show now. A problem that resolved itself often returns.
- Worse than the Advisory described. Escalate before you continue, because the problem looks more severe than it did when the report was generated. Raise team awareness by adding colleagues to the conversation, or through the Slack or Teams integrations where they are enabled.
Click the Notes button to open the Scratch Pad and write out what you intend to check, in order. Even three lines is worth writing, because it stops you circling and becomes your work note later. Skylar Advisor also provides an action that drafts this task list for you from the live thread. For more information, see Using the Notes Feature.
Work your tasks using your normal tools plus whatever Skylar Advisor suggests. Write the outcome of each check in the Scratch Pad as you finish it, including the checks you ruled out. "Checked X, not the cause" is one of the most valuable lines you can leave behind.

As you work, you can use the following features to help your investigation:

Quick Take. Select any text in the thread and ask for a quick take on it. This is the fastest way to resolve an unfamiliar term, error code, or acronym without losing your place.
Quick Prompts. The suggested follow-up questions under an answer. They are generated from the current conversation, and they are usually the cheapest next step.
Tools. See Choosing the Right Tool for the Question.
Web search. If enabled, ask what vendor documentation says about a setting or error code. Answers cite the pages read and when they were read.
Colleagues. Add someone to the thread, or share it to Slack or Teams if those integrations are configured. They arrive with the full history instead of a summary you have to retype. For more information, see Sharing Information with Slack and Microsoft Teams Integrations.

When you find the root cause, insert your task list and work notes into the thread as a comment. Until you insert them, your Scratch Pad notes exist only on your machine. For more information, see the warning at the end of this section.
Use the Incident Resolution action in the Scratch Pad to draft a summary of what happened, what caused it, and what fixed it. Read the summary before you insert it, because it is drafted from the thread and can only be as accurate as what you wrote down. For more information, see Using the Notes Feature.
If metrics were involved, run metrics_snapshot tool once more so the thread ends with evidence that the system returned to normal. This is what turns "I fixed it" into something the next shift and any review can verify.
Generate a KB article from the thread, and read it before saving it. It is drafted from the conversation, so confirm that the root cause and the fix are stated correctly. This article is what makes the next occurrence faster, for you or for someone else. Which type of article you generate depends on your team's best practice. For more information, see Creating a Knowledge Base Article Based on an Activity.
Click Close in the thread header. If you close an Advisory too early, click Reopen; reopening is normal, and it is better than leaving an incorrect record.

The Scratch Pad auto-saves in your browser, not in the thread. If you close the tab, switch machines, or hand off mid-shift without inserting your notes as a comment, that work is not visible to anyone else. Insert your notes as you reach milestones, not only at the end.

Choosing the Right Tool for the Question

Tool availability depends on what your administrator has enabled. If a tool described here is missing from your Toolbox ( > Advisor > Toolbox) or the Ask Skylar prompt box, it has not been enabled for your instance.

When You Are Asking	Reach For	It Gives You
"Is this still happening now?"	metrics_snapshot	Current telemetry for the affected devices, as a chart you can attach.
"Has this happened before, and how was it fixed?"	precedent	Prior occurrences and how they were resolved, from history and the Corpus.
"What should I try first?"	triage	Several approaches compared, with a recommended next action.
"Is it just this device, or wider?"	correlate	The blast radius: what else is affected, and the likely common cause.
"Is this device generally unhealthy?"	device_health	The device's recurring issues, whether they are improving or worsening, and suggested fixes.
"What does this error code or setting mean?"	Web search, or Quick Take	Vendor documentation read live and cited, or a fast plain-language explanation.

Some tools are configured to require sign-off before they run. If a tool requires approval, an approval request appears in the thread instead of a result, and it waits for someone in the approver group. This is expected behavior; continue with other tasks and return to it later. You cannot approve your own request. For more information, see MCP Tools.

Escalating an Advisory

Escalate an Advisory when you have exhausted your task list, when the impact is growing, or when the fix needs a change you are not authorized to make. Escalating early is not a failure. Escalating without any findings wastes the next person's time.

Before you hand off an Advisory, confirm that the thread contains:

Your task list, with what you checked and what you ruled out. Other users cannot see your Scratch Pad, so insert your notes as a comment to leave a record of your work before you escalate.
A current metrics snapshot, so the next person sees the state now rather than the state at Advisory time.
The blast radius, if you established it, and who is affected.
Anything you changed, so nobody has to guess whether the system was touched.

Add the next person to the thread, or share it to Slack or Teams. Leave the Advisory claimed by you until that person picks it up, so it does not appear unowned.

Common Mistakes When Working an Advisory

Mistake	Why It Hurts
Working an Advisory without claiming it	Two people work the same problem, and neither knows.
Trusting an hours-old Advisory as current	You investigate a problem that already cleared, or miss that it got worse.
Acting on an Unverifiable answer without confirming it	The answer might be plausible and wrong. Confirm it against your data first.
Keeping notes only in the Scratch Pad	Nobody else can see them, and they do not survive a handover.
Recording only what worked	The next person repeats every check you already ruled out.
Closing without a recovery snapshot	Nothing in the record shows that the system actually returned to normal.
Saving a KB article without reading it	A wrong article is worse than none, because it will be trusted next time.

Keep the following four points in mind:

Claim an Advisory before you touch it.
Prove that a problem is still happening before you work it.
Record what you ruled out, not just what you found.
Document your notes in the thread, not just the Scratch Pad.

Checking Your Own Performance

Skylar Advisor keeps a profile of your own activity, one calendar month at a time. Reviewing it is worth five minutes at the end of a shift or a week.

To review your activity profile:

Click your avatar anywhere in a thread to open your profile page.
Use the stepper in the header to move one calendar month at a time. The stepper does not step into the future, so the current month is always the newest view, and it is still filling up.
- Time to Claim. The average gap between an Advisory being raised and you claiming it.
- Time to Close. The average time from your claim to your close.
- Ask Skylar. New questions you put to the Corpus, a measure of upskilling.
- Turns. Total questions asked while solving problems across threads.
- KB Generated and Shared. What you left behind for other people.
Read the tiles across the top of the page, which summarize the month: Below the tiles, an activity-over-time chart shows the shape of the month, and a Standing panel ranks you against the rest of your organization on claims, closes, KB generation, and shares, showing your position (for example, #N of M) and a bar comparing you to the top contributor.
- Activity summary. A factual account of what you worked on and your pace, and anything that stood out. This section deliberately contains no advice.
- Areas for improvement. Two or three focus areas, each naming the metric behind it and suggesting a next step.
Click the Coach button in the profile header to open two sections: Both sections are grounded in your actual numbers for the month, not general advice. If the month has very little activity, coaching is skipped rather than invented.

Coaching is currently an Owner-level control, so most operators see the trends and the standing but not the Coach button. The advice is still available to you; ask your team lead or platform owner to open it with you on your profile.

Keep the following in mind when you read your numbers:

Time to Claim is mostly about visibility. If it is climbing, the usual cause is that advisories are not surfacing where you are looking, not that you are working slowly. Raise this rather than absorbing it.
A long Time to Close is not automatically bad. Hard problems take time. It is worth attention when it is long and you generated no KB article, because that combination usually means what you learned did not get captured.
Standing is relative to your team, not an absolute. A middling rank in a strong team is not a failing. The panel shows you where to aim, not a score.

Do not work the metrics. Closing quickly, skipping the recovery snapshot, and skipping the KB article make these numbers look better and make the record worse. The numbers exist to help you spot your own patterns; the thread is what people actually rely on.