Imported from stefanpems/sec-sre-ag (.builder/threat-pulse/SKILL.md). Install upstream with npx skills add stefanpems/sec-sre-ag --skill threat-pulse. Copyright stays with the author.

📏 Result & Token Guardrails — See shared-guardrails.md for universal result-cap, time-window, and aggregation rules that apply to all skills.

Threat Pulse — Instructions

Purpose

The Threat Pulse skill is a rapid, broad-spectrum security scan designed for the "if you only had 15 minutes" scenario. It executes 12 queries across 7 security domains, producing a prioritized dashboard of findings with drill-down recommendations to specialized investigation skills.

What this skill covers:

Data sources: SecurityIncident, SecurityAlert, IdentityInfo, AADUserRiskEvents, SigninLogs, AADNonInteractiveUserSignInLogs, DeviceProcessEvents, DeviceLogonEvents, DeviceInfo, ExposureGraphNodes, AADServicePrincipalSignInLogs, EmailEvents, CloudAppEvents, AuditLogs, DeviceTvmSoftwareVulnerabilities, DeviceTvmSoftwareVulnerabilitiesKB

Portal URL patterns are defined in the Defender XDR Portal Links table. Append tid=<tenant_id> (from config.json or agent settings) to ALL security.microsoft.com URLs.

Companion Files

⚠️ Runtime Location = "Must be on disk" means the file must exist on the local filesystem. Scripts are accessed at runtime — NOT via read_skill_file. They are resolved immediately on skill activation via the File Resolution cascade.

File Resolution (codeRefs-first — On Skill Activation)

generate_html_report.py runs from the local filesystem. Skill files must be resolved to disk before use.

🔴 MANDATORY — IMMEDIATE: The moment this skill is activated (i.e., the agent reads this SKILL.md), the agent MUST resolve ALL files listed below before doing anything else — before collecting parameters, before asking the user questions, before any other action.

Resolution Cascade

Resolve ALL 3 runtime files using this mandatory cascade:

1. codeRefs/sec-sre-ag/threat-pulse/
   → If ALL 3 files exist here: use this directory as <SKILL_DIR>
   → Execute/read files directly from here (companion files are co-located)
   → Do NOT copy files to tmp/

2. tmp/threat-pulse/
   → If ALL 3 files exist here (from previous materialization): use this directory as <SKILL_DIR>

3. Neither location has all files:
   → read_skill_file() from Builder for each missing file
   → CreateFile("tmp/threat-pulse/<filename>", <content>)
   → Use tmp/threat-pulse/ as <SKILL_DIR>

All subsequent commands in this skill reference the resolved directory as <SKILL_DIR>.

Files to Resolve

Step 1: Check codeRefs

ls codeRefs/sec-sre-ag/threat-pulse/generate_html_report.py codeRefs/sec-sre-ag/threat-pulse/threat-pulse-queries.md codeRefs/sec-sre-ag/threat-pulse/svg-widgets.yaml 2>/dev/null | wc -l
# If returns 3 → set <SKILL_DIR>=codeRefs/sec-sre-ag/threat-pulse → DONE

Step 2: Check tmp (if codeRefs not found)

ls tmp/threat-pulse/generate_html_report.py tmp/threat-pulse/threat-pulse-queries.md tmp/threat-pulse/svg-widgets.yaml 2>/dev/null | wc -l
# If returns 3 → set <SKILL_DIR>=tmp/threat-pulse → DONE

Step 3: Materialize from Builder (if neither location has all files)

🔴 CRITICAL: Write FULL file content. NEVER write placeholders or stubs.

Step 3a — Read ALL 3 files in a single parallel batch:

read_skill_file(skill_name="threat-pulse", file_path="generate_html_report.py")
read_skill_file(skill_name="threat-pulse", file_path="threat-pulse-queries.md")
read_skill_file(skill_name="threat-pulse", file_path="svg-widgets.yaml")

Step 3b — Write ALL 3 files in a single parallel batch:

CreateFile(filePath="tmp/threat-pulse/generate_html_report.py", content=<FULL content>)
CreateFile(filePath="tmp/threat-pulse/threat-pulse-queries.md", content=<FULL content>)
CreateFile(filePath="tmp/threat-pulse/svg-widgets.yaml", content=<FULL content>)

Total: 2 tool calls (read batch + write batch). Do NOT split into more batches. Set <SKILL_DIR>=tmp/threat-pulse.

🔴 PROHIBITED: Proceeding to Phase 0 without completed file resolution.

Pre-requisite: Environment Configuration (config.json)

Before executing any script resolved via the File Resolution cascade, the agent MUST ensure that config.json exists at the workspace root (the top-level directory of the agent workspace, NOT inside codeRefs/ or skill-specific directories).

Procedure:

1. Check: Verify that config.json exists at the workspace root and that all required fields are non-empty: tenant_name, sentinel_workspace_id, subscription_id, azure_mcp.subscription_id, azure_mcp.resource_group, and azure_mcp.workspace_name. If the file is complete, proceed to step 3.

2. If config.json is missing or incomplete, create it: a. Ask the user for the tenant name using AskUserQuestion with header "Tenant" and question: "What is your tenant name? (e.g., contoso.onmicrosoft.com or contoso.it)?" b. Extract from agent system prompt settings:

   • subscription_id → from the <azure_resource_access> section (the subscription ID the agent has access to)
   • sentinel_workspace_id → from the <log_analytics_access> section (the workspace GUID after workspace=)
   • workspace_name → from the <log_analytics_access> section (the workspace name before the colon) c. Discover the workspace resource group with RunAzCliReadCommands (never run az in the sandbox terminal), using:

   az monitor log-analytics workspace show --workspace-name <workspace_name> --subscription <subscription_id> --query resourceGroup -o tsv
   

   d. Create config.json at the workspace root with this structure:

   {
     "tenant_name": "<tenant_name>",
     "sentinel_workspace_id": "<workspace_guid>",
     "subscription_id": "<subscription_id>",
     "azure_mcp": {
       "subscription_id": "<subscription_id>",
       "resource_group": "<discovered_resource_group>",
       "workspace_name": "<workspace_name>"
     },
     "api_tokens": {}
   }

   e. Validate: Re-read the created file and verify that every required field listed in step 1 is non-empty. If platform settings or discovery did not provide a value, stop and report the missing field; never guess it.

3. Proceed with the skill workflow. All Python scripts find config.json by walking up from their own directory (max 6 levels), so the workspace root is the correct and expected location.

Rules:

• Do NOT write config.json inside codeRefs/ or inside skill-specific directories.
• Do NOT hardcode any environment-specific values in this skill file — all values are derived at runtime from the agent's own settings and user input.
• The api_tokens object is left empty — API tokens are loaded from Key Vault or environment variables at runtime.

Execution Environment Constraints

⚠️ READ FIRST — This skill operates in a constrained environment.

Execution Model (Two-Tier)

⛔ MANDATORY: All KQL queries are pre-validated in threat-pulse-queries.md. Do NOT write ad-hoc KQL — read the query from the file and execute it as-is with parameter substitution only.

Key Adaptations from AH to LA

📑 TABLE OF CONTENTS

1. File Resolution — Script & file resolution (codeRefs → tmp → Builder)
2. Critical Workflow Rules
3. Execution Workflow — Phase 0–3
4. Phase 4: Interactive Follow-Up Loop
5. Take Action — Portal links, AH queries, defanging
6. Post-Processing — Drift scores, cross-query correlation
7. Report Template
8. Known Pitfalls
9. Quality Checklist
10. HTML Report Generation — On-demand HTML export
11. SVG Dashboard Generation

⚠️ CRITICAL WORKFLOW RULES - READ FIRST ⚠️

1. Workspace discovery — Read workspace parameters from agent settings (<log_analytics_access>, <azure_resource_access>) or config.json. Never prompt the user for workspace parameters if either source is available.

2. Read config.json — Load workspace ID, tenant, subscription, and Azure MCP parameters before execution. If absent, rely on agent settings.

3. Output defaults — Default to inline chat with 7d lookback. NEVER ask the user for output format or preferences. Every execution renders ALL results inline. If the user explicitly requests a file ("generate HTML", "save as Markdown", "download Markdown", etc.), generate the requested format in addition to inline output. If the user just says "threat pulse", "run a scan", or similar — proceed immediately with defaults.

4. ⛔ MANDATORY: Evidence-based analysis only — Every finding must cite query results. Every "clear" verdict must cite 0 results.

5. Parallel execution — Run all 10 Tier 1 queries in parallel via Azure Monitor MCP. Present the 2 Tier 2 queries to the user simultaneously.

6. Cross-query correlation — After all queries complete, check for correlated findings per the Cross-Query Correlation table. Escalate priority when patterns match.

7. SecurityIncident output rule — Every incident MUST include a clickable Defender XDR portal URL: https://security.microsoft.com/incidents/{ProviderIncidentId}?tid=<tenant_id>.

8. ⛔ MANDATORY: Drill-Down Recommendations (tiered) — After rendering the main report, append drill-down recommendations. Skip only when ALL verdicts are ✅.

9. ⛔ MANDATORY: 30d drill-down lookback — ALL Phase 4 drill-down queries use 30d lookback, regardless of the Threat Pulse scan window. Entity-scoped queries have negligible performance difference between 7d and 30d. Substitute ago(7d) → ago(30d) in all drill-down queries.

10. ⛔ MANDATORY: The follow-up loop is stateful, memory-backed, and self-sustaining. Three invariants:

    • (a) Memory is the source of truth. The prompt pool lives ONLY in /memories/session/threat-pulse-drilldowns.md. Create it the first time the pool is built. NEVER reconstruct from conversation history — always memory view before each vscode_askQuestions call.
    • (b) The loop re-presents itself automatically. After EVERY completed drill-down, return to Phase 4 step 2 and call vscode_askQuestions again with the updated pool. The only exits are Skip or an empty pool.
    • (c) Quick Pick Call Contract is mechanical. Run the Pre-Flight Checklist and print the Pool Receipt before every call.

11. ⛔ MANDATORY: Read queries from file — All 12 queries are in threat-pulse-queries.md. read_file the query file BEFORE executing any queries. Do NOT write ad-hoc KQL or rely on memory.

12. ⛔ MANDATORY: Cache management — Query results are saved to output/threat-pulse/ during execution. Cache reuse follows strict rules:

    Cache Check Logic:
    
    1. If NO data files exist in output/threat-pulse/ → proceed with fresh data collection
    
    2. If data files exist, calculate their age:
       → age = current_UTC_time − file_modification_timestamp
       → If age > 4 hours → IGNORE cache entirely, proceed with fresh collection
    
    3. Analyze the user's ORIGINAL prompt for intent:
    
       REDO KEYWORDS (always re-collect, never ask):
             "repeat", "redo", "refresh", "update", "re-analyze",
             "start over", "from scratch", "new analysis"
       → If ANY redo keyword is detected → IGNORE cache, proceed with fresh collection
    
       REPORT-ONLY KEYWORDS (use cache if valid):
             "generate report", "generate HTML", "generate Markdown", "render",
             "show results"
       → If ANY report-only keyword AND cache age ≤ 4h:
         ASK the user:
                "Cached results were generated <TIME_AGO> ago (at <HH:MM> UTC).
                  Would you like to use them or run a new data collection?"
                Options: "Use cached data" / "Collect from scratch"
    
       NO IMPLICIT INTENT (default = fresh collection):
       → Proceed with fresh data collection without asking
    

    Key rules:

    • NEVER silently reuse cached data — either detect explicit report-only intent + ask, or re-collect.
    • Redo keywords bypass everything — no cache check, no question, just re-collect.
    • Default behavior is fresh collection — cache reuse is the exception, not the rule.

13. ⛔ MANDATORY: No PowerShell scripts — The execution environment does not have pwsh or PowerShell. All scripts MUST be Python. Do NOT generate .ps1 scripts or use Invoke-RestMethod, Invoke-WebRequest, or other PowerShell cmdlets in any context.

14. ⛔ MANDATORY: Result cap on all queries — Every KQL query executed by this skill MUST include a | take N cap (value defined per query in threat-pulse-queries.md). If a query in the file does not have a | take, append | take 100 before execution. This prevents token spikes when a query unexpectedly returns thousands of rows.

Execution Workflow

Phase 0: Prerequisites

1. Read workspace parameters from agent settings or config.json

2. Check cache — Apply the cache check logic from Rule 12:

   • Check output/threat-pulse/ for existing tp_results_*.json files
   • If files exist and age ≤ 4h: check user intent (redo keywords → re-collect; report-only keywords → ask; default → re-collect)
   • If cache is valid and user confirmed reuse: load results from JSON, skip to Phase 3

3. Read threat-pulse-queries.md to load all pre-validated KQL queries

4. Use defaults (inline chat, 7d) unless user specified otherwise

5. ⛔ MANDATORY: Display scan summary before executing any queries:

   🔍 Threat Pulse — Scan Plan

   Workspace: <WorkspaceName> (<WorkspaceId>) Lookback: <N>d

   Executing 12 queries across 7 domains:

   🔴 Incidents — Open incidents + 7d closed summary (Q1, Q2) 🔐 Identity — Identity risk posture, risk event enrichment, auth spray (Q3, Q4) 🤖 NonHuman ID — Service principal behavioral drift (Q5) 💻 Endpoint — Device process drift, rare process chains (Q6, Q7) 📧 Email — Inbound threat snapshot (Q8) 🔑 Admin & Cloud — Cloud app ops, privileged operations (Q9, Q10) 🛡️ Exposure — Critical assets, exploitable CVEs (Q11, Q12)

   Direct execution: 10 queries via Log Analytics (parallel) User-assisted: 2 queries via Advanced Hunting (Q11, Q12) Estimated time: ~3–5 minutes

Phase 1: Execute Tier 1 Queries (Q1–Q10) — Parallel

Run all 10 queries in parallel via Azure Monitor MCP (monitor-client_monitor_workspace_log_query).

For Q5 (SPN Drift): Set the hours parameter to at least 2328 (97 days × 24 hours) to cover the 97-day lookback.

Phase 2: Present Tier 2 Queries (Q11, Q12) — User-Assisted

While Tier 1 executes, present Q11 and Q12 to the user for execution in Advanced Hunting.

1. Read Q11 and Q12 from threat-pulse-queries.md
2. Replace <TENANT_ID> with actual tenant ID from config
3. Present both queries in separate code blocks with clear instructions:
   • "Copy this query and run it in Advanced Hunting"
   • "Paste the results back here when complete"
4. If Q11 has a partial LA fallback (internet-facing devices without ExposureGraph), execute that in parallel as Q11-partial
5. If the user declines or cannot run AH queries, mark Q11/Q12 as ❓ No Data and proceed

Phase 3: Post-Processing & Report

0. Save query results to cache — Aggregate all Q1–Q12 results into output/threat-pulse/tp_results_<YYYYMMDD_HHMMSS>.json as a JSON object with keys: scan_timestamp (ISO8601), workspace_id, workspace_name, lookback_days, and queries (dict of Q1–Q12, each with status = ok/error/no_data, row_count, and results array). Use encoding="utf-8" and ensure_ascii=False. Create the output/threat-pulse/ directory if it doesn't exist.
1. Interpret device drift scores from Q6 results (see Post-Processing)
2. Run cross-query correlation checks (see rule 6)
3. Assign verdicts to each domain (🔴 Escalate / 🟠 Investigate / 🟡 Monitor / ✅ Clear)
4. Generate prioritized recommendations with drill-down skill references
5. Render the report immediately inline — Dashboard Summary, Detailed Findings, Cross-Query Correlations, and 🎯 Recommended Actions
6. After the report is rendered, append the 📂 Recommended Drill-Downs section. Skip when all verdicts are ✅.
7. File output (only if explicitly requested):
   • Markdown: Save the rendered report to reports/threat-pulse/Threat_Pulse_<YYYYMMDD_HHMMSS>.md
   • HTML: First save as markdown (step above), then run: python3 tmp/threat-pulse/generate_html_report.py "reports/threat-pulse/Threat_Pulse_<ts>.md" --output-dir reports/threat-pulse/

Phase 4: Interactive Follow-Up Loop

After rendering the report, present the user with a selectable list of follow-up actions. Runs when at least one 🔴, 🟠, or 🟡 verdict exists (skip only when ALL are ✅).

This is a loop, not a one-shot. After each action completes, re-present the selection list with the updated pool.

⛔ Loop invariant — verify before EVERY iteration (per Rule 10): (a) /memories/session/threat-pulse-drilldowns.md exists and was just re-read; (b) re-presenting menu automatically after prior drill-down; (c) Pre-Flight Checklist passed and Pool Receipt printed.

Prompt types (three categories, one unified list):

Skill matching rules — derive from findings:

Skills not available in this environment (e.g., scope-drift-detection, email-threat-posture, authentication-tracing, ca-policy-investigation, app-registration-posture, exposure-investigation, mitre-coverage-report): Route to kql-query-authoring with specific context and entities. The agent will use KQL Search MCP for schema validation and generate targeted queries.

Procedure:

1. Build the initial prompt pool by combining:

   • Skill prompts: one per unique entity + matching skill from the table above
   • KQL hunt prompts: for domains where no specialized skill exists
   • IOC prompts: suspicious IPs/domains from non-✅ findings not covered by a skill prompt
   • Deduplicate: if skill prompt and IOC prompt target same entity, keep skill prompt
   • ⛔ Persist the pool. Write to /memories/session/threat-pulse-drilldowns.md using the template below.

   Memory File Template

   # Threat Pulse Session — <YYYY-MM-DD>
   
   **Workspace:** <name> (<id>)
   **Lookback:** <7d|30d|90d>
   **Scan Start:** <YYYY-MM-DD HH:MM UTC>
   
   ## Active Prompt Pool
   
   <!-- FORMAT: `- <ICON> <action> <entity> — Q<N>: <finding> → <skill>` -->
   <!-- ` — ` (space-emdash-space) is the REQUIRED label/description split delimiter. -->
   
   - 🔍 Investigate incident #<IncidentId> — Q1: <brief finding>, <N> alerts → kql-query-authoring
   - 🎯 Enrich and investigate IP <IP> — Q4: <N> spray attempts / <N> users → ioc-investigation
   ...
   
   ## Pulse Key Findings (quick reference)
   
   ...
   
   ## Completed Drill-Downs
   
   _(none yet)_

2. Call vscode_askQuestions using the Quick Pick Call Contract below.

   Quick Pick Call Contract

   • header: Follow-Up Investigation
   • question: Select one or more actions to launch (or skip):
   • options: entity prompts (from memory), then 📋 (if truncated), then 💾 / 🔄 / Skip as the final three.
     1. 💾 Save full investigation report — Save the complete Threat Pulse session as a markdown file
     2. 🔄 Refresh prompt pool — Rebuild follow-up prompts from existing findings (does NOT re-run queries)
     3. Skip — No follow-up — investigation complete
   • Allowed Label icons: 🔍 📄 🎯 💾 🆕 🔄 📋. Verdict emoji (🔴🟠🟡🟢✅) banned from Labels.

   🔴 Pre-Flight Checklist

   □ 1. memory view → read `## Active Prompt Pool` just now
   □ 2. Count entity prompts (exclude 💾/🔄/📋/Skip) = N
   □ 3. Format integrity: every line starts with `- ` + ONE icon
   □ 4. If N > 12: render top 12 + append `📋 Show full prompt pool (N items)`
   □ 5. Split memory line at FIRST ` — ` → label = before, description = after
   □ 6. Each option Label has exactly ONE icon; Description has at most ONE `→ target`
   □ 7. `multiSelect: true` in call args
   □ 8. ZERO `recommended` keys anywhere in options[]
   □ 9. Tail = 💾 / 🔄 / Skip (or 📋 / 💾 / 🔄 / Skip if truncated)
   □ 10. Print Pool Receipt line to chat BEFORE invoking
   

   Pool Receipt:

   📊 Pool: <N> total / rendering <R> (🆕×<a>, 🔍×<b>, 📄×<c>, 🎯×<d>) / truncated <✔|—> | multiSelect=true ✔ | recommended=0 ✔
   

3. If user selects Skip or pool is empty: end skill execution.

4. Freeform input routing — Match to known skills or use kql-query-authoring with context.

5. 💾 Save full investigation report: Compile pulse + drill-downs into reports/threat-pulse/Threat_Pulse_YYYYMMDD_HHMMSS.md. Drop 💾 from subsequent iterations.

6. 🔄 Refresh prompt pool: Rebuild prompts from pulse + drill-down findings. Deduplicate against completed prompts.

7. Execute selected actions sequentially. For each:

   • 🔍 Skill prompt: read_file the child SKILL.md BEFORE writing ANY query. Use the skill's investigation shortcuts.
   • 📄 KQL hunt prompt: Load kql-query-authoring skill, use KQL Search MCP for schema validation, execute targeted queries.
   • 🎯 IOC prompt: Load ioc-investigation skill with the target indicator.

   After each drill-down, append to /memories/session/threat-pulse-drilldowns.md under ## Completed Drill-Downs:

   ### <N>. <Prompt Label> (<skill-name>, <YYYY-MM-DD HH:MM>)
   - **Entity:** <target entity>
   - **Trigger:** Q<N> — <original finding>
   - **Key Findings:** <1–8 bullets, evidence-cited>
   - **Risk Assessment:** <emoji> <level> — <1-line justification>
   - **Cross-References:** <overlaps with other drill-downs or pulse queries>
   - **Recommendations:** <top 1–3 actions>
   

   Before returning to step 2:

   1. New Evidence Scan — review drill-down for entities/TTPs not in prior findings. Add 🆕 prompts only for meaningful leads.
   2. Reload → mutate → write back — memory view → delete completed line(s) → prepend 🆕 → memory str_replace.
   3. Return to step 2.

Atomic options — ONE action per option. Each maps to ONE skill + ONE entity.

🔍 Skill Drill-Down Execution Rule

⛔ MANDATORY — applies to ALL 🔍 drill-down executions.

1. read_file the child skill's SKILL.md
2. Match trigger context (TP Q number) against the skill's Investigation shortcuts
3. Execute the shortcut query chain — substitute only entity placeholders and date ranges
4. For quick triage: run only the shortcut chain. For deep investigation: run full skill workflow

🎬 Take Action — Portal-Ready Remediation Blocks

⚠️ AI-generated content may be incorrect. Always review Take Action queries and portal links for accuracy before executing remediation actions.

After every non-✅ drill-down that surfaces actionable entities, append a 🎬 Take Action section with direct portal links (single entities) or Advanced Hunting queries (bulk entities).

Skip when: verdict is ✅/🔵, or action already taken.

Every 🎬 Take Action heading MUST be immediately followed by the AI-content warning blockquote above.

Single Entity vs Bulk Entity Decision Rule

⛔ PROHIBITED: Generating an AH query for a single entity when a portal link suffices.

ID sources (agent retrieves silently — never ask the user):

• User OID: RunAzCliReadCommands → az rest --method GET --url "https://graph.microsoft.com/v1.0/users/<UPN>?$select=id", or KQL fallback from IdentityInfo.AccountObjectId
• MDE DeviceId: DeviceInfo table via LA query (see threat-pulse-queries.md → MDE Device ID Lookup)

Required Columns per Entity Type

Template Queries (for bulk remediation — present to user for AH execution)

📧 Email — by NetworkMessageId:

EmailEvents
| where Timestamp > ago(7d)
| where NetworkMessageId in ("<id1>", "<id2>")
| take 50

💻 Bulk Devices (2+):

DeviceInfo
| where Timestamp > ago(1d)
| where DeviceName in~ ("<device1>", "<device2>")
| summarize arg_max(Timestamp, *) by DeviceId
| project DeviceId, DeviceName, OSPlatform, MachineGroup

📁 File — by hash:

DeviceFileEvents
| where Timestamp > ago(7d)
| where SHA1 == "<hash>" or SHA256 == "<hash>"
| project DeviceId, DeviceName, SHA1, SHA256, FileName, FolderPath
| take 50

🔗 Bulk Indicators (network-layer IPs):

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIP in ("<ip1>", "<ip2>", "<ip3>")
| summarize Connections = count(), Ports = make_set(LocalPort) by RemoteIP
| order by Connections desc

🔗 Auth-layer IPs (from SigninLogs):

SigninLogs
| where TimeGenerated > ago(30d)
| where IPAddress in ("<ip1>", "<ip2>", "<ip3>")
| summarize SignIns = count(), Users = dcount(UserPrincipalName), Countries = make_set(tostring(parse_json(LocationDetails).countryOrRegion), 5) by IPAddress
| order by SignIns desc

Note: Take Action template queries use Timestamp (AH syntax) because the user executes them in Advanced Hunting. LA-executed queries use TimeGenerated.

Defender XDR Portal Links — All Entity Types

🔴 Every entity in action/recommendation tables MUST be a clickable portal link.

User fallbacks: ?upn=<UPN> when ObjectId unavailable; ?sid=<SID>&accountName=<Name>&accountDomain=<Domain> for on-prem AD.

🔴 Portal URL Allowlist — No Invented Paths. The 7 patterns above plus /v2/advanced-hunting?tid=<tenant_id> are the ONLY security.microsoft.com URLs you may emit.

Entity Display — Portal Link vs Defang (Mutually Exclusive)

Defang rules: http:// → hxxp://, https:// → hxxps://, . in domain → [.].

Post-Processing

Device Drift Score Interpretation (Q6)

Q6 returns pre-computed drift scores — no LLM-side math needed. Apply verdicts using this scale:

VolDrift cap context:

• VolDriftRaw ≫ 300 but ProcDrift/ChainDrift/AcctDrift near 100 → infrastructure noise
• VolDriftRaw > 300 AND diversity metrics elevated → genuine anomaly
• VolDriftRaw ≤ 300 → cap not triggered, score reflects true proportions

Fleet-uniformity rule: If ALL top-10 devices cluster within 20 points, downgrade verdict one level.

⛔ DO NOT manually recompute drift scores. Trust the returned DriftScore column.

Cross-Query Correlation

After all queries complete, check these patterns and escalate when found:

Report Template

Output modes:

• Inline chat (default) — render in chat. Truncate data tables to 10 rows.
• Markdown file — triggered by 💾 Save. Full data tables. Path: reports/threat-pulse/Threat_Pulse_YYYYMMDD_HHMMSS.md.

Verdicts: 🔴 Escalate | 🟠 Investigate | 🟡 Monitor | ✅ Clear | 🔵 Informational | ❓ No Data

• ❓ No Data — query returned error, table not found, or user declined AH execution. Report the gap.
• 🔵 Informational — neutral context (e.g., Q2 with 0 closures, Q6 with DriftScore < 80).
• Zero results: ✅ No <type> detected in the last <N>d. Checked: <table> (0 matches)

Structure

# 🔍 Threat Pulse — <Workspace> | <Date>
**Workspace:** <name> (`<id>`)  
**Scan Date:** <YYYY-MM-DD HH:MM UTC>  
**Scan Duration:** <N>min | **Queries:** 12 | **Drill-Downs:** <N>  (file mode only)

## Executive Summary
<2–4 sentences synthesizing findings. State final risk posture.>

## Dashboard Summary
<12-row table (Q1–Q12) — columns: #, Domain, Status (verdict emoji), Key Finding (1-line).>

## Detailed Findings
<One section per query — EVERY query gets a section. Q2 always renders after Q1 even when Q1 is ✅.>

## Cross-Query Correlations
<Table per Post-Processing rules, or `✅ No correlations detected`.>

## 🎯 Recommended Actions
<Prioritized table: action, trigger query, drill-down skill.>

## 📂 Recommended Drill-Downs
<Numbered list with entity-specific prompts. For 🟡-only use "📂 Proactive Hunting Suggestions". Omit when all ✅.>

## Drill-Down Investigation Results       (file mode, when drill-downs executed)
### 1. <Title> — <Skill Name>
**Triggered by:** Q<N> — <finding>  
**Entity:** <target> | **Lookback:** <timerange> | **Risk:** <emoji> <level>
**Key Findings:** <max 8 evidence-cited bullets>
**Recommendations:** <numbered actions>

## Cross-Investigation Correlation        (file mode, when drill-downs executed)
| Connection | Evidence | Drill-Downs | Implication |

## Consolidated Recommendations           (file mode)
| Priority | Recommendation | Source | Risk |

## Appendix: Investigation Timeline       (file mode)
| Time | Action | Key Result |

Column / Format Rules

• Q1: | Incident | Sev | Title | Age | Alerts | Owner | Tactics | Accounts | Devices | Tags |
  • When TotalAll > 10: prepend **Showing 10 of {TotalAll} open incidents ({TotalHighCritical} High/Critical)**
  • When TitleDupCount > 1: append (+{TitleDupCount-1} more) to Title cell
• Q1 incidents must include [#<id>](https://security.microsoft.com/incidents/<ProviderIncidentId>?tid=<tenant_id>) links.
• Q2: Classification breakdown + severity + MITRE. Always render even when Q1 is ✅.

Rules

Known Pitfalls

Full table pitfalls are documented in kql-query-authoring/known-table-pitfalls.md. Read before querying any table listed there.

Quality Checklist

• All 12 queries executed (10 direct + 2 AH or ❓ if declined)
• Every query has a verdict row — no omissions
• ✅ verdicts cite table + "0 results"; 🔴/🟠 cite specific evidence
• All incidents have clickable XDR portal URLs
• Cross-query correlations checked
• Every non-✅ drill-down has a 🎬 Take Action block
• Every 🎬 Take Action block includes the ⚠️ AI-generated content warning
• 📂 Recommended Drill-Downs present when any non-✅ verdict exists
• No fabricated data
• All KQL queries read from threat-pulse-queries.md, not written ad-hoc
• Query results saved to output/threat-pulse/tp_results_*.json for cache

HTML Report Generation

When the user explicitly requests an HTML report ("generate HTML", "export HTML", "download HTML", etc.):

1. Save the inline report as markdown to reports/threat-pulse/Threat_Pulse_<YYYYMMDD_HHMMSS>.md
2. Run the HTML generator:

   python3 tmp/threat-pulse/generate_html_report.py \
       "reports/threat-pulse/Threat_Pulse_<ts>.md" \
       --output-dir reports/threat-pulse/

3. Report the result — provide the path to the generated HTML file and its size.

The script reads the markdown report, parses sections (Executive Summary, Dashboard Summary, Detailed Findings, etc.) and tables, applies verdict badges (🔴🟠🟡✅🔵❓), and produces a self-contained dark-themed HTML file with:

• Fixed header bar with risk level indicator
• Verdict KPI cards (counts per verdict type)
• Collapsible H3 subsections for drill-down details
• Responsive table styling with portal link preservation
• Print-friendly CSS

⚠️ The script must be resolved via the File Resolution cascade before use.

SVG Dashboard Generation

After completing the Threat Pulse report, the user may request an SVG visualization. Use the svg-dashboard skill in manifest mode — the widget manifest is at svg-widgets.yaml.

Execution

1. Read svg-widgets.yaml (widget manifest)
2. Read the svg-dashboard SKILL.md for component rendering rules
3. Map manifest field values to Threat Pulse report data in context
4. Render SVG → save to temp/threat_pulse_{date}_dashboard.svg