| name | sigma-rule-writer |
| description | Guided sigma detection rule writing from a natural language threat description. Use when the user asks to write a sigma rule, SIEM detection rule, EDR alert logic, or any "detect when X happens" question. Asks clarifying questions (logsource, MITRE ATT&CK TTP, severity), drafts YAML via mcp__plugin_wrg-sigma-rules_wrg-sigma-rules__draft_rule, validates via mcp__plugin_wrg-sigma-rules_wrg-sigma-rules__validate_rule, and offers backend conversion. |
| user-invocable | true |
| allowed-tools | ["Read","Write","Bash(ls *)","mcp__plugin_wrg-sigma-rules_wrg-sigma-rules__draft_rule","mcp__plugin_wrg-sigma-rules_wrg-sigma-rules__validate_rule","mcp__plugin_wrg-sigma-rules_wrg-sigma-rules__convert_rule"] |
Sigma Rule Writer
Guides a SOC analyst, threat-intel responder, or bug-bounty hunter through
writing a production-grade sigma detection rule from a plain-English threat
description.
Trigger when the user says any of:
- "write a sigma rule for X"
- "I need a detection for X"
- "how do I detect X in my SIEM"
- "draft an EDR alert for X"
- "convert this CVE / blog post into a rule"
Workflow
Step 1 -- Clarify intent (only ask what is missing)
Collect these inputs before drafting. Ask in plain language; do not dump a
form on the user.
- Threat behavior -- what action triggers? (process exec, file write,
registry mutation, network conn, auth event, cloud API call)
- Logsource -- what telemetry sees this? (Windows event log + channel,
Sysmon EventID, EDR provider, Linux auditd, cloud audit log, network IDS)
- Platform -- Windows / Linux / macOS / network / cloud (AWS / Azure /
GCP / SaaS)
- MITRE ATT&CK TTP -- technique ID if known (e.g. T1059.001 PowerShell);
ask only if the user has not already cited one
- Severity -- low / medium / high / critical (default: medium if absent)
- References -- CVE ID, blog post URL, incident report, prior rule (if
any). Used in the rule's
references: block.
Skip questions the user already answered. Inferring from context is fine;
asking the same thing twice is not.
Step 2 -- Draft via mcp__plugin_wrg-sigma-rules_wrg-sigma-rules__draft_rule
Pass the collected inputs as a structured payload. The tool returns a YAML
scaffold conforming to the sigma spec (https://github.com/SigmaHQ/sigma-specification).
Show the YAML to the user. Highlight the detection: block specifically and
explain the selection / filter / condition logic in 1-2 sentences.
Step 3 -- Validate via mcp__plugin_wrg-sigma-rules_wrg-sigma-rules__validate_rule
Run validation immediately on the drafted YAML. Surface ALL warnings to the
user, not just errors:
- pySigma parser errors (hard fail)
- best-practices linter warnings (e.g. missing
falsepositives: block,
overly broad selection, condition ambiguity)
- WRG corpus deviations (e.g. logsource format drift vs canonical 50+ rule
reference set)
If validation fails, offer to revise. Do not silently accept warnings.
Step 4 -- Offer conversion (opt-in)
Ask whether the user wants the rule converted to their SIEM query language:
- Splunk SPL (
mcp__plugin_wrg-sigma-rules_wrg-sigma-rules__convert_rule backend=splunk)
- Elastic ESQL / KQL (backend=elastic / kibana)
- Wazuh XML (backend=wazuh)
Show converted output side-by-side with source sigma YAML.
Step 5 -- Save the rule (opt-in)
If the user wants the rule saved, ask for a target path. Default suggestion:
detections/sigma/<platform>/<ttp-id>_<short-slug>.yml
Use Write tool with the validated YAML content.
Output discipline
- Sigma spec compliant YAML -- pySigma parses without error
- MITRE ATT&CK tagging mandatory --
tags: block with at least one
attack.txxxx entry; multi-TTP rules tag each
- References included -- CVE / blog / incident URL in
references: block;
empty references: is a smell
- Falsepositives populated -- at least one realistic FP scenario; "Unknown"
is acceptable but flag for review
- LLM-safe redaction -- never leak operator-internal infra: no internal
hostnames, no internal IP ranges, no employee identifiers; placeholders
like
<internal-domain> if the user pastes context that includes them
Anti-patterns (do not do)
- Drafting without validating (skip Step 3)
- Inventing TTP IDs (always cite a real
Txxxx or omit the tag)
- Wrapping in code comments instead of producing a parseable YAML document
- Adding closure cues ("Hope this helps!", "Let me know if...") -- operator
drives next step
