Selection And Handoff

Read-only prevalidation

For “safe to delete”, “validate before removal”, or “is this recommendation still valid”:

1. Reuse resolved scope/tenant and the exact recommendation type and affected resources already selected by the user. If the type is unknown, use existing Cost/IdleResources summary or metadata resolution, visibly show the returned types, and ask for one type. Never invent a type GUID or ask for an ID that Advisor results can supply.
2. Call advisor_recommendation_prevalidate for that type. Explicit resources selections accept exact full affected-resource ARM IDs only. Reuse IDs already returned; if only names are known, resolve them through existing list and ask about ambiguous matches before prevalidating. Do not silently include unselected rows or change scope. Do not list the type again when the required IDs are already known. Omit resources for type-wide validation; the tool follows discovery pages and processes bounded batches, not only the first 25. This tool enforces Cost/IdleResources/New internally; do not pass category or status inputs.
3. Use the tool’s verdicts without reclassification. Render three sections, even if empty: Resources that passed automated checks, Resources requiring additional review, and Resources blocked for deletion, mapped to safe, needsReview, and blocked. Explain that passing automated checks still leaves manual checks outstanding and does not authorize deletion. Use the prevalidation layout: compact bucket tables, one shared checks-performed table, and outstanding manual confirmations. Keep per-resource failures and unverified checks visible; show detailed evidence only when explicitly requested. Do not repeat the same checklist/manual guidance for every resource.
4. Show bucket counts and returned Safe/NeedsReview known savings as Retail USD; omit the Blocked aggregate savings line. Preserve unavailable amounts and missing-value counts. Preserve an explicitly requested top/subset. Disclose truncation and unmatched selections; never call a capped subset the entire scope. With incomplete discovery, unmatched means not found in the returned portion, not confirmed absent. Show returned checkedResourceCount and remainingResourceCount; an unavailable remaining count is unknown, not zero. Recent activity, unknown signals, or insufficient history are investigation requirements, not proof of inactivity. Do not infer metrics, ownership, or dependency coverage.
5. In the blocked section, separately identify resources with a returned resourceDeletedOn as confirmed already deleted, with their dates and the returned deletedCount. Show their returned reason and honor canPostponeDismiss=false: no postpone, dismiss, manual completion, or remediation handoff. Explain that no action is needed and Advisor will remove the recommendation automatically within 72 hours once it refreshes. Keep executed-check evidence visible, but do not ask for attachment/ASR investigation, backups, export, or other before-deletion steps for an already-deleted resource; manual guidance is not an outstanding task for it. The tool confirms deletion from a Delete event in the last 14 days of ARG change history, only after a failed scope/detection check. Without resourceDeletedOn, that failure or an unverified deletion probe means stale/unconfirmed detection, not confirmed deletion. A savings timestamp, missing resource, or absent change record alone is not proof of deletion. Preserve the tool’s returned buckets; keep active blockers and their required investigation distinct.
6. Never execute advisory CLI/PowerShell guidance, delete, change state, or generate remediation automatically from these results. A separate remediation request uses the explicit selection/confirmation handoff below. Read failures or unsupported resource-type/ID pairs never become a safe verdict; dependency scans cover only visible control-plane evidence.

Inspect the connected tool contract. If prevalidation is unavailable, report the limitation; do not substitute ad hoc ARM, CLI, or KQL checks.

Resource selection

Artifact requests and lifecycle actions use direct list with category=Cost, sub-category=IdleResources, and the resolved scope. Active remediation and postpone/dismiss selection use status=New. For completion, preserve a supplied source state, otherwise use New. For reactivation, preserve the explicitly supplied or previously selected source state (Postponed, Dismissed, or Completed); if unknown, ask which source state to select instead of listing New. The read filter is the source state, not the intended update state. Do not require an opening summary unless the user separately requested grouped discovery.

1. Reuse an exact type/resource already explicitly selected by the user. Otherwise render returned recommendation types and counts, then ask for one type using returned display names. Never infer a stable type GUID from its label.
2. List that type and visibly render its resources before asking for selection. Keep stable recommendation IDs internally except the separately labeled lifecycle selection identifiers required by State updates; provide full affected-resource IDs when needed to distinguish resources or confirm actions.
3. Ask for selected resources or All resources in this recommendation type only when the target set is missing. A single row is not implicitly selected. Reuse an explicit prior selection. “Those requiring more work” after one prevalidation result selects its needsReview resources only, not passing or confirmed-deleted resources; reuse their returned stable recommendation IDs without another list/selection question. Ask if the referenced result or bucket is ambiguous, or the exact update IDs are missing.
4. An all-resources choice is limited to that type, source state and scope. Follow its list continuation to enumerate that requested set, visibly show the resulting resources, then obtain the required action confirmation. Never add later pages to a prior selection of specific/shown resources. If retrieval remains incomplete, disclose the partial target set and obtain explicit acceptance of only those resources; never call them every match.

For “this”, “it”, or “this one” after several rows, ask which exact resource. Never choose the first, highest-savings, or most recently mentioned row. Ordinary read-only expansion does not require resource-selection prompts. Resolve recommendation types and resources from the user’s wording and returned Advisor records. After scope resolution, do not ask the user to supply type GUIDs or resource IDs that can be obtained from those records.

Remediation artifacts

Distinguish “what could I save if I deleted it?” (read-only estimate) from “create a script to delete it” (artifact handoff). Keep explicit selection for singular estimates after ambiguous multi-resource results, but do not turn an estimate into permission to remediate.

After selection, ask only for missing artifact format: instructions, parameterized template, populated script, or resource list; CLI, PowerShell, or IaC when relevant. Ask one question at a time and no more than two format clarifications.

Load azure-advisor-actionability with the original request, exact recommendation type GUID, complete affected resource IDs, confirmed scope/tenant, requested format, and returned Advisor evidence and savings. Preserve access/truncation limitations and unresolved placeholders. Do not hand off confirmed-deleted, unselected, Completed, Postponed, or Dismissed rows as active deletion candidates. A separate lifecycle-specific request must be handled explicitly.

The existing actionability skill retrieves advisor_remediation_get using only recommendationTypeId, substitutes confirmed resource context, and labels Advisor guidance versus a public Microsoft Learn fallback. Do not generate duplicate remediation here or bypass its confirmation safeguards. Guidance is not evidence of execution or validated deletion safety.

Lifecycle-state changes use the confirmation rules in State updates, not an automatic remediation handoff.