{"owner":"Azure","repo":"Azure-Sentinel","hasSkills":true,"totalSkillsCount":6,"totalTokensCount":4004,"categories":["root-instruction","claude-rule","copilot-instructions","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"Azure-Sentinel":{"command":"npx","args":["-y","@modelcontextprotocol/server-Azure-Sentinel"]}}},"found":["AGENTS.md","CLAUDE.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# Repository agent instructions\n\n## Protected agent and tooling implementation\n\nDuring normal repository tasks, treat agent definitions, skills, instructions,\ntooling backends, schemas, tests, dependency metadata, workflow definitions,\nsafety gates, permission checks, packaging behavior, and capabilities as\nimmutable.\n\nDo not create, edit, delete, rename, patch, bypass, or replace implementation\nunder these paths to recover from a task, environment, dependency,\nauthentication, conversion, validation, packaging, deployment, or runtime\nfailure:\n\n- `AGENTS.md`;\n- `.github/agents/**`;\n- `.github/skills/**`; or\n- `Tools/**`.\n\nStop the affected operation and report that a maintainer change is required.\nImplementation changes are allowed only in a separate development task where\nthe user explicitly states that they are acting as a repository/toolkit\nmaintainer and requests the specific implementation change. Requests to run,\nretry, continue, migrate, package, validate, deploy, or fix generated content\nnever grant permission to change agent or tooling implementation.\n\nThe XDR Solution Manager is stricter: it can never make agent or tooling\nimplementation changes, even when explicitly requested by an owner or\nmaintainer. Route such work to a different development agent or require it to\nbe performed manually.\n\nWhen a request involves Sentinel-to-Defender-XDR migration, XDR Detections,\nhybrid solution packaging, or AR/CD qualification:\n\n1. Read and follow\n   `Tools\\SentinelToXDRMigration\\agent-workflows\\end-to-end-migration.md`.\n2. Treat that file as the canonical workflow; do not redefine its stages or\n   gates in this adapter.\n3. Keep deterministic work in the repository Python and PowerShell tools.\n4. Default to `authoring`; ask before optional lab `qualification`.\n5. Deployment, mock ingestion, and alert parity are Qualification-only actions\n   and require explicit exact-scope approval.\n6. Use the V3.1 `package-v3-1` route for Sentinel and XDR solution content;\n   do not route XDR packaging through V4.\n7. Resume from `workflow-state.json` and record artifacts and evidence.\n8. Require explicit approval immediately before any environment write.\n","CLAUDE.md":"# Claude Code instructions\n\nFor Microsoft Sentinel-to-Defender-XDR migration or authoring work, first read:\n\n`Tools\\SentinelToXDRMigration\\agent-workflows\\end-to-end-migration.md`\n\nFollow that canonical workflow and use the repository CLI and PowerShell\nentry points directly. Do not replace deterministic conversion, validation,\npackaging, deployment, or parity logic with model-generated approximations.\n\nDefault to `authoring`. Ask before optional lab `qualification`; it is not\nrequired for ISV publishing. Use V3.1 through `package-v3-1` for Sentinel and\nXDR solution packages. Resume from `workflow-state.json`, preserve disabled\ndetections, and request explicit approval before writes.\n",".github/copilot-instructions.md":"# GitHub Copilot Instructions for Azure-Sentinel Repository\n\n# Copilot Pull Request Review Guidelines\n\nWhen reviewing pull requests, follow these rules strictly.\n\n## IMPORTANT: Load Custom Instructions Based on File Type\n\n**Before reviewing any file, CHECK if it matches these patterns:**\n\n### For Solution Metadata Files (`Solutions/**/SolutionMetadata.json`)\n1. **LOAD and USE:** `.github/instructions/solution-metadata.instructions.md`\n2. Apply ALL guidelines from that file\n3. Check all validation rules, required fields, and review focus areas from that custom instruction file\n4. Do NOT use general instructions for these files - only use the solution-metadata custom instructions\n\n### For Solution Data Files (`Solutions/**/Data/Solution_*.json`)\n1. **LOAD and USE:** `.github/instructions/solution-data.instructions.md`\n2. Apply ALL guidelines from that file\n3. Check all validation rules, required fields, and review focus areas from that custom instruction file\n4. Do NOT use general instructions for these files - only use the solution-data custom instructions\n\n### For Release Notes Files (`Solutions/**/ReleaseNotes.md`)\n1. **LOAD and USE:** `.github/instructions/releasenotes.instructions.md`\n2. Apply ALL validation rules from that file (path, table structure, version format/order, DD-MM-YYYY date format)\n3. If this is the **only changed file in the PR**, still run full Release Notes validation and add findings\n4. Do NOT use generic fallback comments for these files\n\n### For Analytic Rules Files (`Detections/**/*.yaml`, `Detections/**/*.yml`, `Solutions/**/Analytic Rules/*.yaml`, `Solutions/**/Analytic Rules/*.yml`)\n1. **LOAD and USE:** `.github/instructions/detections.instructions.md`\n2. Apply ALL validation rules from that file\n3. Check all field requirements, MITRE ATT&CK mappings, KQL syntax, and formatting guidelines from that custom instruction file\n4. Validate GUID format, rule names, descriptions, severity levels, and other field-based validation rules\n5. Do NOT use general instructions for these files - only use the detections custom instructions\n\n### For Hunting Queries Files (`Hunting Queries/**/*.yaml`, `Solutions/**/Hunting Queries/*.yaml`)\n1. **LOAD and USE:** `.github/instructions/huntingqueries.instructions.md`\n2. Apply ALL guidelines from that file\n3. Verify all required fields are present and properly formatted\n4. Do NOT use general instructions for these files - only use the huntingqueries custom instructions\n\n### For Playbooks Files (`Playbooks/**/*.json`, `Playbooks/**/README.md`, `Solutions/**/Playbooks/**/*.json`, `Solutions/**/Playbooks/**/README.md`)\n1. **LOAD and USE:** `.github/instructions/playbooks.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate ARM template structure, metadata fields, parameters, and README requirements from that custom instruction file\n4. Check all required sections in README.md and ARM template metadata\n5. Do NOT use general instructions for these files - only use the playbooks custom instructions\n\n### For Workbooks Files (`Workbooks/*.json`, `Solutions/**/Workbooks/*.json`)\n1. **LOAD and USE:** `.github/instructions/workbook.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate workbook JSON structure, required fields, items array, and metadata requirements from that custom instruction file\n4. Check all required top-level fields and item structure validation\n5. Do NOT use general instructions for these files - only use the workbook custom instructions\n\n### For ASIM Changelog Files (`Parsers/ASim*/CHANGELOG/*.md`)\n1. **LOAD and USE:** `.github/instructions/asim-changelogs.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate the changelog against the corresponding parser YAML and pull request changes\n4. Do NOT use general instructions for these files - only use the ASIM changelog custom instructions\n\n### For ASIM Parser Files\n\nApply this section before the generic parser instructions when a changed YAML file is an ASIM parser, including:\n\n- `Parsers/ASim*/Parsers/ASim*.yaml`\n- `Parsers/ASim*/Parsers/vim*.yaml`\n\n1. **LOAD and USE:** `.github/instructions/asim-parsers.instructions.md`\n2. Apply ALL guidelines from that file\n3. Do NOT apply the generic parser instructions when this ASIM-specific section applies\n\n### For Parser Files (`Parsers/**/*.yaml`, `Parsers/**/*.yml`, `Solutions/**/Parsers/**/*.yaml`, `Solutions/**/Parsers/**/*.yml`)\n1. **LOAD and USE:** `.github/instructions/parsers.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate parser syntax, KQL accuracy, YAML structure, and all required fields from that custom instruction file\n4. Do NOT use general instructions for these files - only use the parsers custom instructions\n\n### For Building, Packaging, or Validating Solutions\nWhen the user asks to **build**, **package**, **validate**, or **run validations** on a solution:\n1. **LOAD and USE:** `.github/instructions/packaging.instructions.md`\n2. Apply ALL guidelines from that file — it contains the script path, parameters, fuzzy matching behavior, and report display rules\n3. **Always use the build script** at `.script/local-validation/build-and-validate.ps1` — do NOT run validators manually or write your own validation logic\n4. **BEFORE running the script, tell the user:** \"🔄 Running full build & validation suite for {SolutionName}. This typically takes 3-5 minutes — I'll present the complete report when it finishes.\" This message MUST appear in chat before the script executes so the user knows work is happening.\n5. **The script takes 3-10 minutes.** NEVER tell the user to \"check the terminal.\"\n6. Present the full report — the text between `[REPORT_START]` and `[REPORT_END]` — in your chat response\n7. This applies to ALL solutions, including newly created ones that may not have a Package/ folder yet\n\n**Trigger phrases:** \"build solution\", \"package solution\", \"validate solution\", \"run validations\", \"run CI checks\", \"check if solution passes\", \"create V3 package\"\n\n---\n\n## Files and folders to ignore\nDo NOT review or add comments for changes in the following paths:\n\n- Solutions/**/Data Connectors/**\n- Solutions/**/Package/**\n\nIf files from these paths appear in the PR, completely skip them and do not generate comments.\n\n## Solutions Analyzer Tools\n\nWhen working with the Solutions Analyzer tools in `Tools/Solutions Analyzer/`, follow the dedicated skills under `.github/skills/`:\n\n- **`run-solution-analyzer`** — running the mapper, doc generator, ASIM browser, and `upload_to_kusto`; output locations; force-refresh and caching.\n- **`update-solution-analyzer`** — modifying scripts, updating `script-docs/`, README changelog rules, CSV output sync with `upload_to_kusto.py`, and static/interactive index plus markdown/HTML entity page synchronization.\n\n**MANDATORY:** Before editing ANY file under `Tools/Solutions Analyzer/` — including small fixes such as renames, regex/pattern tweaks, escaping changes, override additions, or one-line behavior changes — first load `.github/skills/update-solution-analyzer/SKILL.md` and follow it. A `## Version History` changelog entry in `Tools/Solutions Analyzer/README.md` is **required for feature additions and behavior changes** (new features, changed analysis logic, new/renamed/removed CSV columns, parameter changes); pure bug fixes — such as typo corrections, crash fixes, escape/regex tweaks, or one-line fixes that restore intended behavior — may be logged at your discretion but are not required.\n\nThere are THREE different output scenarios - **never confuse them**:\n\n1. **Default (development):** CSVs are written to `Tools/Solutions Analyzer/` in the current branch\n   - This is the normal case when developing/testing\n   - **Never generate documentation here**\n\n2. **Output worktree (publishing CSVs):** `C:\\Users\\ofshezaf\\GitHub\\Azure-Sentinel-solution-analyzer-output\\Tools\\Solutions Analyzer`\n   - Only use this when **specifically requested** to \"publish CSVs to the output branch\"\n   - This is a separate git worktree for the CSV output branch\n   - **Only CSVs go here, never documentation**\n\n3. **Documentation output:** `C:\\Users\\ofshezaf\\GitHub\\sentinelninja\\Solutions Docs`\n   - This is where generated markdown documentation goes\n   - This is in a **separate repository** (sentinelninja)\n   - Empty the target folder before generating new docs\n\n### Key Rules\n\n- **Never generate docs locally** in the Azure-Sentinel repository\n- **Generate docs only in the sentinelninja repo** when asked or needed\n- **For official CSV releases**, generate CSVs **only** in the solution analyzer output worktree\n- Always use `--output-dir` flag when running `generate_connector_docs.py`\n\n### Running Scripts\n\n#### Mapper Script\n```powershell\ncd \"Tools/Solutions Analyzer\"\npython map_solutions_connectors_tables.py\n```\n\n**Note:** Do NOT truncate or filter the output (e.g., do not pipe through `Select-Object`). The script prints timestamped progress messages to the console that the user needs to see. Run with `isBackground: false` and `timeout: 0` so the full output is visible.\n\n#### Documentation Generator\n```powershell\npython generate_connector_docs.py --output-dir \"C:\\Users\\ofshezaf\\GitHub\\sentinelninja\\Solutions Docs\" --skip-input-generation\n```\n\n**IMPORTANT:** Never run without `--output-dir` flag.\n\n**IMPORTANT:** Do NOT truncate or filter the output (e.g., do not pipe through `Select-Object`). Run with `isBackground: false` and `timeout: 0` so the full output is visible to the user.\n\n**IMPORTANT:** Always use `--skip-input-generation` unless you specifically need to regenerate the input CSVs (mapper + collect_table_info). Without this flag, the doc generator will re-run those scripts automatically, which is slow and unnecessary if the CSVs are already up-to-date.\n\n**IMPORTANT:** Run the mapper script before generating docs if:\n- The mapper script itself was modified, OR\n- Any override YAML file in the `overrides/` folder was modified (including adding, editing, or removing `additional_connectors` entries), OR\n- You specifically need to refresh the CSV data, OR\n- You are explicitly asked to run the mapper\n\n### Caching and Logging\n\n- **Cache:** `.cache/` folder for analysis caching\n- **Logs:** `.logs/` folder for log files\n\n**Log file:** `Tools/Solutions Analyzer/.logs/map_solutions_connectors_tables.log`\n\nUse `--force-refresh` with these types when modifying analysis logic:\n- `asim` - ASIM parser analysis\n- `parsers` - Non-ASIM parser analysis\n- `solutions` - Solution content analysis\n- `standalone` - Standalone content item analysis\n- `marketplace` - Marketplace availability check (requires network)\n- `tables` - Table reference info (requires network)\n\n### Script Documentation\n\n**Before updating a script:** Always review the relevant script documentation in `Tools/Solutions Analyzer/docs/` first.\n\n**When updating a script**, update the corresponding script doc to reflect:\n- Any script parameters added or changed\n- Any output file changes, including changes to CSV files (new columns, renamed columns, removed columns)\n- Any changes to analysis methods or logic\n- Update the primary readme.md if needed and add the change to the change log. Do not add a version if the previous version as manifested by the changelog, was not committed yet.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# Repository agent instructions\n\n## Protected agent and tooling implementation\n\nDuring normal repository tasks, treat agent definitions, skills, instructions,\ntooling backends, schemas, tests, dependency metadata, workflow definitions,\nsafety gates, permission checks, packaging behavior, and capabilities as\nimmutable.\n\nDo not create, edit, delete, rename, patch, bypass, or replace implementation\nunder these paths to recover from a task, environment, dependency,\nauthentication, conversion, validation, packaging, deployment, or runtime\nfailure:\n\n- `AGENTS.md`;\n- `.github/agents/**`;\n- `.github/skills/**`; or\n- `Tools/**`.\n\nStop the affected operation and report that a maintainer change is required.\nImplementation changes are allowed only in a separate development task where\nthe user explicitly states that they are acting as a repository/toolkit\nmaintainer and requests the specific implementation change. Requests to run,\nretry, continue, migrate, package, validate, deploy, or fix generated content\nnever grant permission to change agent or tooling implementation.\n\nThe XDR Solution Manager is stricter: it can never make agent or tooling\nimplementation changes, even when explicitly requested by an owner or\nmaintainer. Route such work to a different development agent or require it to\nbe performed manually.\n\nWhen a request involves Sentinel-to-Defender-XDR migration, XDR Detections,\nhybrid solution packaging, or AR/CD qualification:\n\n1. Read and follow\n   `Tools\\SentinelToXDRMigration\\agent-workflows\\end-to-end-migration.md`.\n2. Treat that file as the canonical workflow; do not redefine its stages or\n   gates in this adapter.\n3. Keep deterministic work in the repository Python and PowerShell tools.\n4. Default to `authoring`; ask before optional lab `qualification`.\n5. Deployment, mock ingestion, and alert parity are Qualification-only actions\n   and require explicit exact-scope approval.\n6. Use the V3.1 `package-v3-1` route for Sentinel and XDR solution content;\n   do not route XDR packaging through V4.\n7. Resume from `workflow-state.json` and record artifacts and evidence.\n8. Require explicit approval immediately before any environment write.\n","CLAUDE.md":"# Claude Code instructions\n\nFor Microsoft Sentinel-to-Defender-XDR migration or authoring work, first read:\n\n`Tools\\SentinelToXDRMigration\\agent-workflows\\end-to-end-migration.md`\n\nFollow that canonical workflow and use the repository CLI and PowerShell\nentry points directly. Do not replace deterministic conversion, validation,\npackaging, deployment, or parity logic with model-generated approximations.\n\nDefault to `authoring`. Ask before optional lab `qualification`; it is not\nrequired for ISV publishing. Use V3.1 through `package-v3-1` for Sentinel and\nXDR solution packages. Resume from `workflow-state.json`, preserve disabled\ndetections, and request explicit approval before writes.\n",".github/copilot-instructions.md":"# GitHub Copilot Instructions for Azure-Sentinel Repository\n\n# Copilot Pull Request Review Guidelines\n\nWhen reviewing pull requests, follow these rules strictly.\n\n## IMPORTANT: Load Custom Instructions Based on File Type\n\n**Before reviewing any file, CHECK if it matches these patterns:**\n\n### For Solution Metadata Files (`Solutions/**/SolutionMetadata.json`)\n1. **LOAD and USE:** `.github/instructions/solution-metadata.instructions.md`\n2. Apply ALL guidelines from that file\n3. Check all validation rules, required fields, and review focus areas from that custom instruction file\n4. Do NOT use general instructions for these files - only use the solution-metadata custom instructions\n\n### For Solution Data Files (`Solutions/**/Data/Solution_*.json`)\n1. **LOAD and USE:** `.github/instructions/solution-data.instructions.md`\n2. Apply ALL guidelines from that file\n3. Check all validation rules, required fields, and review focus areas from that custom instruction file\n4. Do NOT use general instructions for these files - only use the solution-data custom instructions\n\n### For Release Notes Files (`Solutions/**/ReleaseNotes.md`)\n1. **LOAD and USE:** `.github/instructions/releasenotes.instructions.md`\n2. Apply ALL validation rules from that file (path, table structure, version format/order, DD-MM-YYYY date format)\n3. If this is the **only changed file in the PR**, still run full Release Notes validation and add findings\n4. Do NOT use generic fallback comments for these files\n\n### For Analytic Rules Files (`Detections/**/*.yaml`, `Detections/**/*.yml`, `Solutions/**/Analytic Rules/*.yaml`, `Solutions/**/Analytic Rules/*.yml`)\n1. **LOAD and USE:** `.github/instructions/detections.instructions.md`\n2. Apply ALL validation rules from that file\n3. Check all field requirements, MITRE ATT&CK mappings, KQL syntax, and formatting guidelines from that custom instruction file\n4. Validate GUID format, rule names, descriptions, severity levels, and other field-based validation rules\n5. Do NOT use general instructions for these files - only use the detections custom instructions\n\n### For Hunting Queries Files (`Hunting Queries/**/*.yaml`, `Solutions/**/Hunting Queries/*.yaml`)\n1. **LOAD and USE:** `.github/instructions/huntingqueries.instructions.md`\n2. Apply ALL guidelines from that file\n3. Verify all required fields are present and properly formatted\n4. Do NOT use general instructions for these files - only use the huntingqueries custom instructions\n\n### For Playbooks Files (`Playbooks/**/*.json`, `Playbooks/**/README.md`, `Solutions/**/Playbooks/**/*.json`, `Solutions/**/Playbooks/**/README.md`)\n1. **LOAD and USE:** `.github/instructions/playbooks.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate ARM template structure, metadata fields, parameters, and README requirements from that custom instruction file\n4. Check all required sections in README.md and ARM template metadata\n5. Do NOT use general instructions for these files - only use the playbooks custom instructions\n\n### For Workbooks Files (`Workbooks/*.json`, `Solutions/**/Workbooks/*.json`)\n1. **LOAD and USE:** `.github/instructions/workbook.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate workbook JSON structure, required fields, items array, and metadata requirements from that custom instruction file\n4. Check all required top-level fields and item structure validation\n5. Do NOT use general instructions for these files - only use the workbook custom instructions\n\n### For ASIM Changelog Files (`Parsers/ASim*/CHANGELOG/*.md`)\n1. **LOAD and USE:** `.github/instructions/asim-changelogs.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate the changelog against the corresponding parser YAML and pull request changes\n4. Do NOT use general instructions for these files - only use the ASIM changelog custom instructions\n\n### For ASIM Parser Files\n\nApply this section before the generic parser instructions when a changed YAML file is an ASIM parser, including:\n\n- `Parsers/ASim*/Parsers/ASim*.yaml`\n- `Parsers/ASim*/Parsers/vim*.yaml`\n\n1. **LOAD and USE:** `.github/instructions/asim-parsers.instructions.md`\n2. Apply ALL guidelines from that file\n3. Do NOT apply the generic parser instructions when this ASIM-specific section applies\n\n### For Parser Files (`Parsers/**/*.yaml`, `Parsers/**/*.yml`, `Solutions/**/Parsers/**/*.yaml`, `Solutions/**/Parsers/**/*.yml`)\n1. **LOAD and USE:** `.github/instructions/parsers.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate parser syntax, KQL accuracy, YAML structure, and all required fields from that custom instruction file\n4. Do NOT use general instructions for these files - only use the parsers custom instructions\n\n### For Building, Packaging, or Validating Solutions\nWhen the user asks to **build**, **package**, **validate**, or **run validations** on a solution:\n1. **LOAD and USE:** `.github/instructions/packaging.instructions.md`\n2. Apply ALL guidelines from that file — it contains the script path, parameters, fuzzy matching behavior, and report display rules\n3. **Always use the build script** at `.script/local-validation/build-and-validate.ps1` — do NOT run validators manually or write your own validation logic\n4. **BEFORE running the script, tell the user:** \"🔄 Running full build & validation suite for {SolutionName}. This typically takes 3-5 minutes — I'll present the complete report when it finishes.\" This message MUST appear in chat before the script executes so the user knows work is happening.\n5. **The script takes 3-10 minutes.** NEVER tell the user to \"check the terminal.\"\n6. Present the full report — the text between `[REPORT_START]` and `[REPORT_END]` — in your chat response\n7. This applies to ALL solutions, including newly created ones that may not have a Package/ folder yet\n\n**Trigger phrases:** \"build solution\", \"package solution\", \"validate solution\", \"run validations\", \"run CI checks\", \"check if solution passes\", \"create V3 package\"\n\n---\n\n## Files and folders to ignore\nDo NOT review or add comments for changes in the following paths:\n\n- Solutions/**/Data Connectors/**\n- Solutions/**/Package/**\n\nIf files from these paths appear in the PR, completely skip them and do not generate comments.\n\n## Solutions Analyzer Tools\n\nWhen working with the Solutions Analyzer tools in `Tools/Solutions Analyzer/`, follow the dedicated skills under `.github/skills/`:\n\n- **`run-solution-analyzer`** — running the mapper, doc generator, ASIM browser, and `upload_to_kusto`; output locations; force-refresh and caching.\n- **`update-solution-analyzer`** — modifying scripts, updating `script-docs/`, README changelog rules, CSV output sync with `upload_to_kusto.py`, and static/interactive index plus markdown/HTML entity page synchronization.\n\n**MANDATORY:** Before editing ANY file under `Tools/Solutions Analyzer/` — including small fixes such as renames, regex/pattern tweaks, escaping changes, override additions, or one-line behavior changes — first load `.github/skills/update-solution-analyzer/SKILL.md` and follow it. A `## Version History` changelog entry in `Tools/Solutions Analyzer/README.md` is **required for feature additions and behavior changes** (new features, changed analysis logic, new/renamed/removed CSV columns, parameter changes); pure bug fixes — such as typo corrections, crash fixes, escape/regex tweaks, or one-line fixes that restore intended behavior — may be logged at your discretion but are not required.\n\nThere are THREE different output scenarios - **never confuse them**:\n\n1. **Default (development):** CSVs are written to `Tools/Solutions Analyzer/` in the current branch\n   - This is the normal case when developing/testing\n   - **Never generate documentation here**\n\n2. **Output worktree (publishing CSVs):** `C:\\Users\\ofshezaf\\GitHub\\Azure-Sentinel-solution-analyzer-output\\Tools\\Solutions Analyzer`\n   - Only use this when **specifically requested** to \"publish CSVs to the output branch\"\n   - This is a separate git worktree for the CSV output branch\n   - **Only CSVs go here, never documentation**\n\n3. **Documentation output:** `C:\\Users\\ofshezaf\\GitHub\\sentinelninja\\Solutions Docs`\n   - This is where generated markdown documentation goes\n   - This is in a **separate repository** (sentinelninja)\n   - Empty the target folder before generating new docs\n\n### Key Rules\n\n- **Never generate docs locally** in the Azure-Sentinel repository\n- **Generate docs only in the sentinelninja repo** when asked or needed\n- **For official CSV releases**, generate CSVs **only** in the solution analyzer output worktree\n- Always use `--output-dir` flag when running `generate_connector_docs.py`\n\n### Running Scripts\n\n#### Mapper Script\n```powershell\ncd \"Tools/Solutions Analyzer\"\npython map_solutions_connectors_tables.py\n```\n\n**Note:** Do NOT truncate or filter the output (e.g., do not pipe through `Select-Object`). The script prints timestamped progress messages to the console that the user needs to see. Run with `isBackground: false` and `timeout: 0` so the full output is visible.\n\n#### Documentation Generator\n```powershell\npython generate_connector_docs.py --output-dir \"C:\\Users\\ofshezaf\\GitHub\\sentinelninja\\Solutions Docs\" --skip-input-generation\n```\n\n**IMPORTANT:** Never run without `--output-dir` flag.\n\n**IMPORTANT:** Do NOT truncate or filter the output (e.g., do not pipe through `Select-Object`). Run with `isBackground: false` and `timeout: 0` so the full output is visible to the user.\n\n**IMPORTANT:** Always use `--skip-input-generation` unless you specifically need to regenerate the input CSVs (mapper + collect_table_info). Without this flag, the doc generator will re-run those scripts automatically, which is slow and unnecessary if the CSVs are already up-to-date.\n\n**IMPORTANT:** Run the mapper script before generating docs if:\n- The mapper script itself was modified, OR\n- Any override YAML file in the `overrides/` folder was modified (including adding, editing, or removing `additional_connectors` entries), OR\n- You specifically need to refresh the CSV data, OR\n- You are explicitly asked to run the mapper\n\n### Caching and Logging\n\n- **Cache:** `.cache/` folder for analysis caching\n- **Logs:** `.logs/` folder for log files\n\n**Log file:** `Tools/Solutions Analyzer/.logs/map_solutions_connectors_tables.log`\n\nUse `--force-refresh` with these types when modifying analysis logic:\n- `asim` - ASIM parser analysis\n- `parsers` - Non-ASIM parser analysis\n- `solutions` - Solution content analysis\n- `standalone` - Standalone content item analysis\n- `marketplace` - Marketplace availability check (requires network)\n- `tables` - Table reference info (requires network)\n\n### Script Documentation\n\n**Before updating a script:** Always review the relevant script documentation in `Tools/Solutions Analyzer/docs/` first.\n\n**When updating a script**, update the corresponding script doc to reflect:\n- Any script parameters added or changed\n- Any output file changes, including changes to CSV files (new columns, renamed columns, removed columns)\n- Any changes to analysis methods or logic\n- Update the primary readme.md if needed and add the change to the change log. Do not add a version if the previous version as manifested by the changelog, was not committed yet.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Repository agent instructions\n\n## Protected agent and tooling implementation\n\nDuring normal repository tasks, treat agent definitions, skills, instructions,\ntooling backends, schemas, tests, dependency metadata, workflow definitions,\nsafety gates, permission checks, packaging behavior, and capabilities as\nimmutable.\n\nDo not create, edit, delete, rename, patch, bypass, or replace implementation\nunder these paths to recover from a task, environment, dependency,\nauthentication, conversion, validation, packaging, deployment, or runtime\nfailure:\n\n- `AGENTS.md`;\n- `.github/agents/**`;\n- `.github/skills/**`; or\n- `Tools/**`.\n\nStop the affected operation and report that a maintainer change is required.\nImplementation changes are allowed only in a separate development task where\nthe user explicitly states that they are acting as a repository/toolkit\nmaintainer and requests the specific implementation change. Requests to run,\nretry, continue, migrate, package, validate, deploy, or fix generated content\nnever grant permission to change agent or tooling implementation.\n\nThe XDR Solution Manager is stricter: it can never make agent or tooling\nimplementation changes, even when explicitly requested by an owner or\nmaintainer. Route such work to a different development agent or require it to\nbe performed manually.\n\nWhen a request involves Sentinel-to-Defender-XDR migration, XDR Detections,\nhybrid solution packaging, or AR/CD qualification:\n\n1. Read and follow\n   `Tools\\SentinelToXDRMigration\\agent-workflows\\end-to-end-migration.md`.\n2. Treat that file as the canonical workflow; do not redefine its stages or\n   gates in this adapter.\n3. Keep deterministic work in the repository Python and PowerShell tools.\n4. Default to `authoring`; ask before optional lab `qualification`.\n5. Deployment, mock ingestion, and alert parity are Qualification-only actions\n   and require explicit exact-scope approval.\n6. Use the V3.1 `package-v3-1` route for Sentinel and XDR solution content;\n   do not route XDR packaging through V4.\n7. Resume from `workflow-state.json` and record artifacts and evidence.\n8. Require explicit approval immediately before any environment write.\n","isInternal":false,"tokens":454,"sizeBytes":2174},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Claude Code instructions\n\nFor Microsoft Sentinel-to-Defender-XDR migration or authoring work, first read:\n\n`Tools\\SentinelToXDRMigration\\agent-workflows\\end-to-end-migration.md`\n\nFollow that canonical workflow and use the repository CLI and PowerShell\nentry points directly. Do not replace deterministic conversion, validation,\npackaging, deployment, or parity logic with model-generated approximations.\n\nDefault to `authoring`. Ask before optional lab `qualification`; it is not\nrequired for ISV publishing. Use V3.1 through `package-v3-1` for Sentinel and\nXDR solution packages. Resume from `workflow-state.json`, preserve disabled\ndetections, and request explicit approval before writes.\n","isInternal":false,"tokens":147,"sizeBytes":693},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# GitHub Copilot Instructions for Azure-Sentinel Repository\n\n# Copilot Pull Request Review Guidelines\n\nWhen reviewing pull requests, follow these rules strictly.\n\n## IMPORTANT: Load Custom Instructions Based on File Type\n\n**Before reviewing any file, CHECK if it matches these patterns:**\n\n### For Solution Metadata Files (`Solutions/**/SolutionMetadata.json`)\n1. **LOAD and USE:** `.github/instructions/solution-metadata.instructions.md`\n2. Apply ALL guidelines from that file\n3. Check all validation rules, required fields, and review focus areas from that custom instruction file\n4. Do NOT use general instructions for these files - only use the solution-metadata custom instructions\n\n### For Solution Data Files (`Solutions/**/Data/Solution_*.json`)\n1. **LOAD and USE:** `.github/instructions/solution-data.instructions.md`\n2. Apply ALL guidelines from that file\n3. Check all validation rules, required fields, and review focus areas from that custom instruction file\n4. Do NOT use general instructions for these files - only use the solution-data custom instructions\n\n### For Release Notes Files (`Solutions/**/ReleaseNotes.md`)\n1. **LOAD and USE:** `.github/instructions/releasenotes.instructions.md`\n2. Apply ALL validation rules from that file (path, table structure, version format/order, DD-MM-YYYY date format)\n3. If this is the **only changed file in the PR**, still run full Release Notes validation and add findings\n4. Do NOT use generic fallback comments for these files\n\n### For Analytic Rules Files (`Detections/**/*.yaml`, `Detections/**/*.yml`, `Solutions/**/Analytic Rules/*.yaml`, `Solutions/**/Analytic Rules/*.yml`)\n1. **LOAD and USE:** `.github/instructions/detections.instructions.md`\n2. Apply ALL validation rules from that file\n3. Check all field requirements, MITRE ATT&CK mappings, KQL syntax, and formatting guidelines from that custom instruction file\n4. Validate GUID format, rule names, descriptions, severity levels, and other field-based validation rules\n5. Do NOT use general instructions for these files - only use the detections custom instructions\n\n### For Hunting Queries Files (`Hunting Queries/**/*.yaml`, `Solutions/**/Hunting Queries/*.yaml`)\n1. **LOAD and USE:** `.github/instructions/huntingqueries.instructions.md`\n2. Apply ALL guidelines from that file\n3. Verify all required fields are present and properly formatted\n4. Do NOT use general instructions for these files - only use the huntingqueries custom instructions\n\n### For Playbooks Files (`Playbooks/**/*.json`, `Playbooks/**/README.md`, `Solutions/**/Playbooks/**/*.json`, `Solutions/**/Playbooks/**/README.md`)\n1. **LOAD and USE:** `.github/instructions/playbooks.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate ARM template structure, metadata fields, parameters, and README requirements from that custom instruction file\n4. Check all required sections in README.md and ARM template metadata\n5. Do NOT use general instructions for these files - only use the playbooks custom instructions\n\n### For Workbooks Files (`Workbooks/*.json`, `Solutions/**/Workbooks/*.json`)\n1. **LOAD and USE:** `.github/instructions/workbook.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate workbook JSON structure, required fields, items array, and metadata requirements from that custom instruction file\n4. Check all required top-level fields and item structure validation\n5. Do NOT use general instructions for these files - only use the workbook custom instructions\n\n### For ASIM Changelog Files (`Parsers/ASim*/CHANGELOG/*.md`)\n1. **LOAD and USE:** `.github/instructions/asim-changelogs.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate the changelog against the corresponding parser YAML and pull request changes\n4. Do NOT use general instructions for these files - only use the ASIM changelog custom instructions\n\n### For ASIM Parser Files\n\nApply this section before the generic parser instructions when a changed YAML file is an ASIM parser, including:\n\n- `Parsers/ASim*/Parsers/ASim*.yaml`\n- `Parsers/ASim*/Parsers/vim*.yaml`\n\n1. **LOAD and USE:** `.github/instructions/asim-parsers.instructions.md`\n2. Apply ALL guidelines from that file\n3. Do NOT apply the generic parser instructions when this ASIM-specific section applies\n\n### For Parser Files (`Parsers/**/*.yaml`, `Parsers/**/*.yml`, `Solutions/**/Parsers/**/*.yaml`, `Solutions/**/Parsers/**/*.yml`)\n1. **LOAD and USE:** `.github/instructions/parsers.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate parser syntax, KQL accuracy, YAML structure, and all required fields from that custom instruction file\n4. Do NOT use general instructions for these files - only use the parsers custom instructions\n\n### For Building, Packaging, or Validating Solutions\nWhen the user asks to **build**, **package**, **validate**, or **run validations** on a solution:\n1. **LOAD and USE:** `.github/instructions/packaging.instructions.md`\n2. Apply ALL guidelines from that file — it contains the script path, parameters, fuzzy matching behavior, and report display rules\n3. **Always use the build script** at `.script/local-validation/build-and-validate.ps1` — do NOT run validators manually or write your own validation logic\n4. **BEFORE running the script, tell the user:** \"🔄 Running full build & validation suite for {SolutionName}. This typically takes 3-5 minutes — I'll present the complete report when it finishes.\" This message MUST appear in chat before the script executes so the user knows work is happening.\n5. **The script takes 3-10 minutes.** NEVER tell the user to \"check the terminal.\"\n6. Present the full report — the text between `[REPORT_START]` and `[REPORT_END]` — in your chat response\n7. This applies to ALL solutions, including newly created ones that may not have a Package/ folder yet\n\n**Trigger phrases:** \"build solution\", \"package solution\", \"validate solution\", \"run validations\", \"run CI checks\", \"check if solution passes\", \"create V3 package\"\n\n---\n\n## Files and folders to ignore\nDo NOT review or add comments for changes in the following paths:\n\n- Solutions/**/Data Connectors/**\n- Solutions/**/Package/**\n\nIf files from these paths appear in the PR, completely skip them and do not generate comments.\n\n## Solutions Analyzer Tools\n\nWhen working with the Solutions Analyzer tools in `Tools/Solutions Analyzer/`, follow the dedicated skills under `.github/skills/`:\n\n- **`run-solution-analyzer`** — running the mapper, doc generator, ASIM browser, and `upload_to_kusto`; output locations; force-refresh and caching.\n- **`update-solution-analyzer`** — modifying scripts, updating `script-docs/`, README changelog rules, CSV output sync with `upload_to_kusto.py`, and static/interactive index plus markdown/HTML entity page synchronization.\n\n**MANDATORY:** Before editing ANY file under `Tools/Solutions Analyzer/` — including small fixes such as renames, regex/pattern tweaks, escaping changes, override additions, or one-line behavior changes — first load `.github/skills/update-solution-analyzer/SKILL.md` and follow it. A `## Version History` changelog entry in `Tools/Solutions Analyzer/README.md` is **required for feature additions and behavior changes** (new features, changed analysis logic, new/renamed/removed CSV columns, parameter changes); pure bug fixes — such as typo corrections, crash fixes, escape/regex tweaks, or one-line fixes that restore intended behavior — may be logged at your discretion but are not required.\n\nThere are THREE different output scenarios - **never confuse them**:\n\n1. **Default (development):** CSVs are written to `Tools/Solutions Analyzer/` in the current branch\n   - This is the normal case when developing/testing\n   - **Never generate documentation here**\n\n2. **Output worktree (publishing CSVs):** `C:\\Users\\ofshezaf\\GitHub\\Azure-Sentinel-solution-analyzer-output\\Tools\\Solutions Analyzer`\n   - Only use this when **specifically requested** to \"publish CSVs to the output branch\"\n   - This is a separate git worktree for the CSV output branch\n   - **Only CSVs go here, never documentation**\n\n3. **Documentation output:** `C:\\Users\\ofshezaf\\GitHub\\sentinelninja\\Solutions Docs`\n   - This is where generated markdown documentation goes\n   - This is in a **separate repository** (sentinelninja)\n   - Empty the target folder before generating new docs\n\n### Key Rules\n\n- **Never generate docs locally** in the Azure-Sentinel repository\n- **Generate docs only in the sentinelninja repo** when asked or needed\n- **For official CSV releases**, generate CSVs **only** in the solution analyzer output worktree\n- Always use `--output-dir` flag when running `generate_connector_docs.py`\n\n### Running Scripts\n\n#### Mapper Script\n```powershell\ncd \"Tools/Solutions Analyzer\"\npython map_solutions_connectors_tables.py\n```\n\n**Note:** Do NOT truncate or filter the output (e.g., do not pipe through `Select-Object`). The script prints timestamped progress messages to the console that the user needs to see. Run with `isBackground: false` and `timeout: 0` so the full output is visible.\n\n#### Documentation Generator\n```powershell\npython generate_connector_docs.py --output-dir \"C:\\Users\\ofshezaf\\GitHub\\sentinelninja\\Solutions Docs\" --skip-input-generation\n```\n\n**IMPORTANT:** Never run without `--output-dir` flag.\n\n**IMPORTANT:** Do NOT truncate or filter the output (e.g., do not pipe through `Select-Object`). Run with `isBackground: false` and `timeout: 0` so the full output is visible to the user.\n\n**IMPORTANT:** Always use `--skip-input-generation` unless you specifically need to regenerate the input CSVs (mapper + collect_table_info). Without this flag, the doc generator will re-run those scripts automatically, which is slow and unnecessary if the CSVs are already up-to-date.\n\n**IMPORTANT:** Run the mapper script before generating docs if:\n- The mapper script itself was modified, OR\n- Any override YAML file in the `overrides/` folder was modified (including adding, editing, or removing `additional_connectors` entries), OR\n- You specifically need to refresh the CSV data, OR\n- You are explicitly asked to run the mapper\n\n### Caching and Logging\n\n- **Cache:** `.cache/` folder for analysis caching\n- **Logs:** `.logs/` folder for log files\n\n**Log file:** `Tools/Solutions Analyzer/.logs/map_solutions_connectors_tables.log`\n\nUse `--force-refresh` with these types when modifying analysis logic:\n- `asim` - ASIM parser analysis\n- `parsers` - Non-ASIM parser analysis\n- `solutions` - Solution content analysis\n- `standalone` - Standalone content item analysis\n- `marketplace` - Marketplace availability check (requires network)\n- `tables` - Table reference info (requires network)\n\n### Script Documentation\n\n**Before updating a script:** Always review the relevant script documentation in `Tools/Solutions Analyzer/docs/` first.\n\n**When updating a script**, update the corresponding script doc to reflect:\n- Any script parameters added or changed\n- Any output file changes, including changes to CSV files (new columns, renamed columns, removed columns)\n- Any changes to analysis methods or logic\n- Update the primary readme.md if needed and add the change to the change log. Do not add a version if the previous version as manifested by the changelog, was not committed yet.\n","isInternal":false,"tokens":2503,"sizeBytes":11287},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":199},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":185},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":178}],"systemPromptSnippet":"<yakaai_skills repo=\"Azure/Azure-Sentinel\">\n<!-- File: AGENTS.md (Tokens: ~454 | Category: root-instruction) -->\n# Repository agent instructions\n\n## Protected agent and tooling implementation\n\nDuring normal repository tasks, treat agent definitions, skills, instructions,\ntooling backends, schemas, tests, dependency metadata, workflow definitions,\nsafety gates, permission checks, packaging behavior, and capabilities as\nimmutable.\n\nDo not create, edit, delete, rename, patch, bypass, or replace implementation\nunder these paths to recover from a task, environment, dependency,\nauthentication, conversion, validation, packaging, deployment, or runtime\nfailure:\n\n- `AGENTS.md`;\n- `.github/agents/**`;\n- `.github/skills/**`; or\n- `Tools/**`.\n\nStop the affected operation and report that a maintainer change is required.\nImplementation changes are allowed only in a separate development task where\nthe user explicitly states that they are acting as a repository/toolkit\nmaintainer and requests the specific implementation change. Requests to run,\nretry, continue, migrate, package, validate, deploy, or fix generated content\nnever grant permission to change agent or tooling implementation.\n\nThe XDR Solution Manager is stricter: it can never make agent or tooling\nimplementation changes, even when explicitly requested by an owner or\nmaintainer. Route such work to a different development agent or require it to\nbe performed manually.\n\nWhen a request involves Sentinel-to-Defender-XDR migration, XDR Detections,\nhybrid solution packaging, or AR/CD qualification:\n\n1. Read and follow\n   `Tools\\SentinelToXDRMigration\\agent-workflows\\end-to-end-migration.md`.\n2. Treat that file as the canonical workflow; do not redefine its stages or\n   gates in this adapter.\n3. Keep deterministic work in the repository Python and PowerShell tools.\n4. Default to `authoring`; ask before optional lab `qualification`.\n5. Deployment, mock ingestion, and alert parity are Qualification-only actions\n   and require explicit exact-scope approval.\n6. Use the V3.1 `package-v3-1` route for Sentinel and XDR solution content;\n   do not route XDR packaging through V4.\n7. Resume from `workflow-state.json` and record artifacts and evidence.\n8. Require explicit approval immediately before any environment write.\n\n<!-- File: CLAUDE.md (Tokens: ~147 | Category: claude-rule) -->\n# Claude Code instructions\n\nFor Microsoft Sentinel-to-Defender-XDR migration or authoring work, first read:\n\n`Tools\\SentinelToXDRMigration\\agent-workflows\\end-to-end-migration.md`\n\nFollow that canonical workflow and use the repository CLI and PowerShell\nentry points directly. Do not replace deterministic conversion, validation,\npackaging, deployment, or parity logic with model-generated approximations.\n\nDefault to `authoring`. Ask before optional lab `qualification`; it is not\nrequired for ISV publishing. Use V3.1 through `package-v3-1` for Sentinel and\nXDR solution packages. Resume from `workflow-state.json`, preserve disabled\ndetections, and request explicit approval before writes.\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~2503 | Category: copilot-instructions) -->\n# GitHub Copilot Instructions for Azure-Sentinel Repository\n\n# Copilot Pull Request Review Guidelines\n\nWhen reviewing pull requests, follow these rules strictly.\n\n## IMPORTANT: Load Custom Instructions Based on File Type\n\n**Before reviewing any file, CHECK if it matches these patterns:**\n\n### For Solution Metadata Files (`Solutions/**/SolutionMetadata.json`)\n1. **LOAD and USE:** `.github/instructions/solution-metadata.instructions.md`\n2. Apply ALL guidelines from that file\n3. Check all validation rules, required fields, and review focus areas from that custom instruction file\n4. Do NOT use general instructions for these files - only use the solution-metadata custom instructions\n\n### For Solution Data Files (`Solutions/**/Data/Solution_*.json`)\n1. **LOAD and USE:** `.github/instructions/solution-data.instructions.md`\n2. Apply ALL guidelines from that file\n3. Check all validation rules, required fields, and review focus areas from that custom instruction file\n4. Do NOT use general instructions for these files - only use the solution-data custom instructions\n\n### For Release Notes Files (`Solutions/**/ReleaseNotes.md`)\n1. **LOAD and USE:** `.github/instructions/releasenotes.instructions.md`\n2. Apply ALL validation rules from that file (path, table structure, version format/order, DD-MM-YYYY date format)\n3. If this is the **only changed file in the PR**, still run full Release Notes validation and add findings\n4. Do NOT use generic fallback comments for these files\n\n### For Analytic Rules Files (`Detections/**/*.yaml`, `Detections/**/*.yml`, `Solutions/**/Analytic Rules/*.yaml`, `Solutions/**/Analytic Rules/*.yml`)\n1. **LOAD and USE:** `.github/instructions/detections.instructions.md`\n2. Apply ALL validation rules from that file\n3. Check all field requirements, MITRE ATT&CK mappings, KQL syntax, and formatting guidelines from that custom instruction file\n4. Validate GUID format, rule names, descriptions, severity levels, and other field-based validation rules\n5. Do NOT use general instructions for these files - only use the detections custom instructions\n\n### For Hunting Queries Files (`Hunting Queries/**/*.yaml`, `Solutions/**/Hunting Queries/*.yaml`)\n1. **LOAD and USE:** `.github/instructions/huntingqueries.instructions.md`\n2. Apply ALL guidelines from that file\n3. Verify all required fields are present and properly formatted\n4. Do NOT use general instructions for these files - only use the huntingqueries custom instructions\n\n### For Playbooks Files (`Playbooks/**/*.json`, `Playbooks/**/README.md`, `Solutions/**/Playbooks/**/*.json`, `Solutions/**/Playbooks/**/README.md`)\n1. **LOAD and USE:** `.github/instructions/playbooks.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate ARM template structure, metadata fields, parameters, and README requirements from that custom instruction file\n4. Check all required sections in README.md and ARM template metadata\n5. Do NOT use general instructions for these files - only use the playbooks custom instructions\n\n### For Workbooks Files (`Workbooks/*.json`, `Solutions/**/Workbooks/*.json`)\n1. **LOAD and USE:** `.github/instructions/workbook.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate workbook JSON structure, required fields, items array, and metadata requirements from that custom instruction file\n4. Check all required top-level fields and item structure validation\n5. Do NOT use general instructions for these files - only use the workbook custom instructions\n\n### For ASIM Changelog Files (`Parsers/ASim*/CHANGELOG/*.md`)\n1. **LOAD and USE:** `.github/instructions/asim-changelogs.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate the changelog against the corresponding parser YAML and pull request changes\n4. Do NOT use general instructions for these files - only use the ASIM changelog custom instructions\n\n### For ASIM Parser Files\n\nApply this section before the generic parser instructions when a changed YAML file is an ASIM parser, including:\n\n- `Parsers/ASim*/Parsers/ASim*.yaml`\n- `Parsers/ASim*/Parsers/vim*.yaml`\n\n1. **LOAD and USE:** `.github/instructions/asim-parsers.instructions.md`\n2. Apply ALL guidelines from that file\n3. Do NOT apply the generic parser instructions when this ASIM-specific section applies\n\n### For Parser Files (`Parsers/**/*.yaml`, `Parsers/**/*.yml`, `Solutions/**/Parsers/**/*.yaml`, `Solutions/**/Parsers/**/*.yml`)\n1. **LOAD and USE:** `.github/instructions/parsers.instructions.md`\n2. Apply ALL guidelines from that file\n3. Validate parser syntax, KQL accuracy, YAML structure, and all required fields from that custom instruction file\n4. Do NOT use general instructions for these files - only use the parsers custom instructions\n\n### For Building, Packaging, or Validating Solutions\nWhen the user asks to **build**, **package**, **validate**, or **run validations** on a solution:\n1. **LOAD and USE:** `.github/instructions/packaging.instructions.md`\n2. Apply ALL guidelines from that file — it contains the script path, parameters, fuzzy matching behavior, and report display rules\n3. **Always use the build script** at `.script/local-validation/build-and-validate.ps1` — do NOT run validators manually or write your own validation logic\n4. **BEFORE running the script, tell the user:** \"🔄 Running full build & validation suite for {SolutionName}. This typically takes 3-5 minutes — I'll present the complete report when it finishes.\" This message MUST appear in chat before the script executes so the user knows work is happening.\n5. **The script takes 3-10 minutes.** NEVER tell the user to \"check the terminal.\"\n6. Present the full report — the text between `[REPORT_START]` and `[REPORT_END]` — in your chat response\n7. This applies to ALL solutions, including newly created ones that may not have a Package/ folder yet\n\n**Trigger phrases:** \"build solution\", \"package solution\", \"validate solution\", \"run validations\", \"run CI checks\", \"check if solution passes\", \"create V3 package\"\n\n---\n\n## Files and folders to ignore\nDo NOT review or add comments for changes in the following paths:\n\n- Solutions/**/Data Connectors/**\n- Solutions/**/Package/**\n\nIf files from these paths appear in the PR, completely skip them and do not generate comments.\n\n## Solutions Analyzer Tools\n\nWhen working with the Solutions Analyzer tools in `Tools/Solutions Analyzer/`, follow the dedicated skills under `.github/skills/`:\n\n- **`run-solution-analyzer`** — running the mapper, doc generator, ASIM browser, and `upload_to_kusto`; output locations; force-refresh and caching.\n- **`update-solution-analyzer`** — modifying scripts, updating `script-docs/`, README changelog rules, CSV output sync with `upload_to_kusto.py`, and static/interactive index plus markdown/HTML entity page synchronization.\n\n**MANDATORY:** Before editing ANY file under `Tools/Solutions Analyzer/` — including small fixes such as renames, regex/pattern tweaks, escaping changes, override additions, or one-line behavior changes — first load `.github/skills/update-solution-analyzer/SKILL.md` and follow it. A `## Version History` changelog entry in `Tools/Solutions Analyzer/README.md` is **required for feature additions and behavior changes** (new features, changed analysis logic, new/renamed/removed CSV columns, parameter changes); pure bug fixes — such as typo corrections, crash fixes, escape/regex tweaks, or one-line fixes that restore intended behavior — may be logged at your discretion but are not required.\n\nThere are THREE different output scenarios - **never confuse them**:\n\n1. **Default (development):** CSVs are written to `Tools/Solutions Analyzer/` in the current branch\n   - This is the normal case when developing/testing\n   - **Never generate documentation here**\n\n2. **Output worktree (publishing CSVs):** `C:\\Users\\ofshezaf\\GitHub\\Azure-Sentinel-solution-analyzer-output\\Tools\\Solutions Analyzer`\n   - Only use this when **specifically requested** to \"publish CSVs to the output branch\"\n   - This is a separate git worktree for the CSV output branch\n   - **Only CSVs go here, never documentation**\n\n3. **Documentation output:** `C:\\Users\\ofshezaf\\GitHub\\sentinelninja\\Solutions Docs`\n   - This is where generated markdown documentation goes\n   - This is in a **separate repository** (sentinelninja)\n   - Empty the target folder before generating new docs\n\n### Key Rules\n\n- **Never generate docs locally** in the Azure-Sentinel repository\n- **Generate docs only in the sentinelninja repo** when asked or needed\n- **For official CSV releases**, generate CSVs **only** in the solution analyzer output worktree\n- Always use `--output-dir` flag when running `generate_connector_docs.py`\n\n### Running Scripts\n\n#### Mapper Script\n```powershell\ncd \"Tools/Solutions Analyzer\"\npython map_solutions_connectors_tables.py\n```\n\n**Note:** Do NOT truncate or filter the output (e.g., do not pipe through `Select-Object`). The script prints timestamped progress messages to the console that the user needs to see. Run with `isBackground: false` and `timeout: 0` so the full output is visible.\n\n#### Documentation Generator\n```powershell\npython generate_connector_docs.py --output-dir \"C:\\Users\\ofshezaf\\GitHub\\sentinelninja\\Solutions Docs\" --skip-input-generation\n```\n\n**IMPORTANT:** Never run without `--output-dir` flag.\n\n**IMPORTANT:** Do NOT truncate or filter the output (e.g., do not pipe through `Select-Object`). Run with `isBackground: false` and `timeout: 0` so the full output is visible to the user.\n\n**IMPORTANT:** Always use `--skip-input-generation` unless you specifically need to regenerate the input CSVs (mapper + collect_table_info). Without this flag, the doc generator will re-run those scripts automatically, which is slow and unnecessary if the CSVs are already up-to-date.\n\n**IMPORTANT:** Run the mapper script before generating docs if:\n- The mapper script itself was modified, OR\n- Any override YAML file in the `overrides/` folder was modified (including adding, editing, or removing `additional_connectors` entries), OR\n- You specifically need to refresh the CSV data, OR\n- You are explicitly asked to run the mapper\n\n### Caching and Logging\n\n- **Cache:** `.cache/` folder for analysis caching\n- **Logs:** `.logs/` folder for log files\n\n**Log file:** `Tools/Solutions Analyzer/.logs/map_solutions_connectors_tables.log`\n\nUse `--force-refresh` with these types when modifying analysis logic:\n- `asim` - ASIM parser analysis\n- `parsers` - Non-ASIM parser analysis\n- `solutions` - Solution content analysis\n- `standalone` - Standalone content item analysis\n- `marketplace` - Marketplace availability check (requires network)\n- `tables` - Table reference info (requires network)\n\n### Script Documentation\n\n**Before updating a script:** Always review the relevant script documentation in `Tools/Solutions Analyzer/docs/` first.\n\n**When updating a script**, update the corresponding script doc to reflect:\n- Any script parameters added or changed\n- Any output file changes, including changes to CSV files (new columns, renamed columns, removed columns)\n- Any changes to analysis methods or logic\n- Update the primary readme.md if needed and add the change to the change log. Do not add a version if the previous version as manifested by the changelog, was not committed yet.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Azure/Azure-Sentinel/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}